If you check in code that breaks the build, then go home, and then someone else checks it out, they can’t get anything done till you return and fix it.
A problem that Jenkins Build-per-Branch¹ nicely obviates.
While I agree with the author that feature branches are useful, I think he went too strongly the other way, against feature toggles.
Feature toggles allow you to do things like: 1) deploy only to certain users. 2) incrementally deploy to N percentage of your users. i.e. deploy to 1%, then 10%, then 100%. These are things that absolutely cannot be done by your VCS system.
If you're going to use FTs, then yes, they need to be baked in and well supported by your app. A consistent API & tooling are a good idea.
FWIW, at CircleCI (https://circleci.com), we use feature branches all of the time. We automatically CI all branches, and we use feature toggles. In fact, I'm toying with the idea of a feature-toggles-API-as-a-Service.
Feature branches are almost the opposite of continuous integration. If you're committing to a branch then by definition you're not integrating your changes with people working on other branches.
It's quite possible to integrate and deploy changes to production several times a day. If it hurts, do it more often. Smaller changesets are far easier to merge.
OK, let me throw this out there: what if you're developing a feature that takes longer than a fraction of a day to write, and you want that feature to be developed independently of any other half-baked features that are out there?
Or developing more than one feature at a time?
Or you are halfway through developing a major feature when you suddenly realize there's a high-priority bug that has to be fixed first?
Or you decide halfway through developing a major feature that you went about it all wrong and made a hash of everything and want to start from scratch?
> If you're committing to a branch then by definition you're not integrating your changes with people working on other branches.
When other people's changes are merged to integration, I'll rebase off of integration and resolve any conflicts then and there. No problem.
> Smaller changesets are far easier to merge.
...and since I'm continuously rebasing off of the integration branch, all my merges are fastforward, which is even easier.
The criticism against feature branches makes sense if it's coming from people who don't use Git fluently. Otherwise it's absolute nonsense.
Honestly, no. This is how we work in a combined mainline branch while only using feature branches for relatively rare work that extends beyond a single subsystem and would break other people.
By and large we can keep mainline in a stable and releasable state, which has some advantages in terms of forcing people to take care and keep their code clean as they work.
For stable releases, we just peel off a release branch and stabilize there. The fewer branches we have, the simpler it is to keep track of everything.
Oh, you're just talking about the central repo server. Yeah, I wouldn't push feature branches to origin either, but I definitely still have them locally. They end up rebased, squashed, fast-forward merged, and pushed only to the mainline anyway, so no one need be the wiser.
But "if the unit tests pass, it's safe to commit" is a very...questionable sentiment. It makes sense if you do release branches, and if you have very good test coverage, and if there isn't a lot of tricky stuff that's hard to capture in unit tests--that's just is a combination I've yet to encounter and largely consider to be mythical. I'd love to be proved wrong on that point.
I wonder, where in your process does code review come in?
> Oh, you're just talking about the central repo server. Yeah, I wouldn't push feature branches to origin either, but I definitely still have them locally. They end up rebased, squashed, fast-forward merged, and pushed only to the mainline anyway, so no one need be the wiser.
We actually use SVN. It is considered negatively impacting on communication to have work hidden on local DVCS branches instead of immediately visible to the team upon commit.
This requires one to commit often, in very small chunks, while driving from a test-first perspective. In the cases where that isn't possibly (highly experimental work), a branch will be used.
> But "if the unit tests pass, it's safe to commit" is a very...questionable sentiment. It makes sense if you do release branches, and if you have very good test coverage, and if there isn't a lot of tricky stuff that's hard to capture in unit tests--that's just is a combination I've yet to encounter and largely consider to be mythical. I'd love to be proved wrong on that point.
Inadequate unit test coverage or missing documentation would be considered a serious offense here.
The only code that winds up being difficult to capture in unit tests is usually GUI code (or in the case of web development, the HTML/CSS front-end bits). The testing and validation of those pieces happens outside this process, usually driven by basic automated integration testing and the watchful eye of the design department.
The UI code is expected to be minimal and only involved in the UI. All significant work occurs in the testable backend code.
> I wonder, where in your process does code review come in?
After commit, diffs on the mailing list are reviewed, but not formally. If someone thinks something needs another set of eyes, they ask explicitly.
A problem that Jenkins Build-per-Branch¹ nicely obviates.
¹http://entagen.github.com/jenkins-build-per-branch/