34

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?

BenMorel
  • 34,448
  • 50
  • 182
  • 322
Henrik Paul
  • 66,919
  • 31
  • 85
  • 96
  • 1
    Since subversion treats everything as a folder, is it not confusing that different folders can have completely different contents? – Matt Connolly Jul 25 '11 at 23:22
  • **See also:** https://stackoverflow.com/questions/600079/how-do-i-clone-a-subdirectory-only-of-a-git-repository – dreftymac Nov 14 '19 at 17:23

7 Answers7

19

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.

Dave Jarvis
  • 30,436
  • 41
  • 178
  • 315
jrockway
  • 42,082
  • 9
  • 61
  • 86
  • well, by not being careful, I could always merge the docs-branch with the source-branch, and that'd mess things up pretty well, I'd imagine. Or then Git would just throw up and halt. OTOH, there's always the rollback... – Henrik Paul Jan 21 '09 at 18:11
  • Yes, but you won't actually lose any data, you will just have a branch that doesn't make sense. This is why I'd avoid it, but it is not necessarily a deal-breaker. – jrockway Jan 21 '09 at 18:19
  • @wolfie, if you tried the merge it would throw conflicts on every line of every file and tell you to fix it. It would be pretty obvious you messed up and backing out is only `git reset --hard` away. – Otto Jan 21 '09 at 18:52
  • 12
    I don't think you get any conflicts at all from an accidental merge if the files are totally different. – T.E.D. Jan 22 '09 at 16:19
  • 2
    Subversion did not tell me what to do either. But when it came time to transfer everything to git, every tool I tried was built around the expectation of the SVN repo having /trunk, /tags, /branches. So while you may be free to do whatever you want, you really need to check with git experts to make sure you're doing what the creators expect you to do. – thinsoldier Aug 08 '14 at 15:08
  • I just want to add my 2¢: I always like to execute "git branch foo" before any merge or other operation that could lead to trouble. Then, no matter how badly it goes sideways, "git reset --hard foo" will get you home again. – Edward Falk Apr 17 '16 at 16:33
12

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.

Paul
  • 16,255
  • 3
  • 33
  • 25
  • 3
    +1 for "Git is not SVN" - especially considering that the workflow is night-and-day different. – BryanH Jan 17 '13 at 22:31
9

I'd say it's more like a lazy workaround for the fact that Git can't currently handle having multiple projects stored in the same repository. You can do it, but there's no way to pull down just the one you want.

I say "lazy", because it wouldn't have been too horribly tough to add the feature when the git developers themselves discovered a need for it (for storing docs). Since they used this weird branch hack, their incentive to fix the issue for everyone else has abated significanly.

T.E.D.
  • 44,016
  • 10
  • 73
  • 134
  • This is wrong and has always been wrong. You can fetch specific histories and have always been able to fetch specific histories. – jthill Jun 24 '23 at 08:02
3

The benefit to doing this, is that it's possible to pull only the docs branch if that's all you're interested in. Like jrockway said, you can do this using another repository and submoduling if necessary, but with this ability to create a 'naked' branch, you have the option not to.

Personally, I'm still on the fence about this. I understand why it could be beneficial, but I'm not wholly convinced it's the best way to go.

foxxtrot
  • 11,214
  • 4
  • 27
  • 27
3

I think it depends on what your project is.

Git is obviously a community OSS project so having the docs in the (same) repository so everyone gets them makes sense (to me).

On the other hand I would not store the docs for my projects at work as I would rarley edit them except on 'let's update the docs' type of ticket. At work I don't want my docs intermingled with my source, I just want the source (typical programmer view i know).

Others may want them all-together. I think you just need to realize what it means (remember everyone has a full copy of the repository) and pick the best option for your project.

Andrew Burns
  • 13,917
  • 9
  • 40
  • 42
2

It's a little weird when you're used to the Subversion model of presenting the tree to users, but once you get used to the model it's a lot less confusing.

A git repository is just a tree of objects that explain how to transform a directory from one state to another. Those objects have a parent. Some objects have two (or more) parents; merges. Some objects have no parent; the initial commit.

As I understand it, internally, Subversion's model is similar minus the concept of where merges came from. Those are just new commits with a handy command (svn merge) for getting a patch of the differences between two other commits.

I actually use this feature rather often to manage config files that started from the same directory on separate hosts, like /etc/apache2. It's like saying, "this is the alternate start of this stuff, but it's been abandoned". It allows me to stash the state of some files before I overwrite them, but without having to worry about whether they merge right, or are even related to the master branch at all.

In Subversion I'd have to stow that backup in some un-related place (zip file somewhere) or in a subdirectory in the repository. Plus, in subversion, if I delete any reference to those files in the current view of the tree it becomes very hard to find them again.

Otto
  • 18,761
  • 15
  • 56
  • 62
0

An opinion and how i use it and why it may seem wrong. In my case i am building an API for a product. Now i want different capabilities or features and i want to separate each capability for sales. So i can charge differently for each upgrade while leaving the other branches in their original version state. All branches upgradable. $$ Examples: Version Main is for testing and development not released. Branch Version 1.0- has basic widgets. Branch Version 1.2- adds a new widgets. Branch Professional- all capabilities

Each with their own price point.

So for selling what you develop it is a great way to keep track.

Or you can have each branch as a clone others are working on to update the main branch, traditional. Seems to be what you're used to. More than one way to use something, ask any emergency room doctor about lower extremity x-rays. Remember when there's a will, get outta the way lol...

Best to you all.

Steven Bailey
  • 1
  • 1