I don’t plan on going to great lengths to explain my dislike for rebasing but I knew there would be a lot of questions, so I’ll write a small note on it.
#Squash commits master git software#
Whichever side of the debate you, the reader, are on I certainly hope that as professionals we all agree that keeping the build green (build pipelines running successfully and all tests passing) should be considered not just a default but expected for any software project. How those tools are able to do this can depend if all the commits are present or if they are squashed. It is common to have the CHANGELOG.md file have new features and breaking changes added to it. On the other side, I am more inclined to use squash merges on team projects where other developers may read source history.Īnother important consideration is usage of automated tooling and processes that use the commit messages as part of the CI/CD build pipeline. However, at times I have squash merged when I’ve had many commits with messages I didn’t want in the source control. For example, I am much less inclined to use squash merges on the repository for this site as I am the only developer. I think that factors such as team size (including teams of one developer) and how the source history is used (if at all) should be considered before picking an approach. I think this puts me in a minority simply because I haven’t become enthusiastically attached to one way or the other. I like the ability to see every commit, but I also like a cleaner looking history. I don’t have a good answer for which should be the default option for a codebase. I can honestly see the advantages and disadvantages of both sides of the debate. However, proponents of merge commits vehemently dislike this concept, feeling that a lot of history and context is lost in the process. It keeps the history “clean”, as they say.
As previously discussed, another benefit of squash merges is that they prevent noisy source control history which can include typo fixes, previously accidentally missed files, etc.
#Squash commits master git code#
Squash merges, as it’s proponents argue, are more valuable than merge commits because entire new features or bug fixes can be compressed into a single commit and therefore easier to code review and read at some point in the future. The argument against this is that there is too much noise which actually makes the previous claim harder to be practical. The idea being it is easier to track down when a bug was introduced if there are lots of small commits instead of many commits compressed (squashed) into one. The commits can be used to track down bugs, for example. The argument for merging commits exactly as they are, is that the commits form a history of the codebase and therefore are valuable because of the story the commits tell. The source control history will be preserved exactly as it happened. This could be considered the default behaviour of Git. The choice of merging commits as they are, or “squashing” commits is not always a clear one - both sides of the argument will fiercely extol the advantages of their preferred approach and disadvantages of the opposite approach. I never rebase, so I’m not going to discuss it here. It becomes more complex when you consider the third option - rebasing. There’s certainly strong proponents on both sides of this debate. Should you squash commits or merge them as they are?
0 kommentar(er)
