I’ve realized that I don’t blog very often because I tend to write very long and thorough posts. In an effort to try to start blogging more, I’m going to let myself off the hook some of the time and just write about something short. Perhaps this will get me more in the habit of writing, which will then lead to more in-depth posts!
Anyway, today in our lab meeting I gave a presentation on using git. As I was working on the presentation the past few days, I struggled with a way to answer a question which I’ve been asked multiple times:
Why does it take so many steps to make a commit?
If you are not working with a remote repository, creating a git commit will look something like this:
git statusto check what’s been modified
git addto add new/modified files to the stage
git committo create the commit
(If you are working with a remote, you’ll additionally have to
push. If you’re unlucky and your local repository and the remote
repository have diverged, you might also need to
git pull; git
push. If you’re really unlucky, there will be a merge conflict that
you need to resolve in between the
git pull and
Even just three steps is quite a lot for a beginning git user to remember – and that’s just for a single commit! So, how do you justify this: why are there so many operations to do something seemingly so simple?
The answer is actually one of the reasons why git is so powerful: it offers you full control over what operations you are doing (in this case, in the form of the stage). To explain this, I came up with the following analogy:
Creating a commit is like putting some documents in a box and then taping the box shut. You want to keep the contents of your boxes relatively organized, so you don’t want to just put anything in any box – there should be some systematicity to it. So, even if you have a whole bunch of documents that need to go in boxes, you don’t necessarily want to put all those documents in the same box.
This the same idea behind staging in git: you don’t necessarily want
to put all your changes in the same commit. So, you can put some
things in a box (stage files with
git add), take things out if you
change your mind (unstage with
git reset), and finally seal the box
when you’re happy with what’s in it (commit the changes with
git status isn’t so much a part of the committing operation as
it is useful to see what changes are available to be committed. For
newcomers to git, rather than having them use
git status, it might
be more useful to let them use a GUI tool to visualize the changes
that they’ve made (I happen to be a fan of SourceTree
myself). While I do think people should be able to use git from the
command line, I do not always think it is necessarily the best place
to start when someone is first learning.