0

So the scenario is quite basic: I did a checkout of a git repo, on branch X. Made some changes, performed a commit and pushed them, all good so far. No other changes made for 2-3 days. Afterwards I came back, ran a git status to make sure I have no changes, did a git pull origin X and I got conflicts on several files.

How is that possible? To be honest I have no clue what the other colleagues did on that branch in these 2-3 days (perhaps some rebase, force push, etc) but still, as long as my local clone has no changes, how can a pull result in conflicts? Can anyone explain it, perhaps with an example?

Biggie Mac
  • 1,307
  • 2
  • 13
  • 26
  • Maybe remote was force pushed? What does your `git status` states? – Justinas Jun 08 '23 at 06:00
  • `I have no clue what the other colleagues did on that branch` that's really too bad because we don't either and this is exactly the information missing (together probably with your merge or rebase pull strategy) to understand what is happening. – Zeitounator Jun 08 '23 at 06:26
  • A force-push that reverted your changes (and included others) is a very simple explanation to what you are facing. – eftshift0 Jun 08 '23 at 06:31
  • @Justinas but still: why would a force push cause a conflict on a git pull? I could understand that in case of a rebase, since the commit content (or their order) has changed, it might not be able to re-apply the commits and cause a conflict. But git pull should normally just check if there is any change locally and otherwise simply update the file with the origin version – Biggie Mac Jun 08 '23 at 06:57
  • @BiggieMac Install some UI for git, like SourceTree and will see what actually is happening. Git sometimes sees conflict for same line with same code, just in different commit hashes – Justinas Jun 08 '23 at 06:59

1 Answers1

0

git pull is the combination of two commands: git fetch, followed by git merge or git rebase (that second command depends on your configuration, and the options you pass to git pull).

"conflicts" can only occur at the second step. If you don't know where the conflicts come from, you can return your local branch to its pre-merge state by simply cancelling the merge or rebase :

# run:
git merge --abort
# or:
git rebase --abort

# if in doubt, run one then the other

Once you have aborted the merge or rebase, you have restored your local branch, and still have the result of git fetch : the remote branches have been updated.

Inspect the history you see in your local clone :

  • in a terminal, you can run :
git log --oneline --graph mybranch origin/mybranch

# or:
#  - @ is a shortcut for 'HEAD' or 'the current commit'
#  - @{u} is a shortcut for 'HEAD@{upstream}' or 'the upstream branch of my active branch'
git log --oneline --graph @ @{u}
  • or open a graphical viewer (gitk, gitg, git-extensions, git-kraken, your IDE integrated viewer ...) and look at the combined histories of your current branch and its remote counterpart

You should have the opportunity to see what changed.

Once you have a better understanding of what happened, you can run

git merge origin/mybranch
git merge @{u}
# or
git rebase origin/mybranch
git rebase @{u}

to reapply the exact same action as the second step of git pull, or do some changes on your branch first (drop a commit, cherry-pick another commit ...) before merging or rebasing.

If you want to avoid the "why do I get conflicts I wasn't aware of ?" situation, stop using git pull, use git fetch followed by git merge or git rebase. This gives you the opportunity to inspect what changes you received before dealing with them.

LeGEC
  • 46,477
  • 5
  • 57
  • 104