对于所有开发人员都在所有项目上工作的小团队，哪种Git流程最好？

Question

对于所有开发人员都在所有项目上工作的小团队，哪种Git流程最好？

5

我们是由5名开发人员组成的小团队。我们刚从Subversion迁移到Git，并且在找到适合我们的工作流程方面遇到了些困难。

我们尝试一开始就坚持使用gitflow工作流，遵循成功的git分支模型文章，但老实说，对于我们所做的小项目来说似乎有些不可承受，我们中的一些人也因为它与我们所熟悉的subversion模型截然不同而难以严格遵循它。

因此，我们现在不使用发布分支来进行发布，因为它似乎是不必要的，尽管我们确保我们的主分支是干净的。同样地，我们也不使用特性分支，而是直接在develop上工作。

我不确定发布方面的情况，但我认为我们应该使用特性分支，只是我不知道如何使用它们。在提到的文章以及其他文章中，建议将特性保留在本地，并在将其合并回开发之前压缩其中的提交。如果只有一个开发人员在该特性上工作，那看起来很容易，但我们的情况是任何人随时可能想要/需要接手项目并继续工作。因此，项目经常更改所有权，并且即使尚未完成，所有工作也必须被推送到服务器，以便任何人都可以拉取它并继续工作。

因此，在远程工作中，我们发现很难保持清洁，我们的历史记录是一长串小提交，但据我所知，我们不能压缩它们或重新定义任何分支，因为这会更改公共历史记录。

我们想做得正确，但不要让它变得过于复杂。所以，您有什么关于我们最好使用哪种工作流程以及如何正确实施它的想法吗？

- ithil

2

很多个人意见：小的提交是好的，它们容易撤销/挑选/合并，并提供了良好的历史文档。我讨厌压缩功能分支，这有什么意义呢？不要头朝下地潜入。您可以从像SVN这样的集中式工作流开始；Git仍然非常值得使用。一旦您感到舒适，就可以尝试适合您开发风格的其他东西。 - musiKk

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- fejese · Accepted Answer

您可以在功能分支上继续使用小提交，并且仅在合并回“develop”分支之前进行rebase和/或squash。从那时起，该功能分支不再具有任何相关性，因此混淆其历史记录不一定是问题。

创建功能分支
完成工作，在功能分支上提交推送
其他开发人员可以接管并继续工作
准备就绪后，重新基于develop，压缩小的提交并将其合并回去

这解决了您不希望用小的提交'polluting'历史记录的问题。这种方法唯一的问题是您不经常更新功能分支，因此您最终会有更大的合并。

根据我的经验，最好的方法是采用非常短暂的功能分支，并使用功能切换。这样，您可以合并不完整但不损坏的功能分支，消除巨大的合并困难。

拥有真正的提交历史并不是坏事。它有助于审查，如果需要，使挑选更容易，并且也有助于合并。您的主分支应保持干净：每个发布一个提交。Develop 可以稍微不那么干净，每个功能/票据分支一个提交。但是，您的功能分支可以正确包含历史记录。

此外，如果您确实想使提交图稍微易于跟踪，则可以经常在develop上进行rebase并将其推送。不建议更改公共历史记录，因为如果不是每个人都知道这一点，可能会导致问题。但是，只有一个或几个开发人员在同一分支上工作时，只要所有正在处理该特定分支的人都知道重新基础（它可以是计划的事情，或者在每次develop分支更新后都会执行的任务），这是可以接受的。