Wednesday, 10 April 2013

Storing branch names in git (so not Only the Gods will know which branches you merged)

tl;dr: a better git branching workflow under the bold sentence below.

So yesterday I enjoyed some of the Git Koans by Steve Losh (http://stevelosh.com/blog/2013/04/git-koans/). While I believe that the criticism is valid, I think it also misses the point about git.


Forget what you know about svn, mercurial or other version control systems when thinking about git. The fact that most people use it to version source code is irrelevant. Today I thought of a way to use git to store/merge and distribute the nginx configurations across our front facing webservers. We use git to version /etc , etc. So the big question here is: when will we see a perfect version control system for source code on top of the git data structure/algorithms?

I've been using git for almost two years, but only since reading the Pro Git book 6 months ago did I really understand any of it. The thing about git is:

a git repo is a data structure and the git commands are algorithms, and that's it.

But anyways, I wanted to offer a solution to the problem posed in "Only the Gods".

It is quite simple: when you create a branch, always start with creating an empty commit in that branch, like so:

git checkout -b BRANCH_NAME
git commit --allow-empty -m "created branch BRANCH_NAME in which we will ...."

That way, after merging, you will always have a reference to the branch names in which the commits were made. Seems like a good way to use the git system for versioning source code :)


Discuss this on HN.








Some more explanation if you need it:


In the git data structure branches are pointers to commits. Much like a variable in most programming languages, its name is irrelevant to the rest of the system. (I can hear you thinking: "But I work with variable names all the time, to me they are important!". Yes you're right, but like I said: forget about it and focus on what the algorithm does, at least for now). When examining a commit history using tig, we can trace the two commits involved in a merge operation:


You can see that the text of the merge commit already holds the branch names, but this is not guaranteed when you're merging remote branches or want to have a custom commit message.