是否安全地压缩来自其他分支的提交

开发流程中feature分公司并有多次提交该分支完成，但它们之间有一些融合了master分支，所以日志功能分支，例如像：

它是安全的壁球这一切都提交到一个feature commit 1？

在将feature分支合并到master时，是否会遇到任何问题？

2017-07-22 marknorkin

你会在什么时候压扁？在合并之前？ –

@TadijaBagarić不，在这次合并之后发生了 – marknorkin

将所有这些提交压缩到一个特性提交1中是否安全？

不，这不是安全的这样做

是否有合并功能分支到主站时，我会遇到什么问题？

据我所知问题是，在那种情况下，你改变主分支的历史，基本上为每个人制动。

当你从你的第一个到最后一个的所有提交的feature分支挤压时，你将压缩所有主提交以及这两个提交，甚至主提交改变了不同的文件，那么你做了。

所以你压扁的提交会有很多改变的文件，你根本没有改变，当合并回主分支，即使这些文件的内容没有改变，但提交哈希被改变，所以在这个回购协议中与你一起工作的人们以后会遇到各种各样的冲突。

2018-01-01 09:57:00 marknorkin

对master分支上的任何文件所做的任何更改都会导致合并冲突（甚至更糟，无用的静默覆盖），因此任何其他人将工作交给master会给您带来问题，从而使协作变得更加困难。

在另一方面，如果你的feature分支历史看起来像，因为您在功能开发过程中需要从master变化，为什么不rebase你feature分支上的master顶部，当你需要更新？

基本上，它会做的就是让你feature看起来就像在合并之前从master分支出来。功能开发过程中

所以，如果你使用合并获得master更新：

但是如果你使用变基获得master更新：

所以，当你想合并你的feature回到master，合并将基本上是一个快速向前合并，将您的功能提交到master分支之上。

当然，在合并更合适的情况下，就像您想保留历史记录一样，但这取决于您和您的工作流程。

一些更多的资源，这将更好地解释合并/变基差：

2017-07-22 08:24:28

当您完成您的特性分支工作，你需要将它合并到主分支。在执行此操作时，如果特性分支和主分支在相同位置包含更改，则可能会遇到合并冲突。由于合并是在本地存储库中进行的，因此它很安全，您可以花时间确保所做的所有更改都是正确的。但是，当你推动你的改变并且他们将会被团队使用时，那么你做的任何错误都会升级。

出于这个目的，在许多情况下建议将主体合并到要素分支中，修复您的要素分支中可能的合并冲突，然后将其合并回主体。我知道这涉及到一个额外的民主步骤，但这是值得的，因为您可以选择在没有任何风险的情况下推动合并，如果有人可以回答您的未解决问题或测试人员尝试解决问题，那么您在一个更安全的情况下。

推动掌握并不总是超级风险。风险级别取决于推送到主服务器和推送代码之间的距离。如果推送给主人的任何内容立即生效，那么这是非常危险的，而如果主人是分期，那么风险就会降低，但是，我认为解决功能分支中的任何可能的合并问题更有礼貌，一切都很好，然后将它合并回主。

如果主控自上次合并到功能后没有更改，则可以将功能分支合并到主控中。

从理论上讲，合并每个单独提交更安全，但前提是这些提交经过良好测试，但实际上没有人会这样做，没有一个非常具体的原因，就像其他人做出的某些更改可能与您不兼容变化。但是，这只有当头部合并因某些原因而失败时才需要，并且您需要确定不兼容性来自何处。

2017-07-22 08:52:35

回答