Great read. Rebase is such a powerful tool. I do think that git rebase -I derserved to be its own command. A lot of people I teach debasing to get confused by the difference between rebasing onto a ref, and pruning a branch
Git rebasing is extremely confusing. I say this as someone who does it on a daily basis. Rebasing takes significant effort to teach. The fundamental concepts are different from regular git use - it makes an abrupt jump from snapshot model to diff model.
A large section of developers simply don’t reach that level of proficiency in their entire career - instead depending on the organization’s expert for those tasks.
Good article
I’m not sure the author of this blog post is experienced with git rebase. I’m by no means an experienced git user, and to me the single most useful thing about git rebase is reordering commits in a local branch. This means I can commit some code in a local branch, continue working on stuff, and later move commits around to peel off PRs out of a feature branch. However, the author makes zero mentions to this feature in the blog post.
To illustrate how useful git rebase is, picture yourself working on a feature branch as part of your work on an issue. Suddenly you stumble upon something that you need to fix to unblock your work on that feature, but it’s not directly related to your issue. You can stash your changes, create a new feature branch, fix the bug, post a PR, expect it to be merged, and afterwards rebase your feature branch onto mainline.
That’s ok, but very time consuming.
You can instead use git rebase. Just go straight ahead and commit your code straight away in your feature branch and continue working. After you’re done working on your feature, you run git rebase to reorder your commits so that the ad-hoc fix is the first commit in your feature branch, and you post a PR for that fix alone, and once it’s merged you already have all your other changes lined up to be pushed as well.
Another usecase I follow often is posting an ad-hoc commit to simplify working on a issue. This means adding logging, forcing a flag, commenting out code, etc. I commit this message with commit messages that make it clear that this code is not to be pushed, and follow a convention that commit hooks can pickup as guardrail. From that point onward I just work on the feature until I’m done, and when I’m ready to post a PR I simply crack open git rebase, reorder the commits to move the ad-hoc commit to feature as the very last one, drop it, and done.
I was curious about why people would run git push --force on a shared branch. Some reasons people gave were:
- they’re working on a collaborative feature branch, and the feature branch needs to be rebased onto main. The idea here is that you’re just really careful about coordinating the rebase so nothing gets lost.
A safer solution would be to make a new branch and do the rebase on it instead, that way the shared branch won’t be impacted. You might still lose changes if they’re pushed after merging to main but that’s not really rebases fault. You can always cherry pick or something then from the original un-rebased branch (hopefully without any merge issues…)
