No one I know personally uses git yet, but I see the Ruby on Rails community starting to use it a bit, so I decided I had better get up to speed.
I didn't really need the full power of git. I just needed a simple setup, somewhere I could commit code over SSH. The initial steps for such a setup were not exactly simple to learn as a first-time git user. Hints were scattered across many different websites. So I'm documenting everything I've learned here in a blog entry, in case other git n00bs like myself might find it useful.
First make a new git repo on your remote host:
mkdir -p /git/foo cd /git/foo git init
git should return something like:
Initialized empty Git repository in .git/
Your /git/foo path will likely be different than mine, but it doesn't really matter where you put stuff. I already had an /svn directory with all my Subversion repos in there, so it made sense (to me) to add a /git directory and put all my new git repos in there.
If you're used to using Subversion you might think you can now "check out" this empty git repo, but you'd be wrong. You don't check out code from a git repo, you "clone" it instead. But trying to clone your new git repo right now leads to the (initially confusing) error:
fatal: no matching remote head
The error occurs because your new git repo has no tree, no files, etc.
Instead of trying to clone your new remote git repo, make another git repo on your local machine, some place where you'll be doing your actual code development later:
mkdir ~/foo cd ~/foo git init
git should again dazzle and impress you with the non-error message:
Initialized empty Git repository in .git/
Next add some files to the local repo you just created (still in same foo directory):
cp -r /path/to/your/project/* .
Your local git repo doesn't know about your new project files yet. You need to "add" them (still in the same directory):
git add *
Now that git knows about them you can commit them:
git commit -m 'initial commit'
The -m is your commit message. If you leave that off you'll be prompted to add a commit message, just like with Subversion.
At this point your project files do not yet exist in your remote git repo that you created at the very beginning. They have only been committed to your local git repo. To transfer them you'll need to do a "push", like this:
git push ssh://example.com/git/foo master
Again, your specific path may vary depending on where you created your remote git repo. If you're like me, you probably run your ssh server on an alternate port other than the standard port 22. In addition, your local username might be different than the one you use on the remote server. Your push syntax might be something more exotic, like this perhaps:
git push ssh://firstname.lastname@example.org:8022/git/foo master
"master" tells git to push the code into the main branch of your remote git repo. If you were pushing to another branch you'd use that instead.
If all went well you'll get a message something like:
* [new branch] master -> master
If you didn't get a similar message, check your push URL for accuracy.
Next you have some options for how to tell your local repo where it's origin/master is. I found the documented options workable, but I also found it's just a hell of a lot easier to clone the remote repo, it now has content after all!
So I tossed out my local git repo and cloned it anew:
cd ~ rm -rf foo git clone ssh://example.com/git/foo
If you want your local repo directory to be named something else, add a directory name on the end like this:
git clone ssh://example.com/git/foo bar
I found my normal workflow is a lot like Subversion, just with the added step of pushing out to the remote repo after the local commit. There are commit hooks to make that automatic if you like.
|Console Blackjack written in Perl 6|
|How-to build latest Linux kernel from Linus' git repo on Debian/Ubuntu|
|Console Blackjack in C++|
|Visual Studio Code Configuration|
|airplane (1) apache (1) apple (1) bash (2) bashrc (1) blackjack (3) callproof (1) college (1) config (1) console (3) cpp (1) data (1) debian (4) diff (1) django (2) electoral (1) enterprise (1) flying (1) freebsd (1) games (1) git (3) github (4) gmail (1) go-lang (3) google (1) gourse (1) kernel (3) latin1 (1) linux (4) lottery (1) microsoft (1) module (1) mongodb (1) mp3s (1) mutt (1) patch (1) perl6 (1) photos (1) postgresql (2) powerball (1) psql (1) python (2) raspberrypi (1) rc (1) rubocopyml (1) sed (1) stack (1) sublime (1) testing (2) trace (1) ubuntu (2) utf8 (1) virus (1) visualstudiocode (1) vote (1) waylon (1)|
Copyright © 2017 · GregDonald.io · All Rights Reserved