Git is not (just) Source Control

After many discussions with a colleague about Git, I came to realize that Git is not merely a source control. With time it became a tool in my developer’s sandbox. To develop software effectively, I need (among other) an IDE or text editor, a prompt and countless libraries. I came to rely and trust these tools.

I used many other tools for version control but I saw them as infrastructure – mandatory in the grand scheme of things but not used to improve my productivity.

Git changed everything by allowing me to rethink the way commits and branches work.

  • By promoting small commits that do one thing but do it well, git forces me to split my task in even smaller chunks that can then be commited. This sometimes leads to architectural changes.
  • By making it possible to  reorder the commit history (git rebase -i origin), it pushes me to make each commit clean and atomic.
  • Git makes branching cheap and easy. Like you, I try to code each features in a separate branch. But unlike you, I am undisciplined and often forget. However if I start on a feature and realize it takes slightly longer than expected (and I’m talking about an hour max, not 3 days), I create a branch for that feature. It’s easy and it allows me to work in small, independent chunks. It also allows me to always be able to come back to a stable branch if I need to do a few quick fixes on another part of the project.

Git is not a mere tool – it changed the way I design and code.

4 Responses to “Git is not (just) Source Control”

  1. I have been extremely happy with git as well. At one point I played around with Fossil, hg and bzr but I have settled on git.

    I use just a couple of features and have a lot to learn about the tool. It has been amazing so far. I’m still in a discovery mode of sorts. Just recently I came by a way to modify commit messages using “git commit –amend”.

    I have yet to get into habit of branching properly. It probably would be a nice idea to check commit messages before a push as well.

    Can you expand on your point about reordering commit history? What are the benefits, how do you do it in practice (on command level)?

  2. Reordering the commit history can be done with the command ‘git rebase -i origin/master’ supposing you are in the branch ‘master’ and you have some commits that have not been pushed.

    This open your favorite text editor with a list of all the local commits. You can reorder the lines if you want to change the order of your commits.

    The command allows you to do a lot more – among other you can merge commits together or change the commit message. This is like having a more powerful ‘git commit –amend’ as you can move related commits together then merge them. Very useful if you do commit A, then commit B, then realize that you’re missing something from commit A (a test, documentation, a typo, whatever). Just commit ‘C’ then use interactive rebase to to move A and C together and commit them together in a single commit ‘D’ (it’s called squashing). Then you have a clean history in git log, eg ‘commit A’, ‘commit B’ instead of ‘commit A’, ‘commit B’, ‘commit that fixes something in A’

    It’s a small thing, but I came to find that small things matter a lot.

    Hope that clears things up a bit

  3. I just tried out your tip. It worked just great! I will definitely use this trick (rebase) a lot more in the future.

  4. Glad that helped you :)

Leave a Reply