\n\n\n
There are many, many git tutorials out there. http:\/\/rogerdudler.github.io\/git-guide\/ is pretty cool and gives a nice overview. However, it doesn't quite set you up to play around<\/em> with the commands. Here is a completely self-contained walk-through that doesn't require any networking to experiment with a reasonable git setup. <\/p>\n<\/div>\n<\/div>\n<\/div>\n Let's work through a simple scenario where two friends (Mark and Barb) want to hack on some code together. Since they are both jet-setting around the country and typically working from laptops, they decide to setup a central repository for their code base. (Note: These days, you can do that on github in about 45 seconds.<\/em>) We're going to simulate the three computers (Barb's laptop, Mark's laptop, and the central repository server) on one physical computer. There's no fundamental difference from using physically remote machines: you'd had to setup the networking support (typically using ssh\/sshd) and authentication (public\/private keys) and you'd specify the remote machine when executing commands.<\/p>\n<\/div>\n<\/div>\n<\/div>\n Without further ado (about nothing), let's create a pseudo-laptop and create an initial (empty) code base:<\/p>\n<\/div>\n<\/div>\n<\/div>\n Now, since we know we want to use git, we can use git to create an initial repository that isn't keeping track of anything (yet). We do this with the Ok, let's populate the code base.<\/p>\n<\/div>\n<\/div>\n<\/div>\n And we can commit that file into the repository. Currently, the file exists on the hard drive, but the reposiotry knows nothing about it. Let's tell the repository it exists (by Notice how helpful git is. It tells you that you can use At this point, we've told git that we care about this file, but we have actually committed the file into the repository\/history. Here goes:<\/p>\n<\/div>\n<\/div>\n<\/div>\n I used Fair enough. Now we could have Barb do a magic git command To resolve these issues, we'll use a "central repository" that we both communicate with. This also gives us an offsite backup for free, if you are using github or the equivalent. Note, my mockup demo here is not offsite (I sincerely hope I didn't have to tell you that)!<\/p>\n<\/div>\n<\/div>\n<\/div>\n Now, let's feed the new central repository. First, let's see who Mark's repo is setup to communicate with:<\/p>\n<\/div>\n<\/div>\n<\/div>\n I'm not connected to anyone else (sad face). Let's hook me up to the central repo for both pushing and pulling -- that is, sending and receiving updates to the repo.<\/p>\n<\/div>\n<\/div>\n<\/div>\n Now, we can tell Barb about the "central server" and she can make her own copy of it.<\/p>\n<\/div>\n<\/div>\n<\/div>\n Very often, when you are adding new stuff, you do it in a "branch". Why?<\/p>\n Enough talk, let's fight. Here, we're working as Barb.<\/p>\n<\/div>\n<\/div>\n<\/div>\n So, I (Mark) have been sleeping (!) and I wake up and want to start coding. Before I do anything else, I see if the repo has been updated -- I try to grab any work that Barb did overnight. Easy as pie:<\/p>\n<\/div>\n<\/div>\n<\/div>\n I was asleep and I'm still a bit groggy. I haven't had my coffee yet and disaster strikes:<\/p>\n<\/div>\n<\/div>\n<\/div>\n%<\/span> mkdir marks_code # I just spun up a new computer -- didn't you see it?<\/span>\n%<\/span> cd marks_code # and logged on<\/span>\n%<\/span> git init . # create a git repo here; currently empty<\/span>\nInitialized<\/span> empty Git repository in \/Users\/mfenner\/gitdemo\/marks_code\/.git\/<\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\ngit init<\/code> command. Incidentally, to get help on this command (on Unix-y systems), type man git-init<\/code>. git<\/code> is structured as "one big program" with lots of sub-commands (git init<\/code>, git log<\/code>, git diff<\/code>, etc.), but the man pages (help documentation) are made for each command. You specify it as git-<cmd><\/code> for whatever command cmd<\/code> you want to investigate.<\/p>\n<\/div>\n<\/div>\n<\/div>\n%<\/span> cat ><\/span> test.py\nprint<\/span> "Hello World!"<\/span><\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\nadding<\/code> it). First, we can take a look at what git<\/code> knows about with git status<\/code>.<\/p>\n<\/div>\n<\/div>\n<\/div>\n%<\/span> git status\nOn<\/span> branch master\n\nInitial<\/span> commit\n\nUntracked<\/span> files:\n (use<\/span> "git add <file>..."<\/span> to include in what will be committed)<\/span>\n\n test.py<\/span>\n\nnothing<\/span> added to commit but untracked files present (use "git add"<\/span> to track)<\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\ngit add<\/code> to add a file. Let's do it:<\/p>\n<\/div>\n<\/div>\n<\/div>\n%<\/span> git add test.py\n%<\/span> git status # git will also tell you how to "unadd" test.py<\/span><\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n%<\/span> git commit -m "Added hello world functionality"<\/span><\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n-m<\/code> to specify the commit message (a note about what the reason for this current commit). If you don't put something in there, git will dump you into an editor and let you type a message in. Now would be a great time to try out: git log<\/code>, git show<\/code>, and git blame<\/code>.<\/p>\n<\/div>\n<\/div>\n<\/div>\ngit clone <path\/to>\/marks_code<\/code> and she would get a (standalone) copy of the repository. There are two issues with this approach:<\/p>\n\n
%<\/span> cd .. # go up one level (out of marks_code)<\/span>\n%<\/span> mkdir central # create a server<\/span>\n%<\/span> cd central # and login (ha, easy!)<\/span>\n%<\/span> git init --bare # create a special type of repository<\/span>\n # that won't be used by anyone locally<\/span><\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n%<\/span> cd ..\/marks_code # go back to mark's laptop<\/span>\n%<\/span> git remote -v # who are my remote connections (currently none!)<\/span><\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n%<\/span> git remote add origin \/Users\/mfenner\/gitdemo\/central # link the repos<\/span>\n%<\/span> git push --set-upstream origin master # link the master branches<\/span>\n # (and send my repo as an update)<\/span><\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n%<\/span> cd ..\n%<\/span> mkdir barbs_code &&<\/span> cd<\/span> barbs_code\n%<\/span> git clone \/Users\/mfenner\/gitdemo\/central\n# cloning creates the tailing directory name and puts the repo in it<\/span>\n%<\/span> cd central\n%<\/span> git log --oneline<\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n\n
master<\/code> as a (hopefully) 100% working version of the code.<\/li>\n%<\/span> git branch # view current branches<\/span>\n%<\/span> git branch add-function # create a new branch called ... and activate it<\/span>\n%<\/span> git branch\n\n# update test.py and testmod.py<\/span>\n%<\/span> cat ><\/span> testmod.py\ndef<\/span> foo(x,y):<\/span>\n return<\/span> x + y\n%<\/span> more test.py\nfrom<\/span> testmod import foo\n\n%<\/span> print "Hello World!"<\/span>\n%<\/span> print foo(3,5)\n\n# Now, get those changes stored away!<\/span>\n%<\/span> git add testmod.py\n%<\/span> git commit -a # -a does "auto-add stuff git knows about"<\/span>\n\n# Now, switch back to the boring, old master<\/span>\n%<\/span> git branch master\n%<\/span> ls # why is testmod.pyc around? <\/span>\n # it is "just" a file on the disk, git doesn't know about it<\/span>\n\n# merge our new functionality (after testing, of course!)<\/span>\n%<\/span> git merge add-function # merge named branch onto current branch<\/span>\n%<\/span> git status # barb's gotten ahead of the remote master<\/span>\n%<\/span> git push\n\n# Barb can also clean up the (no longer needed) development branch<\/span>\n%<\/span> git branch -d add-function<\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n%<\/span> git pull<\/code><\/pre>\n<\/div>\n<\/div>\n<\/div>\n