In this post, we'll talk about Interactive Rebase and Merge as the two main ways to squash commits. There are different ways and tools when it comes to squashing commits. There are pros and cons to both approaches, so it's mostly a matter of preference and convention. However, you cannot say that (a) or (b) is the "correct" way of doing things. This can be helpful in keeping things orderly! Some teams see a possible advantage in going with (a) and using squash: instead of many individual commits which might be unnecessary and potentially overwhelming, only a single commit appears in the main commit history.
(b) if you decide AGAINST squashing, all of your individual commits will be preserved as such. The main commit history, therefore, will only show a single commit for this integration. (a) if you decide to squash before merging, then all of those individual commits from your feature branch will be combined into a single commit. This is typically when you decide to squash or not: At some point, you will want to merge your work back into the main branch. Depending of the complexity and duration of your work, it might even be quite a high number of commits. If you should do this or avoid it is - to some extent - a question of preference: in some teams, for example, squashing commits is the preferred way to merge a feature branch back into a long-running branch like "master" or "main".īut why exactly would you do this? Let's take the classic case of a feature development as an example: you have probably worked on a separate feature branch and produced a number of commits in this context. 
As already said, the act of "squashing" your commits means that you combine multiple existing commits into a single one.
0 kommentar(er)
