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 合并，这不应该成功，但它是。不可能！！怎么会这样？不符合上面的场景吗？

Answer 1

推和拉之间有很大的区别。当您想将提交推送到远程分支时，您的本地仓库需要来自远程的所有提交，当然还有您要推送的提交。当 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时，订购按数字。

Answer 2

你描述的情况

开发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 的投诉出现了分歧。

---

现在进入第二个场景。

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

"pull request 将 featureC 与 master 合并成功":

集中式回购：

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

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

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

我看不出为什么这不起作用！由于在集中式仓库中，featureD 被合并到一个最新的master 中，而master 没有分叉。