Git 挤压来自其他分支的提交是否安全
有两个分支Git 挤压来自其他分支的提交是否安全,git,merge,rebase,squash,git-squash,Git,Merge,Rebase,Squash,Git Squash,有两个分支master和feature 开发进入feature分支，在该分支中完成了多个提交，但在它们之间有几个与master分支的合并，因此feature分支的日志例如如下： 功能提交1 主提交1 功能提交2 主提交2 功能提交3 将所有这些提交压缩为一个功能提交1是否安全 在将功能分支合并到主功能时，我是否会遇到任何问题 对master分支上任何文件的任何更改都会导致合并冲突（甚至更糟的是，不必要的静默重写），因此任何其他将其工作提交给master的人都会给您带来问题，使协作更加困难
masterfeaturefeaturemaster- 功能提交1
- 主提交1
- 功能提交2
- 主提交2
- 功能提交3
在将
功能主功能mastermaster另一方面，如果您的
功能主功能主功能分支
基本上，它将使您的功能
看起来像是在合并之前从主功能
分支出来的
因此，在功能开发过程中，如果使用合并获取主控
更新：
- 功能提交1
- 主提交1
- 功能提交2
- 主提交2
- 功能提交3
但是，如果您使用重设基础来获取主文件
更新：
- 主提交1
- 主提交2
- 功能提交1
- 功能提交2
- 功能提交3
因此，当您想将功能
合并回主功能
时，合并基本上是一种快速的合并，将您的功能提交到主功能
分支之上
当然，在某些情况下，合并更合适，例如如果您想保留历史记录，但这取决于您和您的工作流程
更多资源可以更好地解释合并/重定基础差异：
完成要素分支的工作后，需要将其合并到主分支。执行此操作时，如果要素分支和主分支在同一位置包含更改，则可能会遇到合并冲突。由于合并发生在本地存储库上，因此是安全的，您可以花时间确保所做的所有更改都是正确的。但是，当您推动您的更改并且这些更改将提供给团队时，您所做的任何错误都可能升级
为此，在许多情况下，建议将主功能合并到功能分支中，修复功能分支中可能的合并冲突，然后将其合并回主功能。我知道这涉及到一个额外的美丽步骤，但它是值得的，因为你可以选择在没有任何风险的情况下推动合并，如果有人可以回答你的开放性问题，或者有测试人员来尝试，你的处境会更安全
向大师挑战并不总是非常危险的。风险级别取决于推送到主代码和使推送的代码生效之间的步距。如果任何推送到master的东西立即生效，那么它是非常危险的，而如果master是一个staging，那么风险就会降低，但是，我认为更礼貌的做法是解决特性分支中任何可能的合并问题，当一切正常时，再将其合并回master
如果主控形状自上次合并到要素后未发生任何更改，则可以将要素分支合并到主控形状
从理论上讲，单独合并每个提交更安全，但只有在这些提交经过良好测试的情况下，但在实践中，没有人会在没有特定原因的情况下这样做，就像其他人所做的某些更改可能与您的更改不兼容一样。但是，只有当由于某些原因导致头部合并失败，并且需要确定不兼容的原因时，才需要这样做
将所有这些提交压缩为一个功能提交1安全吗
不，这样做不安全
在合并功能时，我是否会遇到任何问题
分支成主子
据我所知，在这种情况下，您正在更改主分支历史，并基本上为每个人打破它
当您挤压从第一个提交到最后一个提交的功能
分支时，除了两个功能提交之外，您还将挤压所有主提交-即使是主
提交您未接触的更改文件
因此，您的压缩提交将有许多您根本没有更改的更改文件。当合并回主分支时，即使这些文件的内容没有更改，提交散列也已更改，因此在此repo中与您一起工作的人员稍后将发生各种冲突。您将在什么时候挤压？就在合并之前？@TadijaBagarić不，在合并发生之后