如果一个由8人组成的小组正在为一个项目工作，那么是否需要为所有成员设立单独的分支机构？
如果是的话
如果每个成员在同一个repo上工作，但仍然在他们各自的文件上，那么单独的分支会导致更多的问题吗？
答案 0 :(得分：2)
这在很大程度上取决于您的开发风格，无论您是否有一个人负责合并每个人的工作并使事情正确，或者您是否将其分散到您的开发人员中。
因为每个克隆本质上都是它自己的repo，所以你的所有开发人员都会得到一个“分支”，即克隆中的那个。如果需要，他们可以进一步分支，但是当需要推送时，他们（默认情况下）必须确保他们的更改与中央存储库上的任何更改都是线性的（如果您使用一个中央存储库作为霸主）。
关于你的问题：
1）如果你有一个中央裸共享仓库，你可以在其中进行“git branch”调用来创建分支。或者，每个开发人员都可以在他们的克隆中从master创建一个分支，然后推送该分支来创建它。
2）分支之间的合并非常简单。如果存在冲突，开发人员必须在合并期间更正这些冲突，然后将显示为合并提交。如果没有冲突，则合并将仅显示为添加到分支的一系列提交。
3）如果使用中央存储库设置，每个成员将定期从所述存储库中“拉”。创建的任何新分支或对现有分支的任何更新都将带有拉动，以便他们可以确保拥有最新（共享）数据。否则，一个开发人员可以请求另一个开发人员直接从他们的工作仓库中提取，以便访问正在进行协作的代码。
在我看来，每个在共享仓库中具有明确单独分支的开发人员可能比您想要的更复杂，除非您有专门负责将每个开发人员的更改合并到生产分支（或主人）中。只要确保每个开发人员都知道在他们尝试推送更改之前提取（--rebase），并在共享仓库中发生任何更改时重新测试他们的更改。
答案 1 :(得分：1)
我说有一个主分支，一个开发分支，然后是各个分支的功能和修复，而不是团队成员。考虑一下如何部署和管理代码，以便找到最佳的repo管理策略。有8个人，你可能会有很多提交。如果你需要在两周后对一些代码进行排序，那么更容易想象“Evan写了这个，所以它将在evan分支中”或“它是破碎的菜单项，所以它在fix_menu分支中”。当跟踪某些内容并找到分支时，您需要找到提交并完成合并。如果另一个人介入协助某个功能怎么办？
理想情况下，master分支总是值得生产，所以你不希望人们直接将它们的变化合并到那里。因而发展分支。一个人的代码在编写时可能像魅力一样，但在集成时会有问题。开发分支（就像staging / dev服务器）是发现那些让master尽可能纯粹的问题的地方。
合并非常简单。在合并的两个提交之间相同的代码块不同时，只有冲突。 Git标记并让您在继续合并之前解决冲突。
Git使用push / pull发送和抓取提交。如果您的目的地有更新的更改，您可以将更改推送出去，git会提醒您。 Pulling实际上是两个操作 - 获取和合并。 Fetch说给我这个分支的最新版本或来自远程仓库的最新分支。 Fetch不会触及您当前的分支，因此它是安全的。 Pull将同时获取最新版本，然后尝试将其合并到当前分支中。
您还可以设置跟踪分支。 git branch --track <newbranch> origin/develop通过这种方式，人们可以分离功能分支，同时能够轻松获取开发分支上的更新。
另一个好的建议是习惯于查看提交日志可视化，以便了解各种方案的出现......当三个开发人员在同一个分支上工作时，它看起来就像这样...一个合并使得viz-line看起来像这样。
如果你的团队是git的新手，我会从一个repo维护者开始。如果每个人都在学习，事情就会变得一团糟。让一个人管理主分支。沟通分支并密切关注发展。作为下一步，通过挤压来实践变革。请记住，所有提交都将存在于分支的线性历史中 - 因此，当您将功能分支合并到develop中时，所有那些无用的“正在进行中的工作”提交都会使开发时间线混乱。压缩然后合并可以保持历史记录清洁（并有助于防止回滚到不完整的状态）。