0

It seems to me that the sooner a developer merges with released code, the better. In the original GitFlow article this isn't done. The original picture is this: enter image description here

When long lived feature branch on the far left is finally merged into develop, it is still based on version 0.1. Wouldn't it be better practice if the developers at least kept their branches up to date with master like this? Is there a good reason that GitFlow does not recommend (and implicitly recommends against) these "keeping up with the release" merges? (Additional merge commits in blue) enter image description here

Improve this question
3
  • 1
    You can do merge back once in a while to long lived feature branch. But this depends on circumstances. In any case I would not be doing merge back from the master, but from develop.
    – Dalija Prasnikar
    Commented Nov 21, 2019 at 21:44
  • 1
    In typical practice, long-lived feature branches are periodically updated with the latest changes from develop to ensure the later merge into develop will be as painless as possible. The releases on master are automatically included in those updates.
    – Bart van Ingen Schenau
    Commented Nov 22, 2019 at 8:41
  • Thanks Dalija and Bart. Merging in from develop makes even more sense to me. My question was about master, because it seems like keeping up with master would be a bare minimum expectation.
    – Theodore Norvell
    Commented Nov 22, 2019 at 12:56

1 Answer 1

Reset to default
6

Working in a large enterprise codebase (my experience is with 20 fulltime devs), I feel the diagram misrepresents the amount of commits to master that occur relative to the commits to the feature branch.

When I develop a feature branch, I often see 200ish commits (non-squashed from 10-20 feature branches) pass by on the master branch. If I were to merge every time a new commit hit the master branch, I'd constantly be distracted from my actual work.

Secondly, are there merge conflicts to begin with? If there aren't, then it doesn't really matter. If there are, then it of course does; but I would prefer to focus on these conflict resolutions when my feature is fully developed (or at least hits a buildable milestone). It makes little sense to start merging conflict when my own work is still very much a broken WIP.
To that effect, it's perfectly reasonable to only merge from master when the feature branch hits specific completion milestones; which for an everyday feature branch may simply be the completion of the feature branch altogether.

Thirdly, I would advise against merging from master to feature when the feature branch originates from develop. In general it would be better to respect the order, and thus merge from master -> develop -> feature.

At best, merging directly from master, in the presented diagram, makes it the feature branch's responsibility to ensure the master commits get merged into the develop branch, which makes little sense.
At worst, it leads to multiple feature branch developers having to deal with merge conflicts (possibly in a different way) that then will again cause conflicts when these feature branches are merged into the develop branch.

Lastly, although this is tangential, tools like GitLab (and I presume others too) perform a check during a pull request whether it's possible to merge into the target branch with no conflicts. If so, preemptively merging from that target branch wasn't necessary. If not, developers are still able to then merge from that branch and resolve the conflicts in their own feature branch.

Improve this answer
7
  • 1
    This might be the first time I've heard of someone preferring infrequent, but massive merge conflicts that bring development to a halt for hours or days over frequent, but fairly trivial merges that can be resolved in a few minutes, if not automatically.
    – 8bittree
    Commented Nov 22, 2019 at 22:23
  • 1
    @8bittree: That's overstating it. I didn't say I put off merges as long as I can. I just don't jump into action the second the master changes when I'm in the middle of something. I don't prefer massive merges, but in large teams master commits are frequent enough (20 fulltime devs + properly split tasks = 4 to 10 master merges a day) that needing to immediately respond to that would become a major distraction.
    – Flater
    Commented Nov 22, 2019 at 22:57
  • Fair enough. I do agree that merging immediately on every push notification would be an awful distraction. I was thinking of feature branches that might be around for a week or (much) more before being completed and only merging at the end, but as you say, milestones provide reasonable points for intermediate merges, and some teams might have their work organized such that feature branches typically finish within a day or so.
    – 8bittree
    Commented Nov 26, 2019 at 22:29
  • @flater With GitFlow, each feature goes into the develop branch when its complete, but commits only go on master when there is a new release. Are you really making 4 to 10 releases a day?
    – Theodore Norvell
    Commented Dec 4, 2019 at 16:18
  • 1
    @TheodoreNorvell: You sometimes need to merge from develop too. If you don't, that means that in the span of a single release, you never work with a version that has the latest (unreleased) features. For short-lived branches and a slower release schedule, that's not always feasible.
    – Flater
    Commented Dec 5, 2019 at 8:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.