1.              C
                | 
                B-D-E
                |    my branch
                A
                master

2. I merged by branch with changes from develop

            C
            | 
            B-D-C-E
            |    my branch
            A
            master
   

3. Now I need to merge my branch to master

Will this duplicate commit C in master?

CodePudding user response：

If you try to merge my branch into master as is, you will have the commit message for commit C twice in master: once before commit message D and once after commit message D.

Probably the easiest way to merge your branch in is to reorder commits C and D on your branch and then merge into master.

On my branch run git rebase -i HEAD~~~ to perform an interactive rebase, which allows you to place commit C before commit D (but you may have to resolve some rebase conflicts). Then your tree should be:

C
|
B-C-D-E
|    my branch
A
master

Then you can merge my branch into master with a fast-forward style merge.

CodePudding user response：

Well you could try a couple of things:

1. Rebase your branch to master - it should get rid of C. Works in simple cases. Tends to be a problem if you merge your branch with master - recommend not to mix merge and rebase. After the rebase you'd need to do a "git push -f" to force overwrite on github, and if anybody else is sharing your branch warn then not to merge with yours but to retake from your latest (another way of getting a mess if you are not careful).
2. (Assuming you are using PRs), squash-merge on completion - at which point only the difference between the two branches matters and the history of that branch will be thrown away.

I personally prefer squash merges for this reason.

CodePudding user response：

In git, a branch is just a pointer to a commit - like a tag, but moveable. It is the "parents" of commits that actually make the history. (I've deliberately not made all the branches neat lines in the diagrams below to emphasise that.)

From your description, it sounds like your initial state was this (you didn't tell us where "develop" pointed):

      /- C <-[develop]
     /
A - B <-[master]
     \
      \- D - E <-[my_branch]

If you merged develop into my_branch, the default would be to create a "merge commit", like this:

       [develop]
         v
      /- C -----\
     /           \
A - B <-[master]  \
     \             F <-[my_branch]
      \- D - E --/

Merging that to master with another merge commit would look like this:

       [develop]
         v
      /- C -----\
     /           \
A - B             \
    |\             F <-[my_branch]
    | \- D - E --/  \
    |                \
     \--------------- G <-[master]

There's no duplication here. But nor is there ever a state that looks like what you drew in the question.

If instead of a normal merge, you rebased my_branch onto develop, you would get this (note that commits D2 and E2 are new commits created by the rebase based on D and E):

       [develop]
         v
      /- C - D2 - E2 <-[my_branch]
     /
A - B <-[master]
     \
      \- D - E <-[abandoned commits]

Then a merge to master would look like this:

       [develop]  [my_branch]
         v         v
      /- C - D2 - E2 -\  
     /                 F <-[master]
A - B ----------------/