How do I merge changes without pulling from a GIT repository?

Question

Thanks for looking. I have no doubt I probably used the wrong terminology in my question so let me just explain the problem:

1. Developer A checks code into GIT.
2. Later, Developer B checks code into GIT and somehow overwrite's Developer A's code with old class files that Developer B has also edited. Possibly, Developer B didn't pull before push ing.
3. Developer A has new work to check in, commits, pulls, pushes. GIT says it was a "success" (no merge issues flagged)
4. Developer A goes back to his code which now won't build because suddenly work I did with that first check in is now missing.

So, that is my issue. I used this SO post to reset my instance of the code to the last successful commit that I made (Step 3 above) and that worked great. So now I can build and all of my work is in tact again.

The Problem

While my local copy of the code now looks great again, I can't push it to GIT without first doing a pull of what is already in the repo. Unfortunately, when I do a pull , all of my work is overwritten and it doesn't give me the opportunity to merge.

Any advice?

Answer 1

如果已经发生了强制推送，并且您觉得包装箱上的存储库状态就是您希望存储库所在的状态，则只需再次执行git push -f 。

Answer 2

why don't you branch your local changes to a seperate branch. pull the repo to your master branch. merge locally. then push back to repo?

Answer 3

Yes, you can merge the change locally without pull and then push it back to the remote repo after you fix the mess.

I believe your graph in the remote repo is:

C1 - C2 

and your local git is:

C1 - C1'

Because your C1' is not based on anything from C2, you cannot commit (unless you do a force)

You can fix this problem by first git fetch to update your local git graph to below:

C1 - C1' (local/master)
  \- C2 (origin/master)

Then you can merge by

git merge origin/master

You may get conflict. After you fix them all you should get a graph like:

After that

C1 - C1'    ----------       C3 (local/master)
  \- C2 (origin/master)     -/

Then you should be able to push without --force

Answer 4

From git help push :

For a failed update, more details are given:  
rejected  
   Git did not try to send the ref at all, typically because it is not a fast-forward and you did not force the update.  
remote rejected  
   The remote end refused the update. Usually caused by a hook on the remote side, or ...

1. You must comply to the above rules before being able to push (ie you must not break Git history, loose commits...)
2. You should (almost) never force a push.
3. The git pull command is a shortcut to git fetch && git merge (or git rebase if using --rebase option). So you can fetch first then manually merge the remote changes.

git status tells you if you are behind the upstream and if you branch can be easily updated:

Your branch is behind 'origin/master' by 4 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

Git-prompt is really handy to quickly know if there are remote changes to retrieve and merge. See the " u-4 " in the prompt after git fetch and the list of four incoming commits reported by git log ..@{u} :

(master $ u= origin/master)]$ git fetch

(master $ u-4 origin/master)]$ git log ..@{u} --oneline
7edead8 NXP-15160 fixing test class path for redis test-jar
d507b6f NXP-15160 renamed cache component
aaf64ab NXP-15161 re-worked redis feature activation
23b1d2c NXP-15254: use concurrent hash maps to avoid locks on service access