So, you’ve got git installed, you have created (or cloned someone elses) repository, and you have done an initial commit of a couple of files. What are the day to day commands you’ll need to use on a regular basis? This posting looks through some common tasks and how to accomplish them simply using git. It’s not focused on some of the cooler features in git – just getting you passably productive in as few commands as possible.
Create a Branch
Before you do almost anything to a live project, you’re going to want to start to create a branch. By default you’re on “master” (which is similar to the “trunk” convention in subversion). Unless you’re just doing a quick patch that needs to be tested and deployed immediately (e.g. a quick bug fix for the production server) you’re going to want to create a branch for your work. That way if you *do* need to move to another story, you’ll be able to put aside the code you are working on in a branch and to return it easily. It also means that master will always be deployable. If you ever make changes to master, master then becomes unavailable for deployment until you’ve finished and tested your work, so a 5 minute patch might take a week to deliver if you have a bunch of half finished code in master.
Lets say we want to implement a “user authentication” story for our site. We’d start by creating a branch: “git branch user-authentication”. We’ve now created a branch called “user-authentication”. Type “git branch” and you’ll see there are now two branches – master and user-authentication. You’ll see from the * next to master that while we have created a user-authentication branch, we haven’t switched to it yet (the * denotes which branch you are currently in).
So, the next step is to “git checkout user-authentication” and both a “git branch” and “git status” will show (in their own ways) that you are on the user-authentication branch. Lets add a new file – login.txt that relates to user=authentication, then “git add .” and “git commit -m ‘added login notes'”.
Now we have a branch with an extra file. Imagine you now need to make a quick patch to master and deploy it. All you do is “git checkout master” and you’ll see the login.txt is gone. Now imagine that was a bunch of changes to your core code that would have broken your unit tests/website. Now we can make a tweak to our master branch, deploy from that and then simply “git checkout user-authentication” to get back to the user-authentication story.
You’ve done a little more work on the user-authentication story and you want to capture all of the changes so you can revert to this point. Simply “git add .” and then “git commit -m ‘meaningful commit message'” and you’re done. With git you can afford to commit changes really often as later you’ll be able to use the rebase command to collapse down the number of commit messages (although we’re not going to cover that in this 101 tutorial). If in doubt, commit. Note that if all you are doing is editing existing files, you can just collapse down the two commands to a single “git commit -a -m ‘commit message'” (note the “-a” flag), but that won’t pick up any untracked files, so if in doubt, just do both steps. (Some UI based tools like the git commands in TextMate will automatically handle the git add as part of the commit.)
Ugh. We’re still on the user authentication story. We have done a lot of work and committed regularly, but since the last commit we tried some different things and they weren’t very good. Worse, we can’t remember how to get the code back to the last commit which was working (although not complete). It’s time to roll back to an earlier commit (it’s git and commits are cheap and easy, so you might be a couple of commits into this path). If you “git log” you’ll see a list of previous commits – each of which has a GUID like df9e8fd2a1d3769e42012a29f0ac4b56f6053a62. Lets say we wanted to revert back to the commit with that GUID. All we do is “git reset df9e8” (note that we just needed a few characters – enough to uniquely identify the element) and it reverts to the status of the branch at that time, allowing you to get back to a known good state and to try something else.
Of course, if you’re doing something experimental, you might just want to create a branch – “git branch user-authentication-experimental-login” and then “git checkout user-authentication-experimental-login” so if it doesn’t work you can just “git checkout user-authentication” and then delete the experimental branch using “git branch -d user-authentication-experimental-login” (if the branch wasn’t a child of the current branch you’ll need -D, not -d).
Merging a Branch to Master
OK, so we’re finally happy with our new user-authentication branch. Let’s merge it into master. From the user-authentication branch we’re going to “git checkout master” to get back to the master and then “git merge user-authentication” to merge the user authentication branch into the master.
Tagging a Release
Often there will be special points you want to tag – such as production releases. When you want to create a tag, just type “git tag release1” (where release1 is the name you want to give it), and then to revert to that tagged point at any time, you can just “git checkout release1”.
Pushing Your Changes
If this is a shared project, you may want to upload your files to Unfuddkle or github. Depending on exactly how your project is setup this may well be as simple as just typing “git push”, which will update all branches on the remote location with those from your local copy.
There is a lot more you can do with git. The default documentation is at http://book.git-scm.com/, although there are also many other tutorials available. Any feedback or questions appreciated!