gitgitlabfast-forward

git merge --ff creates merge commit


I'm trying fast forward develop branch to the main as

git checkout main
git merge --ff develop
git push

but that for some reason creates merge commit which introduces a new hash

Then I have did that:

git merge --verbose --ff-only develop                                                                                                                                    

which ended up with

fatal: Not possible to fast-forward, aborting.

Regular --ff came up as

Merge made by the 'recursive' strategy.
 pom.xml                         | 2 +-
 src/main/webapp/WEB-INF/web.xml | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Any thoughts on that?


Solution

  • ff only works if you are standing on an ancestor of the branch you are trying to merge:

    A <- B <- C <- (master)
              ^
               \ D <- E <- F <- (develop)
    
    git checkout master
    git merge --ff-only develop
    

    That would be ok (because master is on an ancestor of develop)

    A <- B <- C <- G <- (master)
              ^
               \ D <- E <- F <- (develop)
    
    git checkout master
    git merge --ff-only develop
    

    This would not work because now master is not on an ancestor of develop.

    So..... why is G there? I would not be able to know. You should be able to list that (or those) commit with this to be able to see what they are about:

    git log ^develop master
    

    Now.... if you always intend to have master on top of develop, there's more than one way to do it. The way you are attempting (git merge --ff-only) works if you are on an ancestor..... but if you always want it to work regardless of anything that you have committed in master(you don't care losing it if there's something at all), then you can do:

    git checkout develop
    git branch -f master # set master where we are right now
    git checkout master
    

    Or

    git checkout master
    git reset --force develop
    

    The first approach looks more efficient because the working tree is only being adjusted once whereas in the second it is twice (unless you are in master to start with).