GitLab/Workflows/Squashing

Every merge request in GitLab contains a check box titled "Squash commits when merge request is accepted." If this box is ticked all commits of a particular merge request will be combined into a single commit on the merge-request's target branch. This box is ticked by default and committers are encouraged to adopt a squash workflow.

Benefits
The squash workflow has benefits for developers, committers, as well as deployers and operators.

For developers
Developers should be primarily concerned with writing, reviewing, and merging in hosted repositories. Complicated git workflows prevent developers from getting work done. A squash workflow simplifies the day-to-day work of merge request authors.


 * 1) Reduces cognitive overhead Folks who write merge requests should be primarily concerned with the content of their merge requests. Git provides benefits during development for developers who check in their code early and often. Additionally, sharing work publicly eases the process of integration. Merge request history may become cluttered over time: that's fine. If we squash all the development commits when we integrate a merge request into mainline then all the commits that were beneficial for development but not beneficial for operations go away.


 * 1) Avoids casual   use There are many horror stories about developers force pushing to the wrong branch. Our workflow should discourage the casual use of force push. If we use a squash merge workflow developers can make changes to merge-requests without using force push and without cluttering the mainline branch.