有两个分支master和feature。
开发在feature分支中进行，并且在该分支中完成了多个提交，但在它们之间有几个与master分支的合并，因此功能分支的日志例如是这样的：
功能提交 1
主提交 1
功能提交 2
主提交 2
功能提交 3
将所有这些提交压缩成一个是否安全feature commit 1？
feature合并分支时有什么问题master吗？
问问题
1267 次
3 回答
1
将所有这些提交压缩成一个功能提交 1 是否安全？
不，这样做不安全
将功能分支合并到 master 时是否会遇到任何问题？
据我了解这个问题，在这种情况下，您正在更改主分支历史并基本上为每个人打破它。
当您feature为从第一个到最后一个提交的提交压缩分支时，除了您的两个功能提交之外，您还将压缩所有主提交 - 甚至master是更改了您未触及的文件的提交。
因此，您的压缩提交将包含许多您根本没有更改的已更改文件。当合并回 master 分支时，即使这些文件的内容没有改变，但提交哈希已经改变，所以在这个 repo 中和你一起工作的人以后会有各种各样的冲突。
于 2018-01-01T09:57:00.313 回答
0
对分支上任何文件的任何更改master都会导致合并冲突（或者更糟糕的是，不需要的静默覆盖），因此任何其他人提交他们的工作master都会给您带来问题，使协作更加困难。
另一方面，如果您的feature分支历史看起来像这样，因为您需要master在功能开发期间进行更改，为什么不在需要更新时重新调整您的feature分支master？
基本上，它会做的是让你feature看起来像是从master合并之前分支出来的。
所以在功能开发过程中，如果你使用merge来获取master更新：
- 功能提交 1
- 主提交 1
- 功能提交 2
- 主提交 2
- 功能提交 3
但是如果你使用rebase来获取master更新：
- 主提交 1
- 主提交 2
- 功能提交 1
- 功能提交 2
- 功能提交 3
因此，当您想将featureback 合并到master时，合并基本上是一个快进合并，将您的功能提交放在master分支之上。
当然，在某些情况下合并更合适，例如如果您想保留历史记录，但这取决于您和您的工作流程。
更多资源可以更好地解释合并/变基差异：
于 2017-07-22T08:24:28.630 回答
0
完成功能分支的工作后，您需要将其合并到主分支。执行此操作时，如果功能分支和主分支在相同位置包含更改，您可能会遇到合并冲突。由于合并发生在您的本地存储库上，因此它是安全的，您可以花时间确保所做的所有更改都是正确的。但是，当您推送您的更改并且它们将可供团队使用时，您所做的任何错误都可能升级。
出于这个目的，在许多情况下建议将 master 合并到特性分支中，修复特性分支中可能存在的合并冲突，然后将其合并回 master。我知道这涉及一个额外的官僚主义步骤，但这是值得的，因为您可以选择在没有任何风险的情况下推动合并，并且如果有人可以回答您的未解决问题或测试人员来尝试，您是在更安全的情况下。
推动掌握并不总是超级冒险。风险级别取决于推送到 master 和获取推送代码之间的步骤距离。如果推送到 master 的任何东西立即生效，那么风险很大，而如果 master 是一个 staging，那么风险就会降低，但是，我认为在你的特性分支中解决任何可能的合并问题会更有礼貌，当一切正常，然后将其合并回master。
如果 master 自上次合并到 feature 后没有任何变化，那么您可以将您的 feature 分支合并到 master 中。
从理论上讲，单独合并每个提交更安全，但前提是这些提交经过良好测试，但实际上没有人会这样做，没有非常具体的原因，例如其他人所做的某些更改可能与您的更改不兼容。但这仅在头部合并由于某些原因失败并且您需要确定不兼容的来源时才需要。
于 2017-07-22T08:52:35.853 回答