Explore the July edition, featuring prompts, tips, and use cases for GitHub Copilot.
Git’s flexibility allows you to shape your workflow however you like. The organization of your git history is just one of the choices to make, but up until now the merge button on GitHub only created merge commits, resulting in a style of history that didn’t necessarily match your own workflow.
For years, the merge button on GitHub has created merge commits (i.e.
git merge --no-ff) which retain all of the commits in your branch and interleaves them with commits on the base branch. The result of a merge commit is a visually complex, but more accurate log that depicts how changes from a feature branch came to be on the base branch. Here’s what that looks like today:
Commit squashing has the benefit of keeping your git history tidy and easier to digest than the alternative created by merge commits. While merge commits retain commits like “oops missed a spot” and “maybe fix that test? [round 2]”, squashing retains the changes but omits the individual commits from history. Many people prefer this workflow because, while those work-in-progress commits are helpful when working on a feature branch, they aren’t necessarily important to retain when looking at the history of your base branch. Here’s what squashing on merge looks like:
Repository administrators now have a few options to choose from when deciding how to handle history.
Allow merge commits and commit squashing
This option will leave the decision to create a merge commit or squash up to the user doing the merging. This lets repository administrators stay flexible when deciding whether or not to retain all history from a feature branch.
Only allow merge commits
This is the default behavior and is exactly how the merge button worked before this change. Collaborators won’t have the option to squash their commits via the merge button.
Only allow squash commits
This is a new option which lets you force commit squashing on all pull requests merged via the merge button.