Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

During Git Rebase, at what point do conflict resolutions get committed when using --continue

Tags:

git

git-rebase

We are running git rebase and running into conflicts, where we need to use --continue after we resolve merge conflicts. However, I am accustom to manually running the commit once the conflicts are resolved. Since we don't see additional commits when the entire rebase completes, at what point do conflict resolutions get committed?

like image 579
Jamie Lara Avatar asked Dec 24 '15 03:12

Jamie Lara


People also ask

What happens after git rebase continue?

When you're finished making all your changes, you can run git rebase --continue . As before, Git is showing the commit message for you to edit. You can change the text ( "i cant' typ goods" ), save the file, and close the editor. Git will finish the rebase and return you to the terminal.

What is git rebase continue?

However, if you use Git rebase, you move your whole feature branch, starting it on the tip of the main branch so that all the new commits are now part of the whole. This action rewrites the project history by making new commits for each of the original branch's commits. So, this is how the new branch looks: Source.

Do I need to commit again after rebase?

The purpose of rebase is make your commits look as if they were changes to the branch you rebase onto. So the most logical way is to incorporate merge conflicts into these commits. No additional commits is required thus. Merge is different, because it's an explicit action of merging diverged branches together.


2 Answers

Any conflict resolutions that occur during a rebase will belong to the new commit that the rebase creates.

So the direct answer to the question:

what point do conflict resolutions get committed?

...is after --continue, but effectively after the entire rebase command completes and your branch pointer is updated.

From an outsider's perspective a branch that has been rebased looks like the work was done immediately after branching and had no need for any conflict resolution because work was performed on top of that content.

This is sometimes preferable to a merge because the commit history can be easier to reason about if there are not as many (possibly) meaningless merge-commits

like image 75
Jonathan.Brink Avatar answered Sep 19 '22 18:09

Jonathan.Brink


It helps to think of a rebase as just writing a new sequence of commits, reapplying the commits being rebased on top of a new head. If each commit can be applied automatically, great, make it so. When a commit cannot be applied automatically, git tells you, leaves the index as best as it can be represented, with the conflicting files appropriately marked, then after you tell it to continue the rebase, things proceed as follows:

If git rebase --continue finds uncommitted changes in the index, it presumes that the changes constitute the resolved conflicts, and commits it. It prompts for a commit message, and uses it for that commit, then resumes rebasing the remaining commits, after the one that originally caused a conflict.

If git rebase --continue sees nothing uncommitted, it presumes that the conflict has been manually resolved and committed, so it simply continues with the remaining commits in the rebase.

like image 33
Sam Varshavchik Avatar answered Sep 21 '22 18:09

Sam Varshavchik