Git Master回购分支

Question

如果一个由8个人组成的小组正在从事一个项目，是否需要为所有成员设置单独的分支机构？

如果是这样的话

1. 主分支如何回购一个分支。
2. 分支之间合并会发生什么？
3. 每个成员如何获得小组其他成员的最新代码？

与每个成员都在同一个仓库中工作，但仍在他们各自的文件上工作相比，拥有单独的分支会引起更多的问题吗？

Answer 1

这在很大程度上取决于您的开发风格，是否由一个人负责合并每个人的工作并使其正确无误，或者是否将其分散到整个开发人员中。

因为每个克隆本质上都是其自己的存储库，所以所有开发人员都会得到一种“分支”，即克隆中的一个。 他们可以根据需要进一步分支，但是在需要推送时（默认情况下），他们必须确保其更改与中央存储库中的所有更改线性相关（如果您使用一个中央存储库作为霸主）。

至于你的问题：

1）如果您有一个中央裸共享存储库，则可以在其中进行“ git branch”调用以创建分支。 另外，每个开发人员可以从其克隆中的master创建一个分支，然后向上推该分支以创建它。

2）分支之间的合并非常简单。 如果存在冲突，开发人员将必须在合并期间更正这些冲突，然后将其显示为合并提交。 如果没有冲突，则合并将作为一系列提交添加到分支中而出现。

3）如果使用中央存储库设置，则每个成员将定期从所述存储库中进行“拉取”。 该拉动将附带创建的任何新分支或对现有分支的任何更新，以确保它们具有最新（共享）数据。 否则，一个开发人员可以要求另一位开发人员直接从其工作仓库中提取信息，以访问正在进行的代码以进行协作。

我认为，每个开发人员在共享存储库中拥有明确的独立分支可能比您想要的复杂得多，除非您专门负责将每个开发人员的更改合并到生产分支（或主分支）中。 只要确保每个开发人员都知道先拉（--rebase），然后再尝试进行更改并重新测试其更改（如果共享存储库中发生了任何更改）。

Answer 2

我说有一个主分支，一个开发分支，然后是各个分支，负责功能和修复，而不是团队成员。 考虑一下您将如何部署和管理代码，以便找到最佳的回购管理策略。 与8个人一起，您大概会有很多承诺。 如果您需要在两周后整理出一些代码，可以更容易地找到“ Evan编写了此代码，因此它将在evan分支中”或“它是残破的菜单项，因此它位于fix_menu分支中”。 向下跟踪某些内容时，您会找到分支，然后需要查找提交并完成合并。 如果另一个人介入协助功能怎么办？

1. 理想情况下，主分支始终值得进行生产，因此您不希望人们将其更改直接合并到该分支中。 因此发展分支。 一个人的代码在编写时可能会像一种魅力，但是在集成回去时会出现问题。 在develop分支（如staging / dev服务器）可以发现那些问题，使master尽可能纯净。

2. 合并非常简单。 只有在合并的两个提交之间相同的代码块不同时才存在冲突。 Git标记并让您在继续合并之前先解决冲突。

3. Git使用推/拉发送和获取提交。 您将更改推出，如果目的地中有新更改，git会提醒您。 拉实际上是两个操作-提取和合并。 Fetch表示从远程仓库中获取该分支机构的最新消息或所有分支机构的最新消息。 提取不会影响您当前的分支，因此很安全。 Pull会获取最新的，然后尝试将其合并到当前分支中。

您还可以设置跟踪分支。 git branch --track <newbranch> origin/develop这样，人们可以git branch --track <newbranch> origin/develop功能分支，同时能够轻松提取在develop分支上所做的更新。

另一个好技巧是习惯于查看提交日志的可视化，这样您就知道各种情况如何出现……当三个开发人员在同一个分支上工作时，它看起来就是这样……合并使viz-line看起来像这样。

如果您的团队是git的新手，那么我将从一个回购维护者开始。 如果每个人都在学习，事情将很快变得混乱。 让一个人管理主分支。 交流分支机构并关注发展。 下一步，练习壁球练习。 请记住，所有提交都将存在于分支的线性历史记录中-因此，当您将要素分支合并到开发中时，所有那些无用的小“正在进行的”提交都会使开发时间变得混乱。 压缩然后合并可保持历史记录整洁（并有助于防止回滚到不完整状态）。