我们是一个由 5 名开发人员组成的小团队。我们刚刚从 Subversion 迁移到 Git，但很难找到适合我们的工作流程。
我们尝试从一开始就坚持使用 A successful git branching model 之后的 gitflow 工作流程文章，但坦率地说，对于我们从事的小项目来说，它似乎势不可挡，我们中的一些人很难严格遵守它，因为它与我们习惯的颠覆模型完全不同。
所以现在我们没有使用发布分支来发布，因为它看起来没有必要，尽管我们确实保持我们的 master 干净。同样，我们不使用功能分支，而是直接在开发上工作。
我不确定发布，但我觉得我们应该使用功能分支，只是我不知道如何使用它们。在提到的文章以及我们读过的其他文章中，它建议将功能保留在本地并在将它们 merge 回开发之前压缩其中的提交。如果只有一个开发人员在该功能上工作，这看起来很容易，但我们的场景是任何人在任何时候都可能想要/需要接受项目的当前状态并继续致力于它。因此项目经常易手，所有工作都必须推送到服务器，即使还没有完成，这样任何人都可以 pull 它并继续工作。
因此，由于我们所有的工作都是远程进行的，因此我们发现很难保持整洁，我们的历史是一个长长的小提交列表，但据我所知，我们不能压缩它们或 rebase 任何分支，因为那会改变公共(public)历史。
我们想把它做对，但不要比必要的更复杂。那么关于哪种工作流最适合我们以及我们如何正确实现它的想法呢？
最佳答案
您可以继续处理具有小提交的功能分支，并且在 merge 回 develop 分支之前只对它们进行rebase 和/或squash。从这一点来看，功能分支没有任何相关性，所以搞乱它的历史不一定是个问题。
- 创建功能分支
- 做工作，在功能分支上提交推送
- 其他开发人员可以接管它并做更多的工作
- 准备就绪后，对开发进行 rebase ，压缩小的提交并将其 merge 回去
它解决了不通过小提交“污染”历史的问题。这种方法的唯一问题是您不会经常更新您的功能分支，因此您最终会进行更大的 merge 。
根据我的经验，最好的方法是通过使用功能切换来瞄准非常短暂的功能分支。通过这种方式，您可以 merge 回不完整但未损坏的功能分支，从而消除巨大的 merge 难题。
拥有真实的提交历史也不错。它有助于审查，并在必要时更容易挑选，也有助于 merge 。你的主人应该保持干净:每次发布一次提交。开发可能不太干净，每个功能/票证分支都有一个提交。但是，您的功能分支可以正确包含历史记录。
此外，如果您确实想让提交图更容易遵循，您可以经常在开发和推送它时进行 rebase 。不建议更改公共(public)历史记录，因为如果不是每个人都知道这可能会导致问题。但是，如果一次只有一个，或者只有几个开发人员在同一个分支上工作，这是可以接受的，只要在该特定分支上工作的每个人都知道 rebase(它可以是计划好的事情，或者你每次都做的事情开发分支更新后的时间)
关于git - 对于所有开发人员都在所有项目上工作的小型团队来说，哪个 git 流程最好？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25681521/