在我的一个大学项目中，我是一个由4名开发人员组成的小组，负责从头开始开发Web应用程序。我们都对Git有了非常基本的了解，并决定采用它进行代码库协作，我们有一个repo设置，每个人都是GitHub的合作者。
在过去的几个月里，我们只是克隆并提交到主分支机构，这已经很好了。然而，最近有时两个或两个以上的人同时在代码库上工作，我们经常最终会有一些人在提交时落后并且在提交之前必须克隆repo，这有时最终会导致他们的更改丢失。
今天，其中一个小组成员谈到了一个“开发”分支，我们都克隆并提交，然后在每个sprint结束时合并到master分支。我们尝试了这个，但没有真正看到改进，因为我们仍然使用相同的代码库，因此出现了与之前相同的问题。
其他人有了分叉的想法（这对我来说是新事物）主要的回购，然后处理它然后将拉请求发送到主回购，然后可以合并。这在实践中听起来像一个好的计划，因为如果它破坏了代码，可以检查更改并进行修复。无论如何，这就是我理解的方式。
但正如我所说，我们对Git都很陌生，对整个想法有一个非常基本的把握。组建由4名开发人员组成的团队的标准方法是什么？我已经了解了一些Git文档，但对于那些只知道如何克隆并提交到主分支的人来说，这一切都让人感到困惑。
感谢您的帮助！
答案 0 :(得分：3)
您需要查看Git Workflow和/或分支模型。有很多，这里有一个开始：
A successful git branching model
您需要考虑发布，登台，制作等概念，因为这可以很容易地表现出来。它基本上都与组织有关。
答案 1 :(得分：0)
谈论开发方法中“标准”的东西是危险的，因为几乎没有这样的东西。开发人员群体倾向于以对他们有用的方式组织自己（或者以管理层告诉他们自己组织的方式）。
您确定的所有方法都是使用分布式版本控制系统的有效方法。我建议你没有从备选方案中获得巨大的好处，因为你正在开展一个大学规模的绿色实地项目，在同一地理位置上有一小群人，说同一种语言，具有相似的能力，并且同样明确的结果应该是什么。当任何情况都不是这样时，Git会发光。
对于您真正希望一个人充当项目规范版本的守门员的分布式项目，拉取请求的工作非常好。当您希望每个人都拥有有效的相同提交权限时，开发分支是一个很好的解决方案。人们倾向于使用开发分支，以便他们可以使用一个始终工作的版本供人们使用。我假设您目前没有用户，这就是为什么您不太可能从这种方法中获得太多好处。
除非你互相交谈并决定某些事情不适合你作为一个团队，否则我基本上会继续这样做，在这种情况下你可以决定其他一种工作方式是否对你更好