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 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."