In this lesson, you will learn how to navigate and resolve merge conflicts that occur when Git attempts to replay your historical commits during an interactive rebase.
When you perform an interactive rebase (e.g., git rebase -i), you are essentially asking Git to "pick up" your commits and "place them down" one by one onto a new base. If a commit you are modifying (such as during a split, reorder, or edit) introduces changes that clash with the new base, Git will pause the process, leaving you in a "rebasing" state.
Identifying the Conflict
When Git stops, it will notify you that a conflict has occurred in specific files. You can confirm which files are problematic by running git status. Git has essentially "paused" at the specific commit where the logic failed to apply cleanly.
The Resolution Workflow
Resolving these conflicts is a three-step cycle:
- Edit the Files: Open the conflicted files in your editor. You will see the familiar
<<<<<<<,=======, and>>>>>>>markers. Edit the code to reflect the intended logic of the commit you are currently replaying. - Stage the Changes: Once the file is fixed, add it to the index:
git add <file-name> - Continue the Rebase: Do not create a new commit. Instead, tell Git to resume the process:
git rebase --continue
Safety First
If you find that the conflicts are too complex or you realize you’ve made a mistake, you can always abandon the operation and return to the state you were in before you started:
git rebase --abort
Remember, during an interactive rebase, you are acting as an editor of history. If you encounter a conflict, you are simply manually finalizing what Git couldn't automate. Treat each git rebase --continue as a checkpoint in your journey toward a cleaner, more logical commit history.
Key Takeaway: When a conflict stops your interactive rebase, resolve the markers in the code, stage the files, and use git rebase --continue to proceed—never create a new commit manually during this flow.