![]() Collaborators won’t have the option to squash their commits via the merge button. This is the default behavior and is exactly how the merge button worked before this change. This lets repository administrators stay flexible when deciding whether or not to retain all history from a feature branch. This option will leave the decision to create a merge commit or squash up to the user doing the merging. Repository administrators now have a few options to choose from when deciding how to handle history. Here’s what squashing on merge looks like: 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. While merge commits retain commits like “oops missed a spot” and “maybe fix that test? ”, squashing retains the changes but omits the individual commits from history. Here’s what that looks like today:Ĭommit squashing has the benefit of keeping your git history tidy and easier to digest than the alternative created by merge commits. 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. git merge -no-ff) which retain all of the commits in your branch and interleaves them with commits on the base branch. Merge commitsįor years, the merge button on GitHub has created merge commits (i.e. 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. Git’s flexibility allows you to shape your workflow however you like.
0 Comments
Leave a Reply. |