kernel
/
git
mirror of https://git.kernel.org/pub/scm/git/git.git
1
0
Fork 0
Code Releases Activity

doc: git rebase: dedup merge conflict discussion 

Previously there were two explanations, this combines them both into a
single explanation.

Signed-off-by: Julia Evans <julia@jvns.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
main
Julia Evans 2025-08-23 00:42:59 +00:00 committed by Junio C Hamano
parent f39a29c22e
commit af5a099197
1 changed files with 20 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
Documentation/git-rebase.adoc
View File

@ -42,6 +42,26 @@ shortcut for `git checkout topic && git rebase master`.
------------ ------------




If there is a merge conflict during this process, `git rebase` will stop at the
first problematic commit and leave conflict markers. If this happens, you can do
one of these things:

1. Resolve the conflict. You can use `git diff` to find the markers (<<<<<<)
and make edits to resolve the conflict. For each file you edit, you need to
tell Git that the conflict has been resolved. You can mark the conflict as
resolved with `git add <filename>`. After resolving all of the conflicts,
you can continue the rebasing process with

git rebase --continue

2. Stop the `git rebase` and return your branch to its original state with

git rebase --abort

3. Skip the commit that caused the merge conflict with

git rebase --skip

If `<branch>` is specified, `git rebase` will perform an automatic If `<branch>` is specified, `git rebase` will perform an automatic
`git switch <branch>` before doing anything else. Otherwise `git switch <branch>` before doing anything else. Otherwise
it remains on the current branch. it remains on the current branch.
@ -77,13 +97,6 @@ any commits in `HEAD` which introduce the same textual changes as a commit
in `HEAD..<upstream>` are omitted (i.e., a patch already accepted upstream in `HEAD..<upstream>` are omitted (i.e., a patch already accepted upstream
with a different commit message or timestamp will be skipped). with a different commit message or timestamp will be skipped).


It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
and run `git rebase --continue`. Another option is to bypass the commit
that caused the merge failure with `git rebase --skip`. To check out the
original `<branch>` and remove the `.git/rebase-apply` working files, use
the command `git rebase --abort` instead.

If the upstream branch already contains a change you have made (e.g., If the upstream branch already contains a change you have made (e.g.,
because you mailed a patch which was applied upstream), then that commit because you mailed a patch which was applied upstream), then that commit
will be skipped and warnings will be issued (if the 'merge' backend is will be skipped and warnings will be issued (if the 'merge' backend is
@ -186,28 +199,6 @@ This is useful if F and G were flawed in some way, or should not be
part of topicA. Note that the argument to `--onto` and the `<upstream>` part of topicA. Note that the argument to `--onto` and the `<upstream>`
parameter can be any valid commit-ish. parameter can be any valid commit-ish.


In case of conflict, `git rebase` will stop at the first problematic commit
and leave conflict markers in the tree. You can use `git diff` to locate
the markers (<<<<<<) and make edits to resolve the conflict. For each
file you edit, you need to tell Git that the conflict has been resolved,
typically this would be done with


git add <filename>


After resolving the conflict manually and updating the index with the
desired resolution, you can continue the rebasing process with


git rebase --continue


Alternatively, you can undo the 'git rebase' with


git rebase --abort

MODE OPTIONS MODE OPTIONS
------------ ------------