Skip to main content
Software Engineering

Return to Answer

expand advice about merging branches into each other
Source Link
Karl Bielefeldt
Karl Bielefeldt
  • 148.4k
  • 38
  • 284
  • 483

You merge in the order that makes the merges the easiest. There is no general heuristic for this because it's highly dependent upon the code changes in question. Most of the time, your "gut feel" is pretty close to optimal. Consider that you can test different merge orders locally before doing it officially for your central repo.

Also, merging becomes much more difficult the longer you go without doing it. If your changes are too broken to merge into master, you should at least be frequently merging master into your refactoring branches, and frequently merging your refactoring branches into each other. That way, you're resolving conflicts a little bit at a time instead of all at once at the end.

Merging branches into each other can take a couple different forms. The most common way I do it is I will occasionally merge a colleague's branch into mine that I know has overlapping changes. This has a few potential outcomes:

  • My colleague's code is in a broken state because the feature or refactor is half-finished, so I back out the merge and try again later.
  • There are merge conflicts that I can resolve by changing my code, so I do it.
  • There are merge conflicts that require a conversation with my colleague, so I have one.

If my colleague merges to master first, then my PR will exclude changes merged in from that branch automatically. If I need a pull request first, I can rebase them out.

The other way to merge branches into each other that would probably work better in your situation would be to create a temporary refactor branch that can be used for continuous integration of the refactoring changes, then do one big pull request to merge refactor into master. That way, developers are reviewing small pull requests against the refactor branch.

The downside to merging branches into each other is you tend to introduce dependencies on each other, so you either have to take care to avoid that, or accept it and merge them close together. However, not having to take all changes via the master branch in the central repo is one of the main strengths of git. Make sure not to overlook it.

You merge in the order that makes the merges the easiest. There is no general heuristic for this because it's highly dependent upon the code changes in question. Most of the time, your "gut feel" is pretty close to optimal. Consider that you can test different merge orders locally before doing it officially for your central repo.

Also, merging becomes much more difficult the longer you go without doing it. If your changes are too broken to merge into master, you should at least be frequently merging master into your refactoring branches, and frequently merging your refactoring branches into each other. That way, you're resolving conflicts a little bit at a time instead of all at once at the end.

You merge in the order that makes the merges the easiest. There is no general heuristic for this because it's highly dependent upon the code changes in question. Most of the time, your "gut feel" is pretty close to optimal. Consider that you can test different merge orders locally before doing it officially for your central repo.

Also, merging becomes much more difficult the longer you go without doing it. If your changes are too broken to merge into master, you should at least be frequently merging master into your refactoring branches, and frequently merging your refactoring branches into each other. That way, you're resolving conflicts a little bit at a time instead of all at once at the end.

Merging branches into each other can take a couple different forms. The most common way I do it is I will occasionally merge a colleague's branch into mine that I know has overlapping changes. This has a few potential outcomes:

  • My colleague's code is in a broken state because the feature or refactor is half-finished, so I back out the merge and try again later.
  • There are merge conflicts that I can resolve by changing my code, so I do it.
  • There are merge conflicts that require a conversation with my colleague, so I have one.

If my colleague merges to master first, then my PR will exclude changes merged in from that branch automatically. If I need a pull request first, I can rebase them out.

The other way to merge branches into each other that would probably work better in your situation would be to create a temporary refactor branch that can be used for continuous integration of the refactoring changes, then do one big pull request to merge refactor into master. That way, developers are reviewing small pull requests against the refactor branch.

The downside to merging branches into each other is you tend to introduce dependencies on each other, so you either have to take care to avoid that, or accept it and merge them close together. However, not having to take all changes via the master branch in the central repo is one of the main strengths of git. Make sure not to overlook it.

Source Link
Karl Bielefeldt
Karl Bielefeldt
  • 148.4k
  • 38
  • 284
  • 483

You merge in the order that makes the merges the easiest. There is no general heuristic for this because it's highly dependent upon the code changes in question. Most of the time, your "gut feel" is pretty close to optimal. Consider that you can test different merge orders locally before doing it officially for your central repo.

Also, merging becomes much more difficult the longer you go without doing it. If your changes are too broken to merge into master, you should at least be frequently merging master into your refactoring branches, and frequently merging your refactoring branches into each other. That way, you're resolving conflicts a little bit at a time instead of all at once at the end.