Skip to content

Latest commit

 

History

History
49 lines (40 loc) · 2.45 KB

9.2. Pull request strategies.md

File metadata and controls

49 lines (40 loc) · 2.45 KB
Raw

Pull request strategies

  • In Azure repo's you can have limit merge types branch policy
    • Standardizes a strategy for the whole team

Merge (no fast-forward)

  • Standard strategy in Azure repos & most other Git providers
  • It emulates running git merge pr from the master branch
  • All the individual commits in the pull request branch are preserved as-is,
    • and a new merge commit is created to unite the master branch and the pull request branch.
  • git merge (no fast-forward) illustration
  • Trade-off:
    • Pros
      • It gives the most insight into how a branch evolves
      • Illustrates exactly how a developer (or developers) worked on a pull request
    • Cons: since it preserves every commit is may be very verbose.

Squash commit

  • Creates a single new commit
    • leads to a just a simple, straight, linear history
  • Emulates running git merge pr --squash from the master branch.
  • The resulting commit is not a merge commit; those individual commits that made up the pull request are discarded.
  • git squash-commit illustration
  • 💡 As individual commits are lost, it's best for teams that use "fix up" commits or do not carefully craft individual commits for review before pushing them.

Rebase

  • Takes each individual commit in the pull request and cherry-pick them onto the master branch.
  • Emulates running
    1. git rebase master on the pull request branch
    2. git merge pr --ff-only on the master branch.
  • git rebase illustration
  • History is straight and linear, like it is with the "squash" option but each individual commit is retained
  • 💡 Useful for teams that practice careful commit hygiene, where each individual commit stands on its own.

Semi-linear merge

  • Also known as "rebase and merge"
    • The commits in the pull request are rebased on top of the master branch
    • Then rebased pull requests are merged into master branch
  • Emulates running
    1. git rebase master on the pull request branch
    2. git merge pr --no-ff on the master branch
  • git semi-linear merge
  • 💡 Some see it as best of both worlds
    • individual commits are retained, so that you can see how the work evolved
    • but instead of just being rebased, a "merge bubble" is shown so that you can immediately see the work in each individual pull request.