Everyone should stop making sweeping statements about what everyone should do.
Snark aside,
> Long running branches are bound to happen, [...] Good communication comes in handy here if you are working on long running feature branches.
How about this: Instead of having long running branches, don't have long running branches. Everyone runs on the same master branch, and master is always deployable. This way you don't need to communicate (yes you do, but the sort of communication alluded to is secondary, the full, up-to-date code with tests is the authoritative source). Have features that you can turn on and off in configuration, it's not like having branches ensure that you didn't screw anything up.
This is how my company currently operates. It works well for us, BUT we do have some tools/methods to help us along the way. One of which is staging and production trees.
We are using perforce, so cross folder integrations are very simple with branch specs.
We'll have one folder named 'staging' where all development happens. Yes, the label isn't quite right. We can deploy this code to a 'staging' environment and test. When we're happy, we can integrate into the production branch and deploy.
These integrations are always one way; they go from staging -> production only. There are no conflicts to deal with. We also get the benefit of cherry picking updates to push in an emergency.
I recently evaluated different CSS-preprocessors for one of our projects. This included not only changing and renaming a bunch of CSS-files, but also adding new dependencies, updating Makefiles, etc. We ended up going with the first one we tried, but it was a tough call so we might've wanted to revert it completely. Isn't this a perfect use case for a branch?
We had previous experience with the preprocessors, but they behaved differently used in our context with modularized CSS, lots of imports, using our custom watch script, etc, so we had to try them out in the actual project.
A long running branch is usually a feature branch that is worked on over a long period of time. Just committing everything to master is asking for trouble.
There are some long running branches that are difficult to avoid...a typical one might be moving between some very key infrastructure piece (going from ruby 1.8.6 to 1.9 for example or python 2.7 to python 3).
The biggest problem I have with branches in git is that there does not seem to be a simple way to delete a branch in a version controlled way.
For me, the whole point of version control is to be able to go back and look at what I did earlier. The idea of doing destructive deletes of branches is madness. However, if you don't, you end up in the situation I have now, where my project has over a hundred branches, most of them minor changes or attempts at things that didn't pan out.
The overhead this causes (including, just scrolling through the list of branches) now makes me less eager to branch in new projects I work on. In svn, I would just do 'svn rm branches/stupid-idea' and it would be gone, but still exist in the history if I ever wanted it.
You can always replace the branches with tags (git tag failed-branch-mybranch mybranch && git branch -D mybranch). That way, you still will have access to the unmerged commits later, but your list of branches is clean. Your tags will bloat up, but I personally don't go through my tags nearly as often as my branches.
You don't necessarily want to publish all branches to your main project repository, just long-running ones or those that many people hack on. For most branches, especially experiments, use a branch in a personal repository instead. You can merge from that repository to the main repository if the experiment works out, and otherwise leave it around as an experimental repository and/or archive it. Look at git.kernel.org for an example: linux/kernel/git/torvalds/linux.git only has a "master" branch, but numerous other repositories exist for experiments and development.
That said, I'd also love to see a mechanism for version-control of historical branches. Perhaps something like a reflog with expiration turned off.
You can namespace your branches. Once you're done with one, you can rename it to merged/essential-dingbats-feature or discarded/dingbats-are-in-fact-useless.
Some, like the authors of Continuous Delivery (http://continuousdelivery.com/) seem to be arguing against branches, and for a single codebase that is continuously tested, integrated, and releasable.
That said, private branches can make it easier for people to commit early and often, as all changes can easily be squished together so others don't have to see every "embarrassing" iteration.
Utilizing branches heavily does not imply that you shouldn't have a single mainline branch that branches are merged down to often. In fact, it's incredibly difficult to do continuous integration and deployment effectively without branching. Continous delivery requires that your mainline codebase is pristine and ready to be deployed immediately. Without the ability to make commits that don't affect that mainline, that's an unrealistic expectation.
I would say the authors probably have an issue with long-running branches, especially where communication between the mainline and the branch is sparse, but short-lived branches have a ton of benefits if you're deploying continuously.
My (8 person) team is currently developing software for a machine. It's the first version, in fact the machine hardware doesn't even exist yet.
Instantly deployable code is, therefore, of no interest to us (currently). Things'll be different when we have releases out, installed in machines at customers, but for now, really, why branch? The author does not actually give any other argument for branching, except for "master should be instantly deployable". And even that problem could be solved in other ways than e.g. feature branches.
In fact, we want to take continuous integration to extremes. This means that if I work on X and George over there works on Y, and we end up breaking each other's code, I want to find out as fast as possible. Not when my feature is done. Today.
Less branching directly implies earlier feedback. We've yet got to hit the problem that people are really messing in the same code, big time, at the same time - after all, that's what the daily standup is for, right?
Branches are a method for organization. I organize papers by putting them in a stack on my desk. If the stack gets too big I throw them in a box, intending to go through them later. But of course I never do. This is obviously a horrible scheme, but I get by just fine because the volume of truly important papers I deal with is small. It surely wouldn't scale. Even so, more orderly people are probably cringing as they read the above, and to some degree they're right.
But I write code for a living, and I spend more time cleaning up my file system, organizing source code, et al. I do this because I know that not doing this ends up as more work than doing it. I use branches so that when I'm in the middle of implementing a feature and a user comes to me with a bug report I do not have to sweat having half refactored, half implemented, uncompilable stuff. I can switch branches and work on the bug. Ditto for interfacing with other devs working in other parts of the code.
Finally, I have to wonder if you've used branches enough to get a feel for what they can do for you. I know that using CVS and Subversion I avoided branching as a scary and tricky thing. Having them work so easily in Git I began branching and found that it changed my workflow for the better in a fairly painless way.
Unlike centralized version control, DVC systems also have another available topology namely separate repositories. I guess some teams may rethink their branching strategy once they experiment with multiple repository topologies.
I'd much rather see people making better use of tags. I inherited a git-based project recently where branches were being used as a sudo-tag to indicate what code was currently deployed to each server environment, but no tagging of releases whatsoever :-(
Tagging is useful for libraries and such. But for web sites and the like, you can just use the deployed commit SHA as an identifier. Much like GitHub does https://github.com/site/sha
[+] [-] mseebach|14 years ago|reply
Snark aside,
> Long running branches are bound to happen, [...] Good communication comes in handy here if you are working on long running feature branches.
How about this: Instead of having long running branches, don't have long running branches. Everyone runs on the same master branch, and master is always deployable. This way you don't need to communicate (yes you do, but the sort of communication alluded to is secondary, the full, up-to-date code with tests is the authoritative source). Have features that you can turn on and off in configuration, it's not like having branches ensure that you didn't screw anything up.
[+] [-] garyrichardson|14 years ago|reply
We are using perforce, so cross folder integrations are very simple with branch specs.
We'll have one folder named 'staging' where all development happens. Yes, the label isn't quite right. We can deploy this code to a 'staging' environment and test. When we're happy, we can integrate into the production branch and deploy.
These integrations are always one way; they go from staging -> production only. There are no conflicts to deal with. We also get the benefit of cherry picking updates to push in an emergency.
[+] [-] jacobr|14 years ago|reply
I recently evaluated different CSS-preprocessors for one of our projects. This included not only changing and renaming a bunch of CSS-files, but also adding new dependencies, updating Makefiles, etc. We ended up going with the first one we tried, but it was a tough call so we might've wanted to revert it completely. Isn't this a perfect use case for a branch?
We had previous experience with the preprocessors, but they behaved differently used in our context with modularized CSS, lots of imports, using our custom watch script, etc, so we had to try them out in the actual project.
[+] [-] tombell|14 years ago|reply
[+] [-] ironchef|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] CJefferson|14 years ago|reply
For me, the whole point of version control is to be able to go back and look at what I did earlier. The idea of doing destructive deletes of branches is madness. However, if you don't, you end up in the situation I have now, where my project has over a hundred branches, most of them minor changes or attempts at things that didn't pan out.
The overhead this causes (including, just scrolling through the list of branches) now makes me less eager to branch in new projects I work on. In svn, I would just do 'svn rm branches/stupid-idea' and it would be gone, but still exist in the history if I ever wanted it.
[+] [-] rudd|14 years ago|reply
[+] [-] JoshTriplett|14 years ago|reply
That said, I'd also love to see a mechanism for version-control of historical branches. Perhaps something like a reflog with expiration turned off.
[+] [-] obtu|14 years ago|reply
[+] [-] tombell|14 years ago|reply
[+] [-] bergie|14 years ago|reply
That said, private branches can make it easier for people to commit early and often, as all changes can easily be squished together so others don't have to see every "embarrassing" iteration.
[+] [-] ryanbrunner|14 years ago|reply
I would say the authors probably have an issue with long-running branches, especially where communication between the mainline and the branch is sparse, but short-lived branches have a ton of benefits if you're deploying continuously.
[+] [-] noidi|14 years ago|reply
[+] [-] skrebbel|14 years ago|reply
Instantly deployable code is, therefore, of no interest to us (currently). Things'll be different when we have releases out, installed in machines at customers, but for now, really, why branch? The author does not actually give any other argument for branching, except for "master should be instantly deployable". And even that problem could be solved in other ways than e.g. feature branches.
In fact, we want to take continuous integration to extremes. This means that if I work on X and George over there works on Y, and we end up breaking each other's code, I want to find out as fast as possible. Not when my feature is done. Today.
Less branching directly implies earlier feedback. We've yet got to hit the problem that people are really messing in the same code, big time, at the same time - after all, that's what the daily standup is for, right?
Really, how would branches help us in any way?
[+] [-] dwc|14 years ago|reply
But I write code for a living, and I spend more time cleaning up my file system, organizing source code, et al. I do this because I know that not doing this ends up as more work than doing it. I use branches so that when I'm in the middle of implementing a feature and a user comes to me with a bug report I do not have to sweat having half refactored, half implemented, uncompilable stuff. I can switch branches and work on the bug. Ditto for interfacing with other devs working in other parts of the code.
Finally, I have to wonder if you've used branches enough to get a feel for what they can do for you. I know that using CVS and Subversion I avoided branching as a scary and tricky thing. Having them work so easily in Git I began branching and found that it changed my workflow for the better in a fairly painless way.
[+] [-] Toenex|14 years ago|reply
[+] [-] j_col|14 years ago|reply
[+] [-] tombell|14 years ago|reply