git - Git 集中式工作流程

Question

假设开发人员正在使用 git 集中式工作流，并且 github 有 2 个文件 a.txt 和 b.txt。

现在 dev1 成功推送 c.txt。现在如果 dev2 推送 d.txt，它是非快进的，他不能推送，所以，因为他必须先在本地合并 dev1 的更改，然后再推送。

现在另一个场景，假设 dev1 创建分支 featureC 并在其中包含文件 c.txt 以及 a.txt、b.txt 和推送。类似的 dev2 创建分支 featureD 并在其中包含文件 d.txt 以及 a.txt、b.txt 和推送。

现在提出了将 featureC 与 master 合并的请求，并且成功了。再次提出拉取请求以将 featureD 与 master 合并，这不应该成功，但它是。不可能！！怎么会这样？不符合上面的场景吗？

score 1 · Accepted Answer

你描述的情况

开发者1：

a---b - master
     \
      c - featureC

开发2：

a---b - master
     \
      d - featureD

集中式回购：

a---b - master

在您的第一个场景中（您似乎同意），看起来两个开发人员都试图直接推送到集中式 repo 上的同一个分支：

在 dev1 将其本地推master送到集中式之后：

a---b---c - master

然后，如果 dev2 在本地a---b---d - master并尝试将其推送到master集中式存储库，git则抱怨。它应该怎么做？

这：

a---b---d - master #nope

将是错误的，因为c被丢弃。

这：

a---b---c    #nope
     \
      +---d

也会错，应该master指向哪里？没有办法git知道。因此，投诉，master已经分歧。

现在到你的第二个场景。

我将假设拉取请求会导致集中式存储库中的拉取。

“提出了将 featureC 与 master 合并的请求，并且成功了”：

集中式回购：

      c - featureC
     / \
a---b---x - master

然后“拉请求将 featureD 与 master 合并”：

      c - featureC
     / \
a---b---x---y - master
     \     /
      +---d - featureD

我看不出为什么这不起作用！由于在集中式回购中，featureD被合并master为最新的，并且master没有分歧。

score 1 · Accepted Answer

推和拉之间有很大的区别。当您想将提交推送到远程分支时，您的本地仓库需要来自远程的所有提交，当然还有您要推送的提交。当 dev2 推送 d.txt 的提交时，情况并非如此，而对引入 c.txt 的先前提交一无所知。

现在有了拉取请求，情况就不同了。您始终可以保存任何不冲突的内容，即提交仅影响不同文件的情况。

实际上，这是一个拉取请求，在您的第一种情况下，当 git 告诉 dev2 在他推送之前拉取（合并）。

当没有冲突时，您始终可以拉（快进或合并），但您只能在您的分支与要推送到的远程分支保持最新时推送。

本地存储库中的开发人员很容易查看提交实际请求的更改。假设 dev1 分支到 featureA 以从 master 开发一些功能，今天早上。晚上他想看看他所做的所有改变，当他登记入住时，他会做

git format-patch master..featureA

所有按顺序编号的提交都写入文件NUMBER-TITLE.patch。

所有这些补丁都可以合并到，origin/master无论origin/master（如果已经有新的更改已经转到origin/master），当没有补丁无法应用于 origin/master 时，按数字排序。

2 回答 2