Jam*_*son 6 git version-control github
在我的一个大学项目中,我是一个由4名开发人员组成的小组,负责从头开始开发Web应用程序.我们都对Git有了非常基本的了解,并决定采用它进行代码库协作,我们有一个repo设置,每个人都是GitHub的合作者.
在过去的几个月里,我们只是克隆并提交到主分支机构,这已经很好了.然而,最近有时两个或两个以上的人同时在代码库上工作,我们经常最终会有一些人在提交时落后并且在提交之前必须克隆repo,这有时最终会导致他们的更改丢失.
今天,其中一个小组成员谈到了一个"开发"分支,我们都克隆并提交,然后在每个sprint结束时合并到master分支.我们试过这个,但没有真正看到改进,因为我们仍然都在使用相同的代码库,因此出现了与之前相同的问题.
其他人有了分叉的想法(这对我来说是新东西)主要的回购,然后处理它然后将拉请求发送到主回购,然后可以合并.这在实践中听起来像一个好的计划,因为如果更改了代码,则可以检查更改并进行修复.无论如何,这就是我理解它的方式.
但正如我所说,我们对Git都很陌生,对整个想法有一个非常基本的把握.组建由4名开发人员组成的团队的标准方法是什么？我已经了解了一些Git文档,但对于只知道如何克隆并提交到主分支的人来说,这一切都让人感到困惑.
感谢您的任何帮助!
谈论开发方法中的“标准”事物是危险的，因为几乎不存在这样的东西。开发人员团体倾向于以适合他们的方式组织自己（或者按照管理层告诉他们的方式组织自己）。
您所确定的所有方法都是使用分布式版本控制系统的有效方法。我建议您不会从替代方案中看到巨大的好处，因为您正在开发一个大学规模的绿地项目，由一小群人在同一地理位置，说相同的语言，具有相似的能力，并且对于结果应该是什么有同样清晰的想法。当这些情况并非如此时，Git 往往会大放异彩。
对于分布式项目，您确实希望一个人充当项目规范版本的看门人，拉取请求非常有效。当您希望每个人都拥有有效的平等提交访问权限时，开发分支是一个很好的解决方案。人们倾向于使用开发分支，这样他们就可以拥有一个始终可用的版本供人们使用。我假设您当前没有用户，这就是为什么您不太可能从这种方法中看到太多好处。
我基本上会继续像你一样，除非你们互相交谈并认为某些事情不适合你们作为一个团队，在这种情况下，你们可以决定其他工作方式之一是否更适合你们。
| 归档时间： |
|
| 查看次数： |
139 次 |
| 最近记录： |