1

I have a master branch and a feature branch. the feature branch gets merged into the master branch with updated code every day or so. However, it does happen often that changes get merged directly into the master branch without going through the feature branch first.

This means that the master branch needs to be merged into the feature branch too. So the master branch contains some updated code and some outdated code and the feature branch contains some updated code and some outdated code.

When trying to merge the master branch into the feature branch sometimes there are cases where the master branch wants to revert changes made on the feature branch, even though the feature branch has the most up to date code.

How can this be prevented?

mike
  • 1,233
  • 1
  • 15
  • 36
simon lombard
  • 23
  • 1
  • 4
  • Maybe use more predictive branching strategy ? Such as [Gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow). – tvm Sep 20 '20 at 13:37

1 Answers1

2

This means that the master branch needs to be merged into the feature branch too

That is not a best practice:

  • you merge "upstream" (from feature to master) where the merge conflicts are more limited (unless, in your case, you have concurrent evolution to master from from other change branches)
  • you might not want to merge "downstream" (from master to feature), where merge conflicts are almost assured, because of concurrent changes coming from both master and other branches, both merging to feature.

Ideally, you just delete feature, and recreate it on top of master, where you merge again the changes that need to be integrated together.

The integration branch becomes a transient branch, which means it should not even been merge to master at all:

  • you merge your changes to feature, to test them together
  • you then select the changes you want to merge to master, because they are ready to be part of the next release
  • you delete feature, and recreate it.

That is the idea behind gitworkflow (one word).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Would this also work with a flow of 3 branches? 1 master branch and 2 integration branches? The current work flow is feature branch 1 merges with feature branch 2, this is because it makes reviewing easier. Feature branch 2 then gets merged into master. As soon as its merged it gets deleted and recreated from feature branch 1. Should the same be done with feature branch 1? In other words should feature branch 1 be deleted and recreated from master as soon as feature branch 1 is merged with feature branch 2? – simon lombard Sep 20 '20 at 15:39
  • 1
    @simonlombard the all idea behind `gitworkflow` and its integration branches (you have have several) is that you never merge an integration branch to `master`: that would give you a merge commit way to big to debug. In case of an issue in production, all you would know is that there is an issue in that one final merge commit (composed of many features, all bundled together). By merging selectively feature branches, each one individually to `master`, a `git bisect` can, in case of an issue in production, point back to the right feature merge-commit, thereby facilitating the debug process. – VonC Sep 20 '20 at 15:55
  • I see. This is what we are doing currently. However, as soon as the feature branches have been merged we receive errors that have to be selectively fixed. And these changes are small and need to be reviewed. That is when we make these changes on feature branch 1 which is supposed to be a mirror of the master branch. But this branch is so transient because it is being worked on constantly that review is difficult to achieve, so we created feature branch 2 where we test and review the changes in batches. But that leaves us with the problem of how to keep feature branch 1 up to date with master – simon lombard Sep 20 '20 at 16:17
  • 1
    @simonlombard that would be through a rebate, reading features on top of master. – VonC Sep 20 '20 at 16:19
  • ah, that makes sense. what does "reading features on top of master" mean though? – simon lombard Sep 20 '20 at 16:25
  • 1
    @simonlombard I meant rebasing, not reading, but my Android phone auto-correct is not reliable ;) – VonC Sep 20 '20 at 16:49