Why I'm getting conflicts when I merge the 3rd level branch to master after merging the 2 second level

Question

I always have an issue when I got this scenario in my work

0 <- 1 <- 2 <----------- 9 <--- master
           \            /
            3 <- 4 <- 5 <------ Feature/A
                       \
                        6 <- 7 <- 8   <-- HEAD=Feature/B

so we have a master, we created new feature/A from master and later we created another feature feature/B from feature/A

now Feature/A got merged to master at 5

we need to merge Feature/B to master too, but we are getting tons of conflicts for no reason.

any idea what is causing that please , and how I can avoid this?

Edit

To merge B into master I run

git merge master

from Feature B I ran git merge-base --all HEAD master and the result was 2

which is releae/1.14.1 as you can see it in more detail on the next graph

my graph log command :

git log --graph --oneline master feature/member feature/fund-test

as feature/member is Feature A

feature/fund-test is Feature B

releae/1.14.1 Is where feature/A started which is 2

7640e46aa IS 9

|\
| * c354b9142 update claims upon registering.
|/
*   7640e46aa Merge branch 'feature/members' into 'master'
|\
| * 43ea27cb2 Feature/Members
|/
| *   ef276ed89 (HEAD -> fund-test, origin/fund-test) Merge branch 'minor-changes-fundraising-v3.1' into 'feature/fundraising-3.1'
| |\
| | * 952cfe3a9 (origin/add-missing-changes) Add changes resolve by git.
| |/
| * e924e1fc3 fixed changelog
| *   1d6eadffe Merge remote-tracking branch 'origin/feature/members' into feature/fundraising-3.1
| |\
| | * 76d3f1aa4 (origin/feature/members, feature/members) Update data service comments
| | * 5b8cdf931 Update NuGet packages
| | *   cf978c86b Merge branch 'master' into feature/members
| | |\
| |_|/
|/| |
* | |   2754d5127 Merge branch 'releae/1.14.1' into 'master'
|\ \ \
| * | | d67a38076 Update changelogs
|/ / /
| | *   aa16154e4 Merge branch 'remove/context' into 'feature/members'

Answer 1

Edit: given the note that hash ID 7640e46aa is the commit you drew as 9, we look at the two parents of 7640e46aa. They are:

43ea27cb2 Feature/Members

(this is the second parent, as git log --graph always draws that one to the right) and:

2754d5127 Merge branch 'releae/1.14.1' into 'master'

(this is the first parent, directly below the commit you called 2). So the top row of your graph is correct. However, commit 43ea27cb2 Feature/Members does not correspond to the commit you called 5: it is an independent commit with 2754d5127 as its (single) parent. That is, rather than:

0 <- 1 <- 2 <----------- 9 <--- master
           \            /
            3 <- 4 <- 5 <------ Feature/A
                       \
                        6 <- 7 <- 8   <-- HEAD=Feature/B

what we have looks like this:

0--1--2------------9   <-- master
       \___       /
        \  `---345   <-- Feature/Members
         \
          3--4--5   <-- Feature/A
                 \
                  6--7--8   <-- Feature/B

where commit 345 is the result of running git checkout -b Feature/Members <hash-of-2> && git merge --squash Feature/A rather than git checkout master && git merge Feature/A. The squashed-together 345 was then merged with a regular merge into master, and the branch name Feature/Members (note upper case) deleted. This branch was thus not related to the feature/members (note lower case) branch and commits 3, 4, and 5 conflict with commit 345.

Your primary set of choices now lie between merging anyway (use a real merge if at all possible!) and resolving the conflicts, or use git rebase --onto to copy commits 6-7-8 to three new commits. The advantage to using rebase is that the job will be easier. The disadvantage is that the three replacement commits for 6-7-8 must be used as replacements in every clone that currently has those three commits.

(original answer below the line)

---

Assuming your drawing is accurate, the merge base of commits 8 and 9 is 5. To verify this, run:

git merge-base --all HEAD master

This should print just that one commit's hash ID.

Conflicts will arise if/when changes that show up in the diff from 5 to 8 overlap or abut with changes that show up in the diff from 5 to 9. That is, having obtained the merge base's hash ID (singular), run:

git diff --find-renames <hash-of-5> feature/B > /tmp/ours
git diff --find-renames <hash-of-5> master > /tmp/theirs

Compare the diff listings to see where conflicts might occur.

Since the merge at 9 was supposedly made by git checkout master && git merge --no-ff feature/A, and there are no commits between 9 and its first parent 2, the changes that show up here, from 5 to 9, should be exactly those changes that were made along the 3-4-5 path. This means the diff from 5 to 9, in /tmp/theirs, should be empty. An empty diff cannot produce conflicts (with a non-empty or empty diff), so that either of:

git checkout master && git merge feature/B

or:

git checkout feature/B && git merge master

should have no conflicts. Therefore I conclude that at least one assumption here is wrong. The most likely one to be wrong is the assumption that your simplified commit graph drawing is correct. Consider editing your question to include the output of git log --graph --oneline master feature/A feature/B (possibly with some of the commit message subject lines edited out, if necessary). However, another possibility is that the simplified graph drawing is correct, but the merge at 9 is an evil merge: see Evil merges in git? In this case the /tmp/theirs diff will be non-empty.

(My own guess is that commit 9 is a squash merge, and has no link back to commit 5, so that the merge base is actually commit 2.)