Question

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

现在dev1成功推送了c.txt。现在，如果dev2推送d.txt，它不是快进的，他不能推送和正确的，因为他必须先在本地合并dev1的变化然后推送。

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

现在请求将featureC与master合并，并且它成功。再次请求将featureD与master合并，这应该不会成功，但确实如此。它不可能！怎么会这样？它不符合上述情况吗？

Answer 1

您描述的情况

DEV1：

a---b - master
     \
      c - featureC

DEV2：

a---b - master
     \
      d - featureD

集中回购：

a---b - master

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

dev1将其本地master推送到集中的{/ p>

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已经分歧。

现在进入第二种情况。

我假设拉取请求会导致集中仓库中的拉动。

＆＃34;拉取请求将featureC与master合并，并且它成功了＆＃34;：

集中回购：

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

然后＆＃34;拉取请求将featureD与master＆＃34;：

合并

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

我认为没有理由不这样做！由于在集中式仓库中，featureD合并为最新的master，master尚未发散。

Answer 2

推拉之间有一个明显的区别。当您想将提交推送到远程分支时，本地存储需要来自远程的所有提交，当然还有您想要推送的提交。当dev2推送d.txt的提交时，情况并非如此，而不知道前一次提交的任何内容，引入了c.txt。

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

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

当没有冲突时，您可以随时拉（快进或合并），但只有当您的分支与您要推送的远程分支保持同步时才能推送。

本地存储库中的开发人员很容易看到提交请求实际发生了哪些更改。今天早上假设dev1分支到featureA来开发master的一些功能。晚上，他想看到他所做的所有改变，当他办理登机手续时，他会做什么

if exist %SystemRoot%\Sysnative\*

按顺序编号的所有提交都将写入文件git format-patch master..featureA。

所有这些修补程序都可以合并到NUMBER-TITLE.patch，无论origin/master的状态如何（如果已经有新的更改进入origin/master，那么当没有补丁无法应用时）原产地/主人，按编号排序。