5

When I try to merge a feature branch into master, I get a merge conflict every now and then.

Now the obvious solution is to just manually resolve the conflict during the merge.

However, with pull-request based workflows (github, gitlab,...), this is somehow sub-optimal, as it puts all the work on the person who is in charge of actually merging the branch, rather than the submitter.

A somewhat useful solution is to merge master into feature before submitting a PR, fixing all the conflicts. however, I have the feeling that this complicates the git history needlessly.

So I wonder, whether there's a (simple) way to prepare the feature branch so it can be merged cleanly into master (after the fact that the two branches have diverged significantly). Ideally the fixup can be done in multiple commits.

umläute
  • 28,885
  • 9
  • 68
  • 122

2 Answers2

3

I wonder no. I think the simplest way of doing it to merge the master into feature branch before submitting it for a pull request (PR) as you have stated in your question. This is how a feature branch can be merged with master cleanly. I do not know if it is simple or not, but clean.

Personally I follow some basic guideline for a project structure which is widely used and pretty common. First, object oriented project structure along with proper packaging is effective for avoiding merge conflicts. The idea is to lessen the chances of several people are working in the same file but can work together in a same branch.

I think some common git practices will be always helpful. Some of these are making frequent commits, pull from master frequently and resolve small merge conflicts if there's any etc.

It was really hard to fix all the conflicts in a project before. However, almost every IDE is providing resolve conflict tools along with the IDE so that we can visually check and merge the code those are conflicting. I think with common git practices along with standard project structure can highly reduce merge conflicts. Besides that, merging the master into feature branch is the clean way of making things right before a pull request is submitted.

Reaz Murshed
  • 23,691
  • 13
  • 78
  • 98
  • It is not so clean since you leave a merge commit after each `git merge` command ;) merging is the only way when there are few people working on the same branch but if there is a single person who works on a given feature, then it is better to use `git rebase` instead. – Maciej Małecki Feb 23 '18 at 21:00
  • Yes you are right about `git rebase`, but I was thinking of working several person in a single `feature` branch. Moreover, I see nothing wrong in putting a merge commit after your merge `master` into `feature` branch. :) – Reaz Murshed Feb 24 '18 at 05:07
0

When the feature branch can be overridden, you can use rebase before submitting a pull request (or after breaking changes were introduced on the master in the meantime).

Rebase won't create an additional "merge" commit. It will re-write the history by creating new commits (new SHAs) instead. You can read more about it on the git-scm.com/docs/git-rebase. Also, take a look at the article about differences between merge and rebase commands.

Rebasing is also useful in the code review process. You can submit a new pull request so someone can drop comments. Then you can improve the code by adding fixup commits. Your team can make another iteration of the code review but now they are able to check only newly introduced changes. In the end, you just rebase all fixup commits, force push your branch and merge the code.

Note that this approach is okay only if you work on that branch alone. You should never change the history of the branch (and force push) when there are other people who work on the same branch.

Maciej Małecki
  • 2,725
  • 19
  • 29