4 ms·

I disagree with the author. Feature branches should not be long lived in the first place. If a feature branch encompasses more than a story of 1-5 story points

by K0nserv 11y ago

I disagree with the author. Feature branches should not be long lived in the first place. If a feature branch encompasses more than a story of 1-5 story points it's likely that it is too large in the first place. Once you dispel this notion that feature branches are allowed to be long lived all the other points fall as well. Since feature branches are merged to master frequently the problem of integration between multiple features is mitigated. Personally I find that the extra merge commits and the commit bubbles generated by this model make the log easier to read and it's clearer how the code came to be at the state it is. Additionally the PR/MR process codifies when code review should happen and it does not require an extra tool if a web based git UI is being used(GitLab, Github, Bitbucket). During the PR/MR the author can create many small commits with fixes to aid the review of incremental change after the initial full review. When the PR/MR is accepted a rebase on origin/master and heavy use of squashing removes the extra noise created by these smaller commits as well as resolves most problems with integration into to the master branch.

jroseattle 11y ago
This. This is the correct way to think about it. Ballooned feature branches suck either at merge time or at deployment time. The problem in either case isn't the model -- it's the balloon of changes. Commit early and often -- and merge back to master. :-)
- Silhouette 11y ago
  This argument assumes that useful changes can always be broken down into bite-sized chunks and implemented incrementally without unwanted side effects. That's an ideal situation, and it's also a realistic one a lot of the time, but not always. A development process that can't cope with major changes being needed from time to time isn't going to be appropriate for a lot of projects.
ktRolster 11y ago
You just reminded me of a coworker I had that would work for months on a branch, then spend a couple weeks trying to merge it. Eventually I had to yell at him before he would stop. I felt bad about yelling and apologized to his cubicle-mate. Small feature branches, or if you handle it by merging daily, cause no problem though.
- OJFord 11y ago
  > or if you handle it by merging daily Right, as far as I remember the "successful git branching model" still allows - even encourages - merging master back into feature branches. "Long-lived" doesn't have to mean "really out of date".
  - e_proxus 11y ago
    I've done this previously, and it works, but it creates a very messy history where you have merges going back and forth. We typically had several merges to get changes in from master for each feature branch, even if they only lasted for a few days (inside a sprint). Then there's the final merge back to master. If you look at the repo from afar after a couple of features and weeks, it gets very hard to read.
    - ktRolster 11y ago
      use: > git merge --rebase Keeps the history clean, if that's something you care about
      - e_proxus 11y ago
        Yeah, that's what I prefer at all times. Haven't figured out a good way to share feature branches with that model yet though. Sometimes you need to work on a feature together with other people without checking it in to the main branch, and doing force pushes isn't pretty...
manyxcxi 11y ago
To me, it sounds like the author is advocating for what we did when we used Subversion and merging was painful for non-trivial differences. In my opinion, the reason for switching from SVN to Git isn't that it's so distributed (you need to push centrally to get CI and share changes after all) it's that branching and merging are so much easier there's no excuse not to. We create a branch for nearly every ticket and definitely for all features. Master is essentially production ready or already in production while our development branch get run through CI/CD on every commit. The development branch is rarely broken and in almost all cases is where we branch our features/fixes from. It's up to the branch developer(s) to merge development back into their branch before bringing their branch back to dev- but since we're a small team and branches rarely live longer than a week merging back causes so few issues that we don't even flinch. Gone are the days of SVN where you'd spend two weeks off commit and pray your integration went smooth.
- sytse 11y ago
  Totally agree, shared remote branches are a good idea to build new features. A remote branch allows you to leverage CI in advance of merging and to discuss a work in progress with a team member, for more details see http://doc.gitlab.com/ee/workflow/gitlab_flow.html http://doc.gitlab.com/ee/workflow/gitlab_flow.html

by K0nserv 11y ago

jroseattle 11y ago

This. This is the correct way to think about it. Ballooned feature branches suck either at merge time or at deployment time. The problem in either case isn't the model -- it's the balloon of changes. Commit early and often -- and merge back to master. :-)

Silhouette 11y ago
This argument assumes that useful changes can always be broken down into bite-sized chunks and implemented incrementally without unwanted side effects. That's an ideal situation, and it's also a realistic one a lot of the time, but not always. A development process that can't cope with major changes being needed from time to time isn't going to be appropriate for a lot of projects.

ktRolster 11y ago

You just reminded me of a coworker I had that would work for months on a branch, then spend a couple weeks trying to merge it. Eventually I had to yell at him before he would stop. I felt bad about yelling and apologized to his cubicle-mate. Small feature branches, or if you handle it by merging daily, cause no problem though.

OJFord 11y ago
> or if you handle it by merging daily Right, as far as I remember the "successful git branching model" still allows - even encourages - merging master back into feature branches. "Long-lived" doesn't have to mean "really out of date".
- e_proxus 11y ago
  I've done this previously, and it works, but it creates a very messy history where you have merges going back and forth. We typically had several merges to get changes in from master for each feature branch, even if they only lasted for a few days (inside a sprint). Then there's the final merge back to master. If you look at the repo from afar after a couple of features and weeks, it gets very hard to read.
  - ktRolster 11y ago
    use: > git merge --rebase Keeps the history clean, if that's something you care about
    - e_proxus 11y ago
      Yeah, that's what I prefer at all times. Haven't figured out a good way to share feature branches with that model yet though. Sometimes you need to work on a feature together with other people without checking it in to the main branch, and doing force pushes isn't pretty...

manyxcxi 11y ago

To me, it sounds like the author is advocating for what we did when we used Subversion and merging was painful for non-trivial differences. In my opinion, the reason for switching from SVN to Git isn't that it's so distributed (you need to push centrally to get CI and share changes after all) it's that branching and merging are so much easier there's no excuse not to. We create a branch for nearly every ticket and definitely for all features. Master is essentially production ready or already in production while our development branch get run through CI/CD on every commit. The development branch is rarely broken and in almost all cases is where we branch our features/fixes from. It's up to the branch developer(s) to merge development back into their branch before bringing their branch back to dev- but since we're a small team and branches rarely live longer than a week merging back causes so few issues that we don't even flinch. Gone are the days of SVN where you'd spend two weeks off commit and pray your integration went smooth.

sytse 11y ago
Totally agree, shared remote branches are a good idea to build new features. A remote branch allows you to leverage CI in advance of merging and to discuss a work in progress with a team member, for more details see http://doc.gitlab.com/ee/workflow/gitlab_flow.html http://doc.gitlab.com/ee/workflow/gitlab_flow.html