有两个分支master和feature。
开发进入feature分支，并且在该分支中完成了多次提交，但是在它们之间有几个与master分支的合并，因此功能分支的日志例如是：
功能提交1
master commit 1
功能提交2
master commit 2
功能提交3
将所有这些提交压缩成一个feature commit 1是否安全？
将feature分支合并到master时，我是否会遇到任何问题？
答案 0 :(得分：0)
对master分支上的任何文件进行任何更改都会导致合并冲突（甚至更糟糕的是，不需要的静默覆盖），因此任何将其工作提交给master的人都会让您在协作方面遇到问题困难的。
另外请注意，如果您的feature分支历史记录看起来像是因为您需要在功能开发期间master进行更改，那么为什么不只是rebase您的feature分支机构当您需要更新时，master的顶部？
基本上，它会让你feature看起来像是在合并之前从master分支出来的。
因此，在功能开发期间，如果您使用合并来获取master更新：
但是，如果您使用 rebase 来获取master更新：
因此，当您想将feature合并回master时，合并将基本上是一个快速合并，将您的功能提交置于master分支之上。
当然，在某些情况下，合并更合适，例如，如果您想保留历史记录，那么这取决于您和您的工作流程。
更多可以更好地解释合并/转换差异的资源：
答案 1 :(得分：0)
完成功能分支后，您需要将其合并到主分支。执行此操作时，如果要素和主分支在相同位置包含更改，则可能会遇到合并冲突。由于合并发生在您的本地存储库中，因此它是安全的，您可以花时间确保您所做的所有更改都是正确的。但是，当您推送更改并且团队可以使用这些更改时，您所做的任何错误都可能会升级。
出于这个目的，在许多情况下建议将master合并到功能分支，修复功能分支中可能的合并冲突，然后将其合并回master。我知道这涉及到一个额外的民族化步骤，但它是值得的，因为你可以选择推动你的合并没有任何风险，如果有人可以回答你的开放问题或测试人员试图解决问题，你是在一个更安全的情况下。
推动掌握并不总是超级冒险。风险等级取决于推送到主控和获取推送代码之间的步距。如果任何推送到主人的东西立即生效，那么它是非常危险的，而如果主人是一个升级，那么风险会降低，但是，我认为解决你的功能分支中任何可能的合并问题更为礼貌，当一切都好，然后把它合并回主人。
如果master上次没有更改，因为它最后一次合并到功能中，那么你可以将你的功能分支合并到master中。
理论上，单独合并每个提交更安全，但只有在这些提交经过充分测试的情况下，但实际上没有人会这样做，没有非常具体的原因，比如其他人做的一些可能与您的更改不兼容的更改。但只有当磁头的合并由于某些原因而失败并且您需要确定不兼容性来自何处时才需要这样做。
答案 2 :(得分：0)
将所有这些提交压缩到一个功能提交1中是否安全？
不，这样做不安全
合并功能时是否会遇到任何问题 分成主人？
正如我所理解的那样，在这种情况下，您正在更改主分支历史记录，并基本上为每个人打破它。
当您将feature分支从第一个提交到最后一个提交时，除了您的两个功能提交之外，您还将压缩所有主提交 - 甚至master提交更改了你没有碰过的文件。
因此，您压缩的提交将包含许多您根本没有更改的文件。合并回主分支时，即使这些文件的内容没有改变，提交哈希也会发生变化，因此在此仓库中与您合作的人将在以后发生各种冲突。