
Ask HN: How often does Git merge make mistakes? - iceman_w
I was working on an express app with a friend and git auto merged a file after I ran &#x27;git pull&#x27;. There were no merge conflicts, but git added duplicate functions to a file after merge. I spent an hour trying to figure our what the problem was before realizing that git had made a mistake while merging.<p>I had never seen such a thing before. How often does something like this happen?
======
gknoy
I've never noticed that before, but it's possible that you both had added
functions in different places:

    
    
        foo() ... ; original
    
        bar() ...  ; added by alice
        foo() ...
    
        foo() ...
        bar() ...  ; added by bob
    

I haven't tried it, but I could imagine that being seen as separate text
additions, and ending up with duplicates if git thinks it needs to merge them:

    
    
        bar() ... ; alice
        foo() ... ; original
        bar() ... ; bob
    

You mentioned using `git pull`, which will actually merge things if it thinks
it's necessary -- which can lead to tree differences. In practice, I've found
it helpful to NEVER USE `git pull`. Rather, I advise using:

    
    
        git checkout master
        git fetch origin
        git merge origin/master --ff-only
    

This will ensure that git only does "fast-forward" merges, and does not end up
accidentally merging things - and keeps 'origin' as the system-of-record for
what's been merged.

~~~
sold
I recommend

git config --global pull.ff only

instead, then you can use "git pull" without worries. Or,

git pull --ff-only

~~~
iceman_w
In the following scenario:

origin: A-B-C local: A-B-D

What is the recommended action? git pull --ff-only will fail, right? So should
I be using git pull --rebase?

~~~
sold
Yes, ff-only will fail. If C,D are independent and simple, I would go ahead
and rebase, otherwise do a proper merge.

Remember you can play a lot with git; if you are not sure how it will turn
out, checkout a commit (e.g. git checkout origin/master), create a new
throwaway branch (git checkout -b tmp), then you can do rebases, cherry-picks,
merges etc., then do "git log tmp" or "git log -p tmp" to see how does the
branch look. If you are unhappy, you can always throw it out (git branch -D
tmp), it won't affect anything else.

I generally avoid the situation when a branch and origin diverges. The flow I
have in my work is: If I need to make a small change (few lines), I pull, do
changes, commit and push directly to master; if there are any intervening
independent changes, pull --rebase. For anything larger, I create a new
branch, and commit there. Once it is ready, I give it to a teammate for code
review and do automated build, if everything is OK he merges it to master.
Other people generally don't push to my branch, and there is no A-B-C vs A-B-D
situation.

If several people work together on the same branch, we coordinate actions
face-to-face or via team chat, to avoid conflicts. We pull/push many times a
day and the changes are small enough so there are no problems with rebasing in
a topic branch. If two people make big conflicting changes to the same branch,
it means trouble and we merge or even discard some changes.

