DEV Community

A
A

Posted on

git rebase and squash before opening merge requests

#git #gitlab #beginners

If you've just...

  • Completed a bootcamp (like me!)
  • Graduated with a CS degree
  • Studied coding independently

You probably have mostly been either pushing to your main or creating a development branch that you merge into main. Once you start working in groups, things get a little more complicated. Whenever you get on a new team, don't forget to ask and observe what their best practices are for git hygiene, branch naming, and merge requests!

git rebase vs. git merge

  • This video is a great overview. Essentially - rebase allows you replay your commits on top of the latest main - rewriting history to be clean and linear. Merges would create a merge commit and preserve commit history. Most teams might choose to rebase, unless you're working on open source.

How to rebase and squash

1: Sync your local main with the current remote main

git pull origin main
Enter fullscreen mode Exit fullscreen mode

Your teammates may have merged some new code into main since you made your changes to the remote main. If you're going to rebase, you want it to be on top of the latest and greatest. This command allows you to pull the remote main to your local. origin stands for the remote repository, and main is the name of the branch on the remote.

2: Make sure you're on your the branch you want to rebase on main

git checkout [insert name of your branch with changes on it]
Enter fullscreen mode Exit fullscreen mode

3: Open interactive mode and squash commits you don't need (or reword them)

git rebase -i main
Enter fullscreen mode Exit fullscreen mode

the -i flag stands for interactive. Note: if you're in IntelliJ, you might have to swap to your computer terminal to use interactive mode.

Next, hit i + enter

i
Enter fullscreen mode Exit fullscreen mode

This opens insert mode, indicated by the INSERT at the bottom of the terminal. You can now replace any of the words in front of the commits (that currently say pick) to squash or reword depending on what you'd like to do with the command. Usually you might want to squash commits for small things like "added comments" and keep more important ones. Keep the commit at the top.

When you're finished making edits, hit the ESC key +

:wq
Enter fullscreen mode Exit fullscreen mode

ESC will exit interactive mode, and the :wq stands for write and quit. It will write the changes and quit.

Now, you should see some text in the terminal that states that your branch was rebased. This will make it look like your commits were on top of the latest main. However, this change only affects your LOCAL branch - not the remote repo yet. You can double check your commits were squashed with

git log --oneline
Enter fullscreen mode Exit fullscreen mode

4: Push your local branch to the remote repo

git push origin [insert branch name]
Enter fullscreen mode Exit fullscreen mode

Now, when you go to your team's repo on gitlab, you should see a notif along the lines of "pushed to branch [branch name] x seconds ago. would you like to create a merge request?" This is your remote repo detecting changes on the remote copy of your local branch.

5: Create a merge request on gitlab. Once your CI pipelines pass and you have approval....

6: Hit the merge button on the merge request on gitlab
This takes your remote branch with your changes and combines it into the remote main. You can check "Delete source branch" to clean up your branch afterwards.

7: Sync local main again
Now that you've merged your changes to the REMOTE main, your local main is out of sync again - it doesn't include the code you just added.

git pull origin main
Enter fullscreen mode Exit fullscreen mode

8: (Optional) branch cleanup
Delete the branch with the proposed changes. Create a new branch for any new tickets/work you are assigned.

Conflicts

When you're coding in a team, there are a couple places merge conflicts can show up in the process.

  • When rebasing your branch locally If your commits touch the same code that someone modified in main since you branched off, you'll get conflicts during rebasing locally. Ex: let's say you make changes to a HelloWorld function, and you're in the process of rebasing, but your colleague merged to main a change in the same line you did to HelloWorld.
  • Merging your branch into main If someone else merged code into the remote main AFTER you rebased and their changes overlap with yours it will result in a merge conflict.

Conclusion

Rebasing is great for creating cleaner history. But, when you rebase locally, remember that those changes are NOT reflected in the remote branch until you push them! And don't forget, it's also a great practice to make sure your local main is in line with remote main before and after a merge request!

BONUS: Read about conventional commits

Top comments (0)