只要任何推送工作中的最终提交都可以，那么中断中间的提交就可以了吗？

相关： 每个git commit都应该使项目处于工作状态吗？

假设我在本地进行了以下提交：

• 修改数据库架构，破坏应用程序。

• 更新应用程序，使其再次与数据库架构兼容。

只要我同时推送两个提交，master便会保持工作状态。但是，历史版本已损坏。

我知道我可以git rebase -i用来将提交压缩在一起。但是，生成的提交将很大且描述性较低。如果我需要搜索提交历史记录以找出更改原因的原因，我宁愿找到显示我所做的事情和原因的原始提交。

我的问题是：

• 有没有人遇到困难，由于打破历史的主人提交？

• 如果是这样，是否有一种简单的方法可以避免这些困难，而又不丢弃各个提交消息和更改？

在很大程度上取决于服装的分支策略，但是我认为对开发分支的破坏提交通常具有很多意义-使用源代码管理的真正“大赢家”是能够回滚小改动，有时您会做成一堆，你就得把鸡蛋弄碎做蛋卷。

保持单个提交而不污染主服务器的简单方法是使用分支。您可以在其中放置一些突破性的/实验性的东西，这样您就可以获得细粒度的历史记录，而不会污染主分支的历史记录。

断断续续的提交只是“发生”，并不意味着世界末日。我的脑后确实有一点na的声音，告诉我，从原则上讲，不应该有意识地签入破损的代码，因此，包括历史版本在内，但这不是我要争论的问题。

Git广受赞誉的分支模型使将特定分支的提交拒之门外变得可行，例如，如果您的团队采用gitflow或其简化版本。任何带有“干净主人”政策的东西。在这种情况下，您可以将最终的工作版本作为合并提交检入，其中（损坏的）历史版本在存储库中可用，但不涉及主线。

如果您的团队没有采用这样的分支模型，那么您就有正当的理由将全部工作推向高手并完成工作。

不，这不好。

如果您曾经做过git bisect（并且谁不喜欢那个杀手级功能），您就会知道每次提交建立的历史的价值。

如果在bisect未构建期间有很多提交git bisect skip，则将有很多，这使得很难找到最后一个好的提交。

如果您完成了一个功能分支并将其合并到母版中，请在合并之前清理该分支，以便清除历史记录并进行构建。

有没有人因师父的过往经历而遇到困难？

是。反向移植，还原和二等分比较困难。阅读历史记录也是如此（请参阅下文）。

如果是这样，是否有一种简单的方法可以避免这些困难，而又不丢弃各个提交消息和更改？

我不知道，尽管分支机构是一个不错的解决方案。

但是，我认为丢弃（或压扁）个人提交的内容是正确的做法。

在开发期间，尤其是在进行TDD时，尽早并经常提交是一件好事。您想要完整地了解自己在做什么，以便可以回溯，或者准确地确定何时开始出现问题（或者您可能陷入了无法咀嚼的重构之中）。放手

但是，一旦准备好要推送功能/更改，则提交是打包的更改-理想情况下是原子更改，因此可以[独立于其他更改]而被[查看，重新设置，合并，挑选，还原，以注释方式查看] 。

查看项目的历史记录，应自行评估软件更改。它会建立吗？有测试吗？它行得通吗？它有什么作用？提供该功能需要更改哪些文件？

在可能的情况下（必须借助合并）必须组装提交，这使此过程变得更加困难。因此，我认为在推送之前清理您的历史记录是适当的，即使这意味着失去对到达目的地的跟踪方式。

简短答案：是

测试：

测试驱动的开发意味着您编写的测试会失败（即显示失败）。
然后，编写代码以使测试正常工作。

发展：

承诺小，经常承诺。
每个提交都是一个回滚点。如果您发现自己走错了路，则可以相对轻松地回滚到上一个点。如果您提交的文件足够细，则可以回滚到正确的位置。

警告：

这确实不是意味着

1）您将损坏的代码签入master。
2）您需要推送所有微提交供所有人审核。

使用分支来完成您的工作。可能会压缩审阅过程的微提交，因此它们在逻辑上是不同的单元，带有适当的注释。如果您使用的是git，则不会丢失原始的提交集，而只需为将合并到master的审阅过程创建新的，更具逻辑性的提交集即可。

我认为，只要提交是本地的，而不是提交给其他人，那不仅可以，而且实际上是一种很好的工作方式。只是不要将残破的代码推送给其他人。