GitHub:接受当前更改和传入更改之间的区别

sau*_*ngh 31 github

代码冲突时会出现问题。

VSCode 合并解析

正如您在上面给出的图像中看到的那样,有四个选项

  1. 接受传入的更改
  2. 接受当前更改
  3. 接受两个更改
  4. 比较变化

我想知道其中的差别之间Accept Current changesAccept Incoming changes

Bad*_*ibo 38

您位于功能分支上

1.git pull origin master

目前的变化

当前功能分支的更改。

即将发生的变化

您从主分支中提取的更改


2.git pull origin master --rebase

在变基期间,您的功能分支更改将应用​​到主分支中已有的提交之上。

目前的变化

分支上的更改。

即将发生的变化

功能分支上的更改。


* 变基后,您需要强制推送您的分支。使用--force-with-lease而不是--force

  • 嗯,这很令人困惑......为什么 git 不以源代码命名更改?毕竟,默认的合并策略隐藏在 gitconfig 中的某个地方。 (3认同)

Von*_*onC 35

这取决于导致该冲突的操作类型(合并或变基)。

在您的情况下,合并,其中:

  • 当前更改代表您拥有的内容(合并的目的地)
  • 传入更改代表您合并的内容(合并的源)

然后:

  • 选项 1(“接受传入更改”)将完全忽略您拥有的内容,并保留您合并的内容。
  • 选项 2(“接受当前更改”)将完全忽略您合并的内容,并保留您拥有的内容。

不要忘记,在 rebase 的情况下,“你拥有的”和“你合并的”是相反的

  • 感谢“rebase is returned”提示,我在这方面遇到了麻烦。 (8认同)
  • 因此,为了确保我理解:如果我在 BRANCH_1 上运行“git checkout master”并遇到冲突:传入的更改是 master 上的文件当前的更改是我在 BRANCH_1 上所做的,对吗? (2认同)

ros*_*net 19

如果这是由于 rebase 引起的冲突,你总是可以这样想象 -

  1. 你的主分支是固定的
  2. 源自 master 上较旧提交的功能分支正在将自身从那里转移到 master 上的最新提交(这就是 rebase 的核心)。

现在,如果你从大师的角度来看——

  • incoming changes是转移master的那些(即你的特性分支的变化),因此这个术语。

  • current changes 是已经存在于 master 中的那些(即由其他开发人员或您自己在 master 上完成的)。

在合并冲突的情况下,正如@VonC 所建议的那样,术语被颠倒了。