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