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

Origin task: phab:T321798
Date of the decision: 2022-11-22
People in the decision meeting:
* User:Arturo_Borrero_Gonzalez
* User:David_Caro
* User:FNegri
* User:Nskaggs
* User:Vivian_Rook
* Bryan
* Raymond
== 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