3 ms·
Currently we have the problem of merges of two working branches occasionally resulting in a broken one. How does one solve that?
by Akronymus 3y ago
Currently we have the problem of merges of two working branches occasionally resulting in a broken one. How does one solve that?
- withinboredom 3y agoDon’t merge. Rebase only. Keep a linear history. When committing, do a ff-only of ‘main’ to your branch. Yes, this forces everyone to rebase before “merging” but in practice, this results in the least amount of failures, tests being run after you resolved any conflicts, etc. If you can use GitHub merge queues, that solves a ton of this, and you can run tests on the final merge before actually merging instead of relying on rebasing.
- whstl 3y ago"Don’t merge. Rebase only. Keep a linear history." This. It makes life so much simpler. With teams that don't have a lot of experience with git, however, I tend to use the "Squash and Merge" feature, coupled with forcing a linear history.
- lxgr 3y agoRequiring a passing integration branch before merging to master. Merging the integration branch then becomes a fast-forward merge. Alternatively, if you have a low enough merge volume, requiring mergers (by policy) to squash and rebase (and re-run tests before attempting to merge) can work too, as others have already mentioned.