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 639 times
-1
-
I'm not one of the down voters, but can you explain a little more about the state of this branch? Have you pushed any commits? Are you wanting to rebase any commits you pulled from someone else? – Greg Burghardt Jan 30 '20 at 23:30
-
@GregBurghardt Thanks. It's a bunch of commits, from various tickets, for a deployment, if some turn out to be buggy. I think it's not feasible now, and we'll need to do an additional commit. – Josh Jan 31 '20 at 21:37
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
- 34,276
- 8
- 63
- 114