Git分叉/合并冲突？

Question

Git分叉/合并冲突？

3

我还不太了解版本控制和Github。有些事情让我感到困惑，似乎无法理解。假设我们是两个人在同一个Rails应用项目上工作。A拥有主仓库，B是派生仓库的人。现在B创建了一个在应用程序中不存在的新功能。为了达到预期的结果，他必须编辑一些文件，并在某些情况下移动它们。

与此同时，A也正在开发一个非常相似的功能，需要编辑并移动非常相似的文件，但源代码却非常不同。或者他正在开发一个不同的功能，需要编辑这些相同的文件，但是源代码不同。现在B提交了一个拉取请求，而A也必须将他创建的功能合并到主分支中。Github如何调和这些被两个不同人以不同方式修改的相同文件？

- Shikasan

据我所知，我认为推送到Github的任何内容都将覆盖先前的提交。 - Marco Scannadinari

问题是，如果我们想保留这两个功能怎么办？ - Shikasan

我会允许主分支所有者（A）进行推送，然后其他人（B）可以从该提交中拉取带有人A功能的文件，然后将其更改推送为[文件名（s）]_B。 - Marco Scannadinari

所以基本上我们只需要跟踪对方正在做什么。谢谢你澄清了这一点。 - Shikasan

2个回答

1

Github在pull requests中使用合并。有时，在Guy B的存储库上需要手动合并以解决无法处理的pull request合并冲突。有时重新设定可能工作得更好，但您的情况可能会有所不同。

个人认为，最后添加其代码的人负责在通过pull requests或手动集成将其推回权威存储库或分支之前合并/重新设定。

- Srdjan Grubor

现在有点清楚了，但我还是有点困惑。我猜随着时间的推移我会更好地理解，谢谢。完全无关的话题，什么是变基？ - Shikasan

重新定位是在你的分支上添加其他人的更改，然后再添加你的更改。例如，人员A有A->B->C->D，而您的分支具有A->B->C2->D2。重新定位将人员A自上次重新定位/合并以来发生的提交添加到您的行中，因此您的行将如下所示：A->B->C->D->C2->D2。 - Srdjan Grubor

哦，我明白了。我还有很多要学习的东西。看来创建Github的人们在其中投入了很多心思。感谢您提供的信息。 - Shikasan

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Tuxdude · Accepted Answer

当我在多用户项目中工作时，工作流程如下：

- Guy A在本地仓库进行更改 -> 推送更改到远程仓库 - Guy B在本地仓库进行更改 -> 推送更改到远程仓库（此处将失败） - Guy B执行"git fetch"，然后执行"git merge"或"git rebase"，以便将他的更改与来自远程的更改合并。Guy B应立即将这些更改推送到远程。 - Guy A在他的本地仓库做了一些更改 -> 推送更改（这里又将失败）。他遵循类似于Guy B的一组步骤来合并或重新设置基础。

而在Github术语中，将更改推送到远程仓库的概念在Github中是通过"pull request"来处理的。当有人向某个仓库的某个分支发送拉取请求时，请求者有责任对其更改与目标进行合并/重新设置基础，然后发送"pull request"。

如果接收拉取请求的用户看到许多冲突，可能是因为请求者没有花足够的心思进行合并，或者因为他必须处理先前的拉取请求，现在会导致冲突，那么所有者可以要求请求者在最新更改的基础上发送更新的"pull request"。

换句话说，接收拉取请求的人通常只会接受"快进合并"，但有少数例外情况。