2

Say I have one.txt and two.txt in a remote repo and I've been doing some work locally and haven't staged them. Then I find out another team member made some necessary changes to those two files and pushed them to the remote repo. I need his changes, so I go git stash, git pull, git stash pop.

But I get 2 merge conflicts when I did the stash pop. one.txt was auto merged and two.txt had to be done manually. For the manual one, I said "take both" in one area, and the other I kept mine). Then I staged the result of the merge via git add.

git status now shows both files are ready to be committed.

Will I have a problem pushing? In other words, does the checking in of a merge (in the context of the stash/pull/pop) have to match what the co-worker pushed? Also, am I supposed to do something with the stash after/when there's a conflict?

I'm trying to avoid a merge conflict when I push to the remote repo, so I'm worried about getting into a weird state.

MattoMK
  • 609
  • 1
  • 8
  • 25
  • You won't have a merge conflict if you fix the conflict after the `git stash pop`. But be careful by fixing the merge conflict. – SwissCodeMen Apr 11 '22 at 21:35

2 Answers2

1

Assuming that you resolved the merge conflicts correctly, and another developer hasn't pushed more code for the same lines of code since you last pulled, you shouldn't have any issues pushing your changes.

That said, I don't recommend using git stash for conflict resolution when working with multiple developers on the same branch. It's highly error-prone, and you're likely to lose work eventually.

The problem is that if you make any mistakes with your conflict resolution after popping the stash, you have no way of rolling back to the previous state.

A much safer strategy is to use git pull --rebase.

The steps in your example case would be:

  1. Make local changes
  2. Find out that files you've changed locally have been altered on remote
  3. Commit local changes
    • This ensures that your reflog has recorded the changes as they are before you resolved conflicts, meaning you'll always be able to roll back.
  4. git pull --rebase
    • You can read the link for more details on this operation. Essentially, it will take the commit that you just made and rebase it onto the HEAD of the remote branch
  5. Resolve any conflicts the same as you would when applying/popping a stash
  6. git push

As a disclaimer: the safest option is to always keep your work on its own branch, and merge it into the shared branch when necessary. Even so, these types of conflicts will come up, and when they do, git pull --rebase should be your default strategy.

TonyArra
  • 10,607
  • 1
  • 30
  • 46
-1

Will I have a problem pushing? ... I'm trying to avoid a merge conflict when I push to the remote repo

A push is not a merge, so it cannot possibly result in a merge conflict.

In fact, if pushing would require a merge (because the remote has commits that you don't have), Git will refuse to permit the push.

So, pushing cannot possibly do anything bad. If pushing is possible at all, then pushing is perfectly fine.

matt
  • 515,959
  • 87
  • 875
  • 1,141