将Git扩展到团队使用

Question

在过去的3年中，我几乎每天都在为我所有的宠物项目使用git，并在工作中使用不在全球SVN存储库中的小型项目。我的工作流程非常类似于http://nvie.com/posts/a-successful-git-branching-model中著名的git分支模型来总结它：

• 我在分支中工作，一个分支为一个特性(即不混淆错误修复和新特性，等等)
• 我真的经常提交，通常只有2-5行，最大的提交通常是新函数等等。我大量地使用交互式提交工具来组织我的提交(例如，在修复一个导入声明和函数中的某个内容时，我倾向于将它分割成两个提交，当更改不相关时)。
• 最后，我倾向于在git merge选项中使用--no-ff，因为我有点喜欢gitk中的可视分支历史图。
• 从未真正使用过重基(除了修复)

当然，这个工作流从来不需要面对像在同一代码库上工作的团队那样严重的合并冲突。

现在我到处读到，有些项目非常关注保持“快速发展”的历史。为什么这很重要？在这方面你有什么选择？

我可以想象，当看历史时，“线性”历史更容易处理，但是:在我看来，拥有真正的历史也是很有价值的。没有快速转发的线性历史可能更类似于SVN历史，但我的git提交通常比平均SVN提交小得多，我认为它们比git中的分支合并(至少我的用法)要小得多。在没有-no-ff的情况下工作会使主人的历史变得“杂乱无章”(这是我对快速转发合并的关注)。

Answer 1

在使用共享Git存储库时，有一些常见的最佳实践。我所熟悉的是：

• 每个特性一次提交
• 不提交破坏构建的
• 试着把所有的东西都重新建立在主分支上

不同团队的工作方式可能会有所不同，所以我认为这个问题没有一个答案。例如，不同的团队会选择不那么严格地破坏构建。

在我看来，最主要的事情是始终将存储库保持在工作状态。您的同事应该能够检查任何提交，并从那里开始工作，而不会出现构建问题或其他明显的错误。在提交之前构建和测试所有内容。

要对共享存储库有一个很好的概述，最好在每次提交时只添加一个per修复或新特性。有些特性确实需要更多的提交，但是如果可能的话，提交应该按照每个子特性进行组织(例如，一个提交可以添加特性X所需的新API端点，然后另一个提交会在前端应用程序中添加实际的特性)。这也有助于不破坏构建，因为半实现的功能是错误磁铁。

拥有线性提交历史可以简化许多事情，但不是必需的。我认为这在不同的项目中会有很大的不同。有些可能要求您始终将您的更改重新基于master的尖端，而另一些则会接受特性分支。拥有线性历史非常有助于跟踪构建/版本号。例如，如果您具有线性历史记录，则可以使用Git描述而不使用短散列。