Git 集中式工作流程
Git centralized workflow
假设开发人员正在使用 git 集中式工作流程并且 github 有 2 个文件 a.txt 和 b.txt。
现在 dev1 推送 c.txt 成功。
现在如果 dev2 推送 d.txt，它是非快进的，他不能推送并且正确地这样，因为他必须首先在本地合并 dev1 的更改然后推送。
现在另一个场景，
假设 dev1 创建分支 featureC 并在其中包含文件 c.txt 以及 a.txt、b.txt 和推送。
Simillty dev2 创建分支 featureD 并在其中包含文件 d.txt 以及 a.txt、b.txt 和推送。
现在提出拉取请求以将 featureC 与 master 合并，并且成功。
再次提出拉取请求以将 featureD 与 master 合并，这不应该成功，但它是。不可能！！怎么会这样？不符合上面的场景吗？
你描述的情况
dev1:
a---b - master
\
c - featureC
dev2:
a---b - master
\
d - featureD
集中式回购：
a---b - master
在你的第一个场景中（你似乎同意），看起来两个开发者都试图直接推送到集中存储库上的同一个分支：
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 发生了分歧。
现在进入第二个场景。
我假设拉取请求导致集中式回购中的拉取。
"pull request is made to merge featureC with master and it's successful":
集中式回购：
c - featureC
/ \
a---b---x - master
然后"pull request is made to merge featureD with master":
c - featureC
/ \
a---b---x---y - master
\ /
+---d - featureD
我看不出为什么这不起作用！由于在集中式回购中，featureD 合并到最新的 master 中，并且 master 没有分歧。
推和拉有本质区别。当您想将提交推送到远程分支时，您的本地存储库需要来自远程的所有提交，当然还有您要推送的提交。当 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，按编号排序。
假设开发人员正在使用 git 集中式工作流程并且 github 有 2 个文件 a.txt 和 b.txt。
现在 dev1 推送 c.txt 成功。 现在如果 dev2 推送 d.txt，它是非快进的，他不能推送并且正确地这样，因为他必须首先在本地合并 dev1 的更改然后推送。
现在另一个场景， 假设 dev1 创建分支 featureC 并在其中包含文件 c.txt 以及 a.txt、b.txt 和推送。 Simillty dev2 创建分支 featureD 并在其中包含文件 d.txt 以及 a.txt、b.txt 和推送。
现在提出拉取请求以将 featureC 与 master 合并，并且成功。 再次提出拉取请求以将 featureD 与 master 合并，这不应该成功，但它是。不可能！！怎么会这样？不符合上面的场景吗？
你描述的情况
dev1:
a---b - master
\
c - featureC
dev2:
a---b - master
\
d - featureD
集中式回购：
a---b - master
在你的第一个场景中（你似乎同意），看起来两个开发者都试图直接推送到集中存储库上的同一个分支：
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 发生了分歧。
现在进入第二个场景。
我假设拉取请求导致集中式回购中的拉取。
"pull request is made to merge featureC with master and it's successful":
集中式回购：
c - featureC
/ \
a---b---x - master
然后"pull request is made to merge featureD with master":
c - featureC
/ \
a---b---x---y - master
\ /
+---d - featureD
我看不出为什么这不起作用！由于在集中式回购中，featureD 合并到最新的 master 中，并且 master 没有分歧。
推和拉有本质区别。当您想将提交推送到远程分支时，您的本地存储库需要来自远程的所有提交，当然还有您要推送的提交。当 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，按编号排序。