git pull options to prevent merge conflicts

Question

Is there an option(s) when doing git pull that will not allow any possibility of a merge conflict? I've looked at the merge strategies but none seem to meet this description. I'm looking for an option like git pull --quit_if_possible_merge

Basically, want a command for pulling to production site without any risk of a merge conflict which would temporarily bring the site down while we resolve it.

Answer 1

What about:

git pull --ff-only 

If what has been said in the other answers is true, this should have exactly the desired effect. No?

The --ff-only flag stands for "fast-forward" which is how Git refers to a situation in which one of the merging branches contains all of the commits of the other ( a strict superset ). This is special because it means no merge conflicts are possible. The commit so on the branch that is ahead simply get added to other branch and everyone is happy.

Answer 2

Git 2.0 (Q2 2014) add a new setting in commit b814da8 with push.ff:

In your case:

git config push.ff only

pull.ff::

By default, Git does not create an extra merge commit when merging a commit that is a descendant of the current commit. Instead, the tip of the current branch is fast-forwarded.

• When set to false, this variable tells Git to create an extra merge commit in such a case (equivalent to giving the --no-ff option from the command line).
• When set to only, only such fast-forward merges are allowed (equivalent to giving the --ff-only option from the command line).

Answer 3

When merging in Git you can do the following type of merge:

git merge -ff-only branch_to_merge_into_this_one

This will only complete your merge if Git sees that your merge can be completed using the fast-forward approach. Otherwise Git will abort the merge and let you know that the merge is not possible as fast-forward.

So what is fast-forward merge such that it can assure you that a merge conflict will not occur. A fast forward merge reviews the commit history of the two branches in question (say A and B where you are on A merging in B) and then checks to see if B contains the complete commit history of A. Additionally, that A does not contain any commits that are not part of B. This means that when merging in B it is save to do then merge by stacking all of B's new commits on top of the HEAD of A and then moving A's HEAD to where B's HEAD is. In this fashion the change sets are applied linearly and there is no chance of conflicting edits because Git will have enough information in its commit history to responsibly decide which changes you do and do not want.

Answer 4

As already stated by others: you only get merge conflicts if you committed anything in the local repository. If you don't you will not get any merge conflicts.

If you did not commit anything, but you were working inside you local git repository, i.e. you changed files or created new ones, a git pull will still get you in trouble, when it needs to update your modified files. - Hence, do not work inside your local repository directly and you are fine.

Next if you insist on working inside your local repository and think of a git pull to update your files. You have to decide what to shall happen with your modified files. If you simply want to abandon all local changes and just get the files as they are in the remote repository you can do a git fetch;git reset --hard @{u}.

Answer 5

I don't think there is any such flag. If something conflicts it conflicts and needs to be handled. But there is a merge strategy that guarantees no merge conflicts: don't modify or commit anything on the production site.

If nothing is committed on the production site then there is nothing to conflict with it. Do all merging on the production branch on your local machine and resolve all merge conflict there before pulling from the production site.