Why Junior Devs Fail at Git Rebase—And How You Can Avoid It
I make this video specifically for the juniors who apply to my company.
They often don’t understand this picture - but they should!
That’s why I’m writing down the most important rules for git rebase - And I explain this on a high level. This piece will help:
- Your team to work better together
- Have a cleaner history
- Waste less time in merge hell.
Cool. If you watch this, you probably don’t need an intro into what rebasing is. If you do need, there are many tutorials out there. This video from Mark Howard is quite good.
But as you are here - let me give you a high level overview.
It’s the command to update (=rewrite) your git commit history, so that it can match the team’s updated progress.
Publishing a rebase to other people requires a git push --force - which should be a good indicator that this might be unsafe.
Stick to these rules and you’ll be fine:
#1 Rebase with squash: ONLY on feature branches
Else the history is gone
That’s why we have protected branches. To not shoot yourself in the foot.
#2 Can you group commits together logically?
Good. If not, leave them apart.
anyadmin-rails❯ git log --pretty=format:"%h - %s" --name-status
#3 If you are not a CLI pro: use a tool like Fork.
#4 Don’t rebase if someone branched off your branch already.
If you need: coordinate with them, ask them to rebase on your branch again.
See the demo: https://learngitbranching.js.org/?NODEMO
#5 Always rebase before merging, test after rebase
- A successful rebase does not mean your code will work.
- Have enough tests. At least the 80/20 of testing
- Always manually do a smoke test.
For a more practical understanding , be sure to watch the full video. It’s packed with insights that will help you master git rebase and improve your workflow. Don’t miss out!
