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’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.