Say a branch is created with many merges/commits, then you figure out 1 merge was bad. Would it be better to undo it with rebase -i or with git revert or by manually undoing some changes and adding them in a new commit? It seems like both revert and manually undoing it with new commits both add an unnecessary extra commit. Is rebase -i less error-prone?
Asked
Active
Viewed 1,019 times
1 Answers
3
Rebasing is not less error prone. The choice to rebase or revert depends on whether the commits you are rebasing have been pushed to any remotes. If they have been pushed, rebasing has the potential to erase history. This will screw anyone else who has pulled those commits to their repository. In other words don't rebase commits that have been pushed or commits you pulled in.
If you have not pushed those commits then rebasing is an option. Reverting preserves the history, including the bad merge. If you prefer to forget that bad merge ever happened then rebase and skip that commit.
Have a look at my answer to Is using Git Stash as a workflow an antipattern? for more info, and a rant by Linus Torvalds specifically about rebasing commits.
One is not better than another. Rebase operations are a way to clean up your local history before sharing it with the rest of the team. Reverting is a safer option if you want to preserve history, and if those commits have been pushed or pulled you want to preserve history.
Greg Burghardt
- 45,304