GIT Squash & Rebase: Lesser Used but useful GIT Commands

Git Squash & Rebase are two commands which are not very often used but still once you get to know their purpose they are the gold standards of how you should be maintaining your code and commits.

However, I wont be surprised if many of you have still never used both these commands. I literally encountered my first use case for them four year into my employment as a developer

Purpose

Consider yourself working in a large team that has proper standards set in place for all the commits that each of us make into the main branch or the dev branch whatever it is called. Code quality checks, Sonar or some other Lints etc. In this case following could be the mechanism followed by the team

  • For every task instead of checking out the main/dev branch we create a branch of own and start doing our changes
  • During the course of the changes, we make 5 or 6 commits to this branch to accomplish all our requirements
  • Now as per standard we raise a Merge Request or a Pull Request where my code would be verified and then merged to the main/dev branch
  • Now since we are not alone in the team, there would have been multiple people working on the same dev/main branch. Hence, my branch and the main branch will mostly not be in sync anymore
  • Someone might have made changes into the same file and if we directly send our code for review and the reviewer merges it, only thing that can happen is merge conflict or some code missing from here or there causing the build to break
  • Now to avoid the above mentioned scenario Rebase command is used and Squash is just an additional toping which helps to maintain the quality of what we are sending through

Lets understand both of these commands and see how we can use them

Note: I'll be using the mac terminal for these commands

GIT Rebase

Rebase command is used to sync your current branch with its feature branch. Feature branch would be the branch from which you created your own branch.

This is done so that any changes made into the feature branch following the creation of our branch are also applied to our branch hence we can make sure we always have the latest code on which we are working.

git checkout feature-branch
git pull
git checkout -
git rebase feature-branch
  • Firstly, we checkout the feature branch on our local machine
  • Then we use the pull command to get any remote changes in the feature branch
  • Once we have the latest of the feature branch we will then checkout our concerned branch again
  • git checkout - checkouts the branch on which we were working previously
  • Now we use the rebase command and tell the branch with which we want to sync our branch
  • If merge conflicts arise then we can manually resolve them using the GIT UI or our code editor and then comeback to cmd prompt / terminal and use the below command to continue rebasing again
git rebase --continue
  • Best practise now would be to build our code once to make sure that the conflicts were resolved correctly and nothing broke.
  • Incase we end up making some mistake and dont want to continue with the process, we can use the below command to clear out the changes done
git rebase --abort
  • Once it is success, next we should force push our branch changes onto remote so that the repo server also has our branch synced with the feature branch
  • We forcefully push these changes as when complex operations like squash/rebase/reset etc are performed, we eventually are changing the commit history and it can only be done by force.
git push -f

GIT Squash

Squash command is used to merge multiple commits into one so that in the end changes are visible in a single commit.

When you submit your code finally for review, the reviewer doesn't need to know how many commits you made and how many time you kept changing the logic for the same implementation. They should only be seeing the exact final changes which are going to be merged to the feature branch to avoid any confusion.

Let's see the process to squash say 5 commits from a branch and merge them into one single commit.

Note: Make sure to rebase your branch before squashing

git rebase -i HEAD~5
  • Firstly we use the rebase command and tell the number of commits in the branch which we want to fetch for squash. Here we have that as 5
  • This opens a git file with the last 5 commits on that branch with pick and squash written in front of each of them
  • We can edit this file by going into insert mode on pressing 'i'
  • Once in edit mode we will manually update all the commits which we want to squash by changing the command from pick to either squash or s
  • We have to leave one of these 5 commits as pick as thats the one which we want the end reviewer to see as the commit which was made

image.png

  • The changes in the file can be saved by pressing Escape key followed by typing in :wq
  • This saves and closes the file and open a new one with the commit messages corresponding to all 5 of them
  • We can again go back to edit mode using i and then manually delete the commit message for the 4 squashed commits and update the one if required for the picked one
  • Again, we save and close the file by pressing Escape key followed by typing in :wq

image.png

  • We then again build our project to make sure the changes were success so that we can finally forcefully push our changes using
git push -f

Let's see how our commit screen looked before we squashed the changes

Commits before squashing.png

And now after squashing the last 5 into one, this is how it looks

Commits after squash.png

Conclusion

We have successfully understood and implemented the main use case of Git Rebase and Squash commands 🚀🔥. Please do share your feedback if you have reached this far on the article.

Keep learning & keep building.

No Comments Yet