3 ms·
The "semi-linear merge" (as Azure DevOps calls it) is our preferred merge approach as well, though reasonable cases can be made for alternative merges depending
by taberiand 5y ago
The "semi-linear merge" (as Azure DevOps calls it) is our preferred merge approach as well, though reasonable cases can be made for alternative merges depending on circumstance, e.g., an old version hotfix merge into master is of course done as a regular merge.
In addition, if people are feeling charitable, the branch will be cleaned up prior to merge with an interactive rebase to squash out "Wip" commits and hopefully leave a nice clear set of self-contained commits that provide a logically separated view of the work that went into the change.
- rocqua 5y ago> In addition, if people are feeling charitable, the branch will be cleaned up prior to merge with an interactive rebase If you're not doing that, might it not be better to squash? The point of not squashing is to preserve valuable granular commits. If you have WIP commits, those don't have much value. I suppose it depends on how clean the feature branch is. Personally, I have horrible commits, knowing I will clean them up later.
- taberiand 5y agoInteractive rebase allows you to optionally squash a commit down (or edit or otherwise manage them). The idea being that you can keep the important commits that express the purpose of the branch while cleaning up those that are not important for that purpose.