Why git rebase shows conflicts in the files I did not modify? -

let's on local repo , branch my_name/branch_a

when git rebase <branch_b>, many conflicts in files did not modify.

why happen? head of files branch_b except ones modified in my_name/branch_a. how can done without manually resolving these conflicts did not introduce myself.

rebase copies commits (and abandons originals). root of problem.

let's @ example. first, note i'm drawing commit graphs older commits towards left, , newer commits towards right. commits have single-letter names here, instead of git's true 40-character hash names f1c93ab7.... branch names appear on right, arrow pointing tip commit of branch, because how git stores these things.

your current branch name my_name/branch_a, , have branch named branch_b well. there commits on each branch not on other branch, , commits on both branches. meanwhile branch, my_name/branch_a, forks off third point—so there commits on branch not on branch_b, not "your commits":

...--a--b--c--d--e         <-- branch_uhoh          \        \           \        i--j    <-- my_name/branch_a            \             f--g--h        <-- branch_b 

you made commits i , j , have 2 commits come after commit h, i.e., rework commits "after" tip of branch_b.

in other words, did not make commits c--d--e. nonetheless, these commits on branch. in fact, commits a , b on branch too: 2 commits on all branches.

if run git rebase branch_b (while you're still on branch), git has figure out 2 things:

• what copy, and
• where start putting copies.

the name branch_b tells git both of these things. commits copied "those on my_name/branch_a not on branch_b. that's c-d-e-i-j. place put them "after tip commit of branch_b, i.e., after commit h.

if succeeds, git set branch name point new copies:

...--a--b--c--d--e         <-- branch_uhoh          \        \           \        i--j    [abandoned]            \             f--g--h        <-- branch_b                    \                     c'-d'-e'-i'-j'  <-- my_name/branch_a 

the names "prime" marks (c' , on) copies.

(you can view commits git rebase would/will copy git log <upstream>..head, in case git log branch_b..head. add --oneline here in cases one-line log message per commit.)

well, if that's problem, should do? obvious answer is: tell git not copy c-d-e. want result instead:

...--a--b--c--d--e         <-- branch_uhoh          \        \           \        i--j    [abandoned]            \             f--g--h        <-- branch_b                    \                     i'-j'  <-- my_name/branch_a 

that is, git should copy commits "between" (after, really) tip of branch_uhoh , branch, commits i , j; should copy them to (again, after, really) tip of branch_b. way write:

git rebase --onto branch_b branch_uhoh 

in other words, tell rebase both things, instead of telling one thing , letting figure out 2 that.

(but how find branch_uhoh? well, "right" way remember it, can run git log --graph --decorate --oneline , find cutoff commit id or name shows up. instead of branch_uhoh can cut-and-paste hash id of actual cutoff commit. often, can have git itself remember "upstream" name you, , rebase within , onto upstream , need no arguments: run git rebase , work. there special cases need transplant commits, not sufficient; need git rebase --onto.)