我们是一个由5名开发人员组成的小团队。我们刚刚从Subversion迁移到Git，无法为我们找到合适的工作流程。
我们试图在A successful git branching model篇文章之后坚持从一开始到gitflow工作流程，但坦率地说，对于我们工作的小项目来说似乎势不可挡，而且我们中的一些人严格遵守它，因为它与颠覆有很大不同我们习惯的模型。
所以现在我们没有使用发布分支来发布版本，因为它看起来是如此不必要，尽管我们确保我们的主人保持干净。同样，我们不使用功能分支，而是直接在开发上工作。
我不确定发布但我觉得我们应该使用功能分支，只是因为我不知道如何使用它们。在上面提到的文章中，以及我们读过的其他文章中，它建议在将它们合并到开发之前保持本地特征并压缩它们中的提交。如果只有一个开发人员正在使用该功能，那看起来很容易，但我们的情况是任何人都可能希望/需要将项目置于其当前状态并继续处理它。因此，项目易手很多，所有工作都必须推送到服务器，即使它还没有完成，所以任何人都可以拉动并继续工作。
因此，我们所有的远程工作都发现很难保持清洁，我们的历史是一个很小的提交列表，但据我所知，我们不能压缩它们或改变任何分支，因为这会改变公共历史。
我们希望做得对，但并不比必要的复杂。那么任何关于哪种工作流程对我们最好的想法以及我们如何正确实施呢？
答案 0 :(得分：2)
在合并回rebase分支之前，您可以继续处理具有小提交但仅squash和/或develop的功能分支。从那以后，功能分支没有任何相关性，因此搞乱其历史不一定是个问题。
它通过小型提交解决了您没有“污染”历史记录的问题。这种方法的唯一问题是你不经常更新你的功能分支，所以你最终会有更大的合并。
根据我的经验，最好的目标是使用功能切换来实现非常短的生活特征分支。通过这种方式，您可以合并回不完整但未破坏的功能分支，从而消除巨大的合并难题。
拥有真正的提交历史并不错。它有助于评论，并在必要时更容易挑选，并有助于合并。你的主人应该保持干净：每次发布一次。开发可以不那么干净，每个功能/票证分支的提交。但是，您的功能分支可以正确包含历史记录。
此外，如果您确实希望保持提交图更容易理解，那么您可以经常过度开发和推送它。不建议改变公共历史，因为如果不是每个人都意识到这可能会导致问题。但是，如果只有一个，或者只有少数开发人员在同一个分支上工作，只要在该特定分支上工作的每个人都知道rebase（它可以是一个预定的东西，或者你每个人都做的事情）是可以接受的开发分支更新后的时间）