git - 对术语的混淆,"他们的"与"我的"

Cap*_*ack 22 git git-flow git-branch

我对他和他们的意思完全混淆了.在这个特定的情况下,我有一个功能分支,我刚刚压缩了大约80个提交,rebase -i并将其合并回来develop.我遇到了一些冲突,我只想使用我的功能分支上的任何代码.我试过"我的",但实际上似乎反其道而行之.

有人可以对这个术语有所了解吗?

Kei*_*ith 39

ourstheirs是一个有点令人困惑的概念; 执行rebase时会加剧:

当执行合并,ours是指你归并的分支进入,并theirs表示要合并的分支.因此,如果您尝试在合并过程中解决冲突:

  • 用于ours接受我们当前所在分支机构的变更
  • 用于theirs接受我们合并的分支的更改.

这是有道理的,对吗?

重订,ours并且theirs被反转.重新选择文件到"分离的"HEAD分支.目标是HEAD分支,并且merge-from是rebase之前的原始分支.这使得:

  • --ours rebase正在构建的匿名者,和
  • --theirs 被重新定位的人;

即,rebasing在我们打算重新绑定的分支顶部重放当前分支的提交(一次一个).

  • 你说"他们指的是你正在合并的分支*来自*"然后"用他们接受我们正在合并*进入*的分支的变化" - 是吧? (8认同)
  • "使用"一词的使用不当.如果我在一个分支上,并希望与master合并,运行"Git checkout --thehis filename(s)"将使master的文件优先,这将覆盖我的分支副本."--ours"是相反的,在合并中赋予我的分支优先权 (2认同)
  • 嗯,我发现这个问题完全符合我的困惑。我读了很多票,但仍然不知道任何信心水平的答案。返回Google。 (2认同)
  • 都是矛盾的答案。当您在 Gitlab 中通过分支比较进行合并时,您实际上并没有“进入”任何特定分支,至少您没有明确知道。当您不使用命令行时,“源”和“目标”分支将是更明确的术语。 (2认同)

mip*_*adi 19

"我们的"(和"我的")指的是当前的分支; "他们的"是指被合并的分支.听起来你真的想要使用"他们的".

  • 我认为恰恰相反。 (3认同)