When we left off, you had just finished transforming a remote Subversion repository into a git repository and optimizing it to save you some space. Now that you have a git repository, what do you do?
First things first. Once you have an idea of what work you want to do, you should give yourself a space to do this work without disturbing anybody else’s work. Do this by making a new, personal branch. Unlike Subversion and some other centralized version control systems, git makes it possible to do make all kinds of changes to your repository, including making branches, and even save those changes without having to republish everything back to the central repository server at each step. In other words, if you thought Subversion branches were “cheap,” you’ll love git’s branches.
Also unlike Subversion, which stores its branches in completely separate pathnames, git keeps all branches in the same filesystem tree separated only with metadata (in
.git/refs/remotes for remote branches and in
.git/refs/heads for local branches, to be a bit more precise), so you don’t have to create lots of different directories for all your branches (unless you want to). With no branches defined, you’re working in the “master branch,” or “the trunk” by default.
git branch * master
git branch you ask git to print a list of all (local) branches. The one with the asterisk marks the current branch, the one you’re using at the moment you run the command. Since there are no branches, you’re currently in the “master” branch. But we don’t want to make changes here, we want to make changes in our own private branch, so we’ll make a new one.
git checkout -b new_branch_name
This will create a new branch with the name new_branch_name and immediately switch to it. Notice that you’ve made absolutely no changes to the filesystem itself; only the git metadata has been altered. Saying
git branch again will show you the change:
git branch master * new_branch_name
Also note that since we haven’t comitted any changes, we don’t need a commit message (or “log message”) for creating this branch. We’ll add one later, when we need it. Now go ahead and write some code in your new branch. At any time, you can create a new branch in the same way you added the first. Each new branch is created at the
HEAD (“latest”) revision of whatever branch you’re currently working in.
git checkout -b another_branch Switched to a new branch "another_branch" git branch master new_branch_name * another_branch
To switch back to any other branch, simply
git checkout that branch again:
git checkout master Switched to branch "master"
If you want to delete a branch you don’t like, that’s easy too:
git branch -d another_branch Deleted branch another_branch.
Keep in mind that throughout all of these branch creation and deletion actions, the only thing that’s being altered is the git metadata. That’s why it’s so cheap to create new branches. If you ever have a new idea you’re working on, it’s recommended that you create a branch for it, even if that branch is so short-lived it never gets published.
So you have a new local branch, and you’ve been working as you normally do for a few minutes, creating files, editting them, and so on. Running
git status now will ask git to show you the changes you’ve made to your filesystem. If you’ve created any files in new directories that git doesn’t know about, it will simply report that directory. If you’ve made new files in directories git does know about, it will list all those files explicitly.
git status # On branch cartoon_contests # Untracked files: # (use "git add
..." to include in what will be committed) # # sites/default/modules/cartoon_contests/ # sites/default/modules/factiva/.factiva.module.swp # sites/default/modules/testfile # sites/default/settings.php nothing added to commit but untracked files present (use "git add" to track)
In the above sample output, I’m working on a new Drupal module for a web site. I’ve created a new directory,
sites/default/modules/cartoon_contests/ (note the trailing slash), and I have several untracked files. One is my vim swap file for a different module,
.factiva.module.swp, one’s an unimportant
testfile, and the last is the Drupal configuration file,
The only thing I want to commit is the new
cartoon_contests directory, and all the files within it. Like Subversion, I have to tell git that I want to track this directory, which is done simply by saying
git add cartoon_contests. Unlike Subversion, future invocations of
git status let me see everything that git is going to go in the next commit.
git status # On branch cartoon_contests # Changes to be committed: # (use "git reset HEAD
..." to unstage) # # new file: sites/default/modules/cartoon_contests/cartoon_contests.info # new file: sites/default/modules/cartoon_contests/cartoon_contests.module # # Untracked files: # (use "git add ..." to include in what will be committed) # # sites/default/modules/factiva/.factiva.module.swp # sites/default/modules/testfile # sites/default/settings.php
The “Changes to be committed” section of the output is called the staging area, or the index. In this way, I can prepare all the changes I want to commit before I do so, making sure they’re perfect before I actually commit them to the git repository. At any time before I commit, I can make additional modifications, such as
git adding more files or directories,
git reseting to unstage all (or some) of my changes, etc.
git help reset also has a number of handy explanations with examples for different things you might need to do at this point.
If you were using
svn:ignore, equivalent functionality exists in git. Simply append file glob patterns, one per line, to the
$GIT_DIR/info/exclude file in your git repository. Like so:
echo -e "*.swp\nsites/default/settings.php" >> .git/info/exclude ; git status # On branch cartoon_contests # Changes to be committed: # (use "git reset HEAD
..." to unstage) # # new file: sites/default/modules/cartoon_contests/cartoon_contests.info # new file: sites/default/modules/cartoon_contests/cartoon_contests.module #
If you’ve got many of these, you can use
git svn show-ignore >> .git/info/exclude to search through your old Subversion repository and look for any and all ignores, automatically adding them to git’s exclude list. (Checkout Tsuna’s blog entry on learning git for more tips like this.)
Finally, after you’ve done some of your work and you’ve finished staging your changes, you’re ready to commit them to the repository. On the other hand, if you hate what you’ve done and want to undo it all, you can say
git reset --hard HEAD to throw away all your local changes. To throw away changes to just a single file, just checkout that file again by saying
git checkout filename. This is the equivalent of Subversions
svn revert filename command.
Before you actually make your first commit, however, you should properly introduce yourself to git. You don’t have to do this because git will try to figure out who you are by itself (details explained in detail here), but you probably should at least create global defaults for your user (which git will store in
~/.gitconfig). If you want to, you can also create per-repository defaults (which git will store in
.git/config), or even system-wide defaults for all users of this computer (which git will store in
/etc/gitconfig). To do so, say this:
git config --global user.name "Your Full Name" git config --global user.email "[email protected]"
This will create the file
~/.gitconfig if it doesn’t alreay exist and will write your name into it. You can also just edit the file directly yourself instead of using
git config commands.
Like Subversion, committing will create a saved, fixed point-in-time that marks the changes you have made to your files. Like branches, commits are also very cheap in git, so go ahead and commit at any time you like. Remember to stage your files (by
git adding them), and then just
git add filepattern git commit -m "My very frst git commit!" Created commit ef483c1: My very frst git commit! 5 files changed, 58 insertions(+), 12 deletions(-)
If you forget to specify a commit log message (
-m "log message") on the command line, or if you want to enter a multi-line commit log, git will prompt you for it in your favorite
$EDITOR. You can view a history, including all the log messages, for your project with
git log. You can even the view logs in a number of pretty formats. Check
git help log for more information.
If you want to change anything about the commit you just made, such as the author, you can just run
git commit again with the
--amend flag added to the command. Notice the typo in the commit log? Fixing it is really easy:
git commit --amend -m "My very first git commit!" Created commit 88602f6: My very first git commit! 5 files changed, 58 insertions(+), 12 deletions(-)
Finally, with your new code commited to your local git branch, it’s time to share that code with your colleagues who are (for some inexplicable reason) still using Subversion. This is also extremely simple. Just say
git svn dcommit. (That’s right,
dcommit, not just commit. I don’t know why….)
Not sharing your changes via Subversion, but with a patch instead?
git diff -p will generate patches for you. See
git help diff-files and look for the “GENERATING PATCHES WITH -P” section.
If you found this helpful, you may also enjoy an alternative tour for beginners from Carl Worth.