Wikimedia Cloud Services team/EnhancementProposals/Decision record T321798 gitlab cloud repos merge strategy

From Wikitech

Origin task: phab:T321798

Date of the decision: 2022-11-22

People in the decision meeting:

Decision taken

Option 4. Fast-forward-merges-only with "Encourage" squash mode for all repos under https://gitlab.wikimedia.org/repos/cloud.

Rationale

  • We would like to keep git history linear in the main branch, without merge commits.
  • We would like commits to be an independent unit of change as much as possible.
  • If a merge request contains commits addressing code reviews issues, they should be squashed before merging, so they are not present in the final main git history.
  • If a merge request contains nicely independent commits, there is no need to squash them before merging, so they are preserved in the final main git history.

Worth mentioning that things like development workflow, deploying mechanisms or integration with CI are topics that were out of scope for this decision request process.

Problem

Scope: this only applies to our repos in gitlab, mostly everything under https://gitlab.wikimedia.org/repos/cloud

There are 3 available merge strategies in gitlab.w.o. By default, on repository creation, the first option is enabled.

The merge-commit strategy was made famous mostly by github, but it comes with a cost: it pollutes the git history with meaningless merge commits.

Constraints and Risks

None. I don't think there is any particular risk or constraints associated with this decision request.

Proposals:

Option 1

Keep merge-commit strategy. See also https://gitlab.wikimedia.org/help/user/project/merge_requests/methods/index.md#merge-commit

Pros

  • Default
  • Preserves the development history
  • Preserves deployability (every commit in the main history line is one single change)
  • History line is not mixed with development commits (like 'addressing comment X')

Cons

  • History is not linear

Option 2

Use merge-commit with semi-linear history. See also https://gitlab.wikimedia.org/help/user/project/merge_requests/methods/index.md#merge-commit-with-semi-linear-history

Pros

  • Preserves deployability (every commit in the main history line is one single change)
  • History is linear
  • History line is not mixed with development commits (like 'addressing comment X')
  • Preserves the development history

Cons

  • Not default

Option 3

Use fast-forward-only merges. See also https://gitlab.wikimedia.org/help/user/project/merge_requests/methods/index.md#fast-forward-merge

Pros

  • History is linear
  • Preserves the development history

Cons

  • Not default
  • History line is mixed with development commits (like 'addressing comment X')
  • Does not preserve deployability (most commits are only part of a change, hard to tell when the change starts/stops)

Option 4

Use squash + merge fast-forward. Setup the same as option 3 + squashing all the commits into one before. See also https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html

Pros

  • History is linear
  • Preserves deployability (each commit is a change)
  • History line is not mixed with development commits (like 'addressing comment X')

Cons

  • Not default
  • Does not preserve the development history
Retrieved from "https://wikitech.wikimedia.org/w/index.php?title=Wikimedia_Cloud_Services_team/EnhancementProposals/Decision_record_T321798_gitlab_cloud_repos_merge_strategy&oldid=2033246"