Hi Jean-Paul, you make a good case but you can still use feature toggles even with feature branches and also all devs working on the master branch means that the build might be broken for a long time in some cases.
The biggest drawback though (which is mostly the reason GitHub and the others encourage feature branching) is having to deal with the increasing async nature of our work. More and more companies are distributed and some are even async.
It's doable to work on the master branch if all devs can talk to each other in a room or in a chat room in real time. "Sorry, I broke the build, I'm going to fix it" but what if you have multiple set of developers working on different timezones that may or may not overlap?
The build could be broken for hours if someone is unavailable or asleep.
This already can happen with important bugs that need to be fixed ASAP, adding the load of fixing a feature written by someone else because it impedes the work of those devs that are "online" seems an unnecessary burden.
It'll lead to commit messages like "commenting out feature X because I have no idea how it works but it's breaking the build". :D
I think it's a valid idea, I'm just not sure it works best with fully distributed and remote teams.
You make a valid point that "all devs working on the master branch" might no apply to all setups. You could be remote, async or even have newcomers in the team who need more structure and guidance before starting up and being up to the standard.
The way to mitigate that is to use branches, but not feature branches a.k.a "long lived branches". You would create a branch per logical piece of code that you want to merge in. Then merging goes through a continuous integration tool that lets the code in only if it does not break the main branch. You could also open a PR and have this go through a code review if needed.
The main idea remains: you diverge from the master branch for a short period of time: say 1 day max and then sync back in. This way you eliminate big merge issues and avoid the "unpredictable release syndrome".
The main idea remains: you diverge from the master branch for a short period of time: say 1 day max and then sync back in. This way you eliminate big merge issues and avoid the "unpredictable release syndrome".
Agreed! Short lived branches are what I interpret feature branches for. For a feature, as small as possible. I once worked in a place where every dev had their own long lived branch and multiple feature branches and it was a bit of a nightmare as you wrote about :D
Yeah when I think of feature branches I think of something that's around for a week or two at most. Committing stuff to trunk is hard because you can't make small, incremental commits that might be a bit sloppy. Having a feature branch can make saving your state less stressful because you don't have to worry about others seeing your commit that says "oops I broke this now it's good".
Yep, also confused here somewhat, always thought of "feature branches" as being around for anywhere from minutes to days at worst. GitHub has no mechanism for code-reviewing individual commits, so I don't know how you'd do reviews on the main branch anyways.
(For longer-term branches, I had thought the term was "project branch", which is a collection of feature branches.)
I have updated the title and added this to the introduction: "For the sake of clarity: this article assumes a feature branch will carry the whole feature you are developing and is a so called 'long-lived' feature branch that will last 1 week or more. It's not a "no branches at all" mantra."
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Jean-Paul, you make a good case but you can still use feature toggles even with feature branches and also all devs working on the master branch means that the build might be broken for a long time in some cases.
The biggest drawback though (which is mostly the reason GitHub and the others encourage feature branching) is having to deal with the increasing async nature of our work. More and more companies are distributed and some are even async.
It's doable to work on the master branch if all devs can talk to each other in a room or in a chat room in real time. "Sorry, I broke the build, I'm going to fix it" but what if you have multiple set of developers working on different timezones that may or may not overlap?
The build could be broken for hours if someone is unavailable or asleep.
This already can happen with important bugs that need to be fixed ASAP, adding the load of fixing a feature written by someone else because it impedes the work of those devs that are "online" seems an unnecessary burden.
It'll lead to commit messages like "commenting out feature X because I have no idea how it works but it's breaking the build". :D
I think it's a valid idea, I'm just not sure it works best with fully distributed and remote teams.
Hi Rhymes,
First of all thanks for reading!
You make a valid point that "all devs working on the master branch" might no apply to all setups. You could be remote, async or even have newcomers in the team who need more structure and guidance before starting up and being up to the standard.
The way to mitigate that is to use branches, but not feature branches a.k.a "long lived branches". You would create a branch per logical piece of code that you want to merge in. Then merging goes through a continuous integration tool that lets the code in only if it does not break the main branch. You could also open a PR and have this go through a code review if needed.
The main idea remains: you diverge from the master branch for a short period of time: say 1 day max and then sync back in. This way you eliminate big merge issues and avoid the "unpredictable release syndrome".
Cheers,
JP
Agreed! Short lived branches are what I interpret feature branches for. For a feature, as small as possible. I once worked in a place where every dev had their own long lived branch and multiple feature branches and it was a bit of a nightmare as you wrote about :D
Yeah when I think of feature branches I think of something that's around for a week or two at most. Committing stuff to trunk is hard because you can't make small, incremental commits that might be a bit sloppy. Having a feature branch can make saving your state less stressful because you don't have to worry about others seeing your commit that says "oops I broke this now it's good".
Yep, also confused here somewhat, always thought of "feature branches" as being around for anywhere from minutes to days at worst. GitHub has no mechanism for code-reviewing individual commits, so I don't know how you'd do reviews on the main branch anyways.
(For longer-term branches, I had thought the term was "project branch", which is a collection of feature branches.)
Thanks for the comments!
I have updated the title and added this to the introduction: "For the sake of clarity: this article assumes a feature branch will carry the whole feature you are developing and is a so called 'long-lived' feature branch that will last 1 week or more. It's not a "no branches at all" mantra."