Branches: Everyone Should Use Them
tomb.io
tomb.io
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.
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.
If everyone works in master, you try it, run the tests, and if they're green, you know it works for everybody. You don't risk breaking feature branch X that did a refactoring in a different direction in an overlapping area.
Of course, this implies that you adhere to a CD/CI philosophy. Code always compiles, all test always pass. If your process involves code being uncompilable, unintegrable or test breaking for substantial periods of time, you'll need branching.
Lets say person A and person B are working on two features both committing to master.
Person A commits some work to master and pushes to origin. Person B commits some work and pushes to origin. Repeat this a few times, now you want to scrap the feature person A is working on. How do you cleanly handle this?
That said, it seems you are suggesting that the workflow should be centered around rolling back features rather than commits? That being the case, if your feature spans multiple commits, then indeed you have something there. If your feature does not, branching probably isn't needed.
Sure, if you work in some sort of enterprise or corporate environment.
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.
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.
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.
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.
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?
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.