团队应该如何将他们的变化推向git master？

Question

过去我们（同事和我）会将我们的变化直接推向主人。然后告知对方需要撤消的更改。

一位新同事建议分享git repo以及何时进行更改。他做了拉请求。我仍然会在主回购中接受请求拉动。

团队合作时，哪种传统/常用方法？或者有更好的方法吗？

Answer 1

这取决于您是否想拥有一个中央存储库。许多组织在切换到git时一直在使用并继续使用中央存储库。它还取决于访问权限，信任以及您有多少开发人员。如果你只是少数几个开发人员并且你们彼此相互信任，我会选择一个中央的裸存储库，每个人都会推动并从中拉出来。保持简单。

如果您是100名开发人员，也许还有您不信任使用中央存储库的外部开发人员，并且出于某些其他原因而希望限制访问，则拉取请求可能就是解决方案。

重要的是要看看你想要什么样的工作流程，并记住git不会妨碍你，让你自己决定。

Answer 2

传统的方法是fork-pull，即Linux内核的Linus-fork是官方的。与当前方法的不同之处在于您对更改的控制量。如果你不需要这种控制，或者你无法检查更改，因为你没有时间这样做，那么手动拉动没有任何好处。 Git确实可以很好地处理重置/删除，你可以随时回溯历史。

Answer 3

在团队中工作时，分配git repo是一种更好的方法，因为它可以确保您的repo和代码永远不会遇到不一致的阶段。然而，这种做法在世界上并不常见。大多数团队都把它作为一个传统，每个人同时在同一个分支上工作，这有点危险，但可以通过在repo的post-receive hook中添加电子邮件警报发送功能来提高效率队友可以在收到电子邮件提醒后立即撤消更改。

我希望这会有所帮助。

Answer 4

我想说有两个主要的工作流程：

1. 正如马格努斯所说，每个人都在推动“有福”的裸体回购，同时在当地的克隆上工作。
2. 更多受限制的工作流程可能表明有限数量的人有推送访问受祝福的回购，而所有其他贡献者要么发送拉请求，要么技术上难以提供补丁。但他们正在从有福的回购中撤出，以保持他们的回购同步。此工作流程意味着在更改进入受祝福的仓库之前，“中尉”进行代码审查