This strategy - using squash when merging - is often used when a Pull Request is closed.The rational management of their own code, the programmer is a very important thing, today I took the road to hosting github It will appear as if the work for your feature had happened in just a single commit. In the end, this allows you to avoid the automatic commit that typically happens as a result of a merge. The effect is very similar to what we've discussed before: all changes will be combined just as with a normal merge - but by using the -squash option, instead of a merge commit being automatically created, you're left with local changes in your working copy which you can then commit yourself. Squashing is also an option when merging branches: $ git merge -squash feature/loginĪutomatic merge went well stopped before committing as requested In case you are using the Tower Git client, using Interactive Rebase to squash some commits is very simple: just select the commits you want to combine, right-click any of them, and select the "Squash Revisions." option from the contextual menu. If you mark one or more lines as "squash", they will be combined with the one above:Īfter entering a commit message for the new, combining commit, the Interactive Rebase is completed - and the three old commits have been squashed into one. Keep in mind that Interactive Rebase allows to perform many different actions on your commit history for our example case here, however, we are interested in the "squash" action keyword. We can do so by starting an Interactive Rebase session: $ git rebase -i HEAD~3Īn editor window will then open where you can choose how you want to manipulate the selected part of your commit history. But before doing so, you'd like to clean up and squash the new commits into a single one: Let's say you have completed your work on a new feature branch (in the below example "feature/login") and now want to merge it back into the "main" branch. Going deep into Interactive Rebase goes beyond the scope of this article (take a look at the First Aid Kit for Git for a series of free, short videos on this topic), but we'll walk through a simple example case together. ![]() You can manually squash your commits at any time using Git's "Interactive Rebase" feature. 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 Comments
Leave a Reply. |