116

Problem occurs when codes are conflict.

VSCode merge resolution

As you see in image given above that four options are there

  1. Accept incoming changes
  2. Accept current changes
  3. Accept Both changes
  4. Compare changes

I want to know the difference between Accept Current changes and Accept Incoming changes

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
saurabh Singh
  • 4,902
  • 3
  • 11
  • 12

3 Answers3

145

It depends on the type of operation (merge or rebase) leading to that conflict.
When you are trying to resolve conflicts in Git, you are typically dealing with two sets of changes:

  1. Changes from your Current Branch: Often the branch you are currently working on or have checked out. In your explanation, this is described as "what you have" or "the destination of the merge".

  2. Changes from the Incoming Branch: The branch you are trying to merge into your current branch (during a merge) or the branch you are attempting to apply on top of another branch (during a rebase). This is "what you merge" or "the source of the merge".

Now, in the context of the conflict resolution options in VSCode:

  • Accept Incoming changes: That will discard the conflicting changes from your current branch ("what you have") and keep the changes from the incoming branch ("what you merge").

  • Accept current changes: That will keep the conflicting changes from your current branch ("what you have") and discard the changes from the incoming branch ("what you merge").

It is important to understand that during a rebase, the roles of "current branch" and "incoming branch" are essentially reversed. In a rebase, your current branch is being applied on top of the incoming branch. So, when faced with conflicts:

  • "Current changes" during a rebase will refer to the branch onto which you are rebasing (usually the base branch).
  • "Incoming changes" during a rebase will refer to the branch that you are trying to rebase (the changes you are attempting to apply on top of another branch).
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 4
    So to make sure I understand: If I'm on BRANCH_1 and I run "git checkout master" and get conflicts: Incoming changes are what the file is like on master Current changes are what I did on BRANCH_1, correct? – Nick Tydryszewski Jul 29 '20 at 13:41
  • @NickTydryszewski Yes, provided you did a `git checkout -m master` (https://git-scm.com/docs/git-checkout#Documentation/git-checkout.txt--m) – VonC Jul 29 '20 at 14:25
  • @VonC "Option 1 (='Accept incoming changes') would ignore completely what you merge, and keep what you had." Is that true? My feeling tells me it's the opposite. – danzel Feb 03 '21 at 09:56
  • @danzel Agreed. I have edited the answer accordingly. – VonC Feb 03 '21 at 10:00
  • 5
    Thanks for the "rebase is reversed" tip, I was having trouble with this. – eocavalcanti Dec 03 '21 at 14:09
  • This answer is more confusing than it is helpful. "What you had" and "what you merge" are just so ambiguous, especially since you're also trying to explain what happens in a rebase. – Mdev Aug 12 '23 at 18:04
  • 1
    @Mdev Thank you for your feedback. I have rewritten the answer to clarify that point. – VonC Aug 12 '23 at 18:59
  • @VonC Wonderful, I appreciate that! – Mdev Aug 13 '23 at 04:11
57

If it's a conflict due to a rebase, you could always imagine like so -

  1. Your master branch is fixed
  2. A feature branch that originated from an older commit on master, is shifting itself from there to the latest commit on master (that's what a rebase is, at its core).

Now, if you see from the point of view of master -

  • incoming changes are the ones that move to master (i.e. changes in your feature branch), hence the term.

  • current changes are the ones that are already present in master (i.e. ones done by fellow developers or yourself on master).

In case of merge conflicts, as suggested by @VonC, the terminology is reversed.

roshnet
  • 1,695
  • 18
  • 22
  • So, if I was on my feature branch and I ran `git pull --rebase origin master` Will `incoming changes` be the changes on master? – Mahmoud Tokura May 26 '21 at 19:47
  • 1
    @MahmoudTokura technically, yes. But in practice, we almost never merge master into our feature branch. – roshnet May 26 '21 at 21:13
33

You are on a feature branch

1. git pull origin master

Current changes

Changes on your current feature branch.

Incoming changes

Changes you are pulling from i.e the master branch

2. git pull origin master --rebase

During rebase your feature branch changes are applied on top of the commits that are already there in master branch.

Current changes

Changes on the master branch.

Incoming changes

Changes on the feature branch.

* After a rebase, you need to force push your branch. Use --force-with-lease instead of --force

Badal Saibo
  • 2,499
  • 11
  • 23
  • 2
    Well, this is pretty confusing... Why does git not name the changes after the source? After all, the default merge strategy is hidden somewhere in gitconfig. – davidav Sep 14 '22 at 12:42