Git branches with completely different content

Question

Since Git has the ability to keep track (and keep it clean) of branches with completely different content from each other, in the same repository, some projects (like Git itself) have started to make use of it.

Git, for instance, uses one branch for the code itself, while keeping its documentation in a separate branch. Same repo, just different branches.

It might just be me, coming from a SVN background, but I find it confusing to have 'nothing in common' in those branches. Development/staging/production branches; those I understand. Branches for incomplete features; sure, I'm doing those too. Heck, have your documentation with one branch per language. But no files in common?

Is this just (perhaps an underused and/or undermarketed) feature in Git, that everyone should embrace and get used to, or a possibly dangerous misuse by someone being lazy of not differentiating two aspects of the same project enough?

Answer 1

I personally would not store different content in different branches; in the case of docs and code, I would just make a myproject.git and a myproject-docs.git (and sub-module the docs into the code if it was necessary for the build process).

On the other hand, nothing bad will happen if you do this. Git is not going to tell you what to do, so you are free to make your own decision on how you want to use it. So to answer your question, it's neither a killer feature, nor something that will bowl you over if you are not careful. It's just how someone choses to use it.

Answer 2

Git tracks coordinated changes in (text) files within a project, so it doesn't know or care whether branches are mergable or not. Having independent branches in a Git repo is similar to having independent projects in a Subversion repo, which is a common practice (because of svn's overhead).

Because Git's data structure is very different than SVN's, you can do different things with them. In SVN a feature branch is somewhat unusual, and a feature branch which is not often merged to the trunk might be a "bad smell", a sign that the programmer has "gone dark" and is creating code that may never be able to be integrated into the project. In Git, a feature branch is a perfectly safe and sensible workflow.

So they can be used in different ways because Git is not SVN even though both have repositories and branches and commits, and serve the same general function of source control.

As I got more experience of Git, what had been weird just became different. Then I got curious about what I could do with that different tool.