假设共有三个人参与该项目。人A，B和C.他们三人都从主人那里创建了一个分支。使用github的正确工作流程应该是什么？
让我们先说A合并为主人，为了将B＆B的代码合并到主人身上，B应做些什么，同样的问题转到C.
团队合并多久掌握一次？日常？每周？或者何时实施新功能？
关于使用git / github / bitbucket作为团队的任何其他好建议吗？
非常感谢！
答案 0 :(得分：1)
如果你们所有人都开始使用分布式代码管理，那么从一开始就做好它是个好主意。选择一个既定的工作流程，阅读它，玩一下，然后提高工作效率。
我个人最喜欢的是＆＃34;每个功能分支＆＃34;作者：Dymitruk：http://dymitruk.com/blog/2012/02/05/branch-per-feature。这是非常强大的，演示非常清晰和完整，它只是简单的作品和IMO做的一些事情比＆＃34;通常＆＃34;工作流程（http://nvie.com/posts/a-successful-git-branching-model/在此处的另一个答案中公布），您有专门的＆＃34;开发＆＃34;科。当然，你也不会对后者做错。
您的问题将在这些页面上得到解答（Dymitruk执行＆＃34;合并为主人＆＃34;根本不同，订购没有问题/问题;基本上＆＃34;合并到主人＆＃34;等同到＆＃34;生产发布＆＃34;）。
只要您处于现在的状态（即，对所有这一切都不熟悉），就不要试图挽救它并发明自己的方案。
答案 1 :(得分：0)
在将分支合并为master之前，请务必执行git pull origin master。
之后将您的更改推送到特定分支。
git push origin brnach_name 现在，您可以与master合并。
通常应该将其分支与master合并。只要有新功能。
答案 2 :(得分：0)
在过去的12个月里，我一直在使用this Git feature branch model，在4名开发人员和我的团队中使用QA获得了良好的效果。
我在团队中推广定期推/拉 - 我们很快就知道代码是否破坏了其他代码，可以在失控之前解决合并冲突，修复潜在问题等等。它让团队定期沟通和协作。 Vincent说＆＃34;这些行为非常便宜和简单，它们被认为是您日常工作流程的核心部分之一＆＃34;。
Vincent接着将origin存储库描述为＆＃34;中央事实存储库＆＃34;开发人员从中分配自己的存储库。我们使用master分支来反映生产服务器上的内容（带有版本发布的标签），develop以反映我们的登台服务器上的内容，以及具有JIRA票证代码的功能特定分支（例如PROJ-001-fixes-all-teh-bugs）以及JIRA整合。
origin更新＆＃34;真相＆＃34;。
Vincent接着描述了修补程序分支和发布分支，尽管我们还没有必要使用后者。
由于我们已将BitBucket绑定到JIRA，我们注意到私有fork存储库不会更新票证状态等，但每天推送到origin（即使在功能分支上）也可以
一旦功能分支准备好，我们的开发人员就会提出拉取请求，我们会召开会议批准/调整，然后它会合并到develop，然后master合并到其中。如果老板决定一个功能很糟糕，我们可以恢复分支合并，并使用其他功能 - 一个强大的工具。
一些开发人员发现在fork上工作太多的努力/混乱开始。坚持下去！它成为第二天性（即使对我来说，我也不是很好），它使我们远离棘手的情况和可怕的代码。
如果一切听起来不错......
让我们先说A合并为主人，为了将B＆＃39代码合并到主人身上，B应做些什么，同样的问题转到C。
使用Vincent的模型，A B和C将在功能分支中处理私人回购分叉。当他们在自己的叉子上工作时，他们可以经常互相拉扯。不可避免地会有一个开发人员使用最新的代码将其推送到origin上的功能分支并放入PR。
团队应该多久合并掌握一次？日常？每周？或者何时实施新功能？
只有在即将部署该功能时才会合并到origin/master。我们首先合并到origin/develop，在我们的暂存环境中测试它，然后将develop分支PR到master。
我们发现将活动功能分支至少每天合并并推送到origin是一种很好的做法并更新JIRA状态。
关于使用git / github / bitbucket作为团队的任何其他好建议吗？
了解如何处理合并冲突，恢复提交以及毫不费力地恢复合并提交:)在团队内定期讨论。如果您喜欢Vincent的模型，请将文章发送给每个人，并讨论它如何运作。甚至可能在假项目上练习Git-fu。
答案 3 :(得分：0)
这个答案假定如下......
<强>服务
Git Hub
团队规模
2＆lt; = x＆lt; = 7
<强>存储库
私人
对于从事小型项目的小型开发人员团队，您可以将所有开发人员添加为协作者。这将为每个协作者提供读/写访问权限。
鉴于上述情况已经完成，每个开发人员都可以创建一个功能分支，他/她可以执行他们认为合适的任何类型的修改，并在时间到来时发出拉取请求。
什么是拉取请求？拉取请求是一种将您所做的更改与团队其他成员进行通信的方式。您可以发出拉取请求，团队将能够审核您的工作，提出建议，并在每个人都满意时将工作合并到生产中。
您可以随时将自己的作品合并到作品中，但这通常是推荐的 NOT 。毕竟，你是一个团队。
那么，你应该多久一次？关于你应该多久提交的频率没有严格的指导，但保持粗粒度被认为是一种好的做法。无论何时对代码进行更改，都必须具体 - 您可以在提交消息中轻松描述。
现在，关于项目工作流程。您已经建立了一个存储库并设置了协作者，是时候完成一些工作了。
每个协作者都会克隆存储库并创建一个他们将要处理的功能分支。他们做了一些工作 - 阶段 + 提交和推送他们的工作上游。为了让自己了解他们在功能分支上所做的所有更改，请记住指示git不时进行拉动。或者，您可以指示git获取上游并手动合并它。
当您的某个团队成员准备好其功能分支时，他们应该发出拉取请求。此时，您将查看他们所做的工作，做出任何适当的评论，如果每个人都满意，请将其合并到生产中。
以上信息是为介绍级别的过程而编写的，并且绝不是如何使用git的唯一方法。它应该作为小型项目团队中git工作流的介绍材料。答案并未涵盖在任何服务（Git Hub，Gitbucket等）上运行项目的所有可能方式。希望你发现它内容丰富。