我有一个问题,从master到我的一个存储库中的'deploy'分支.
我的回购设置如下:
master - of course, the main branch
deploy - a branch created where files like Capfile, deploy.rb etc are created and configured - these changes will NEVER be merged back into Master
通常我的工作流程是:
deploy分支git rebase master在部门分支上执行- 这曾经没有问题cap deploy我现在遇到的问题是,当我git rebase master在部署分支上执行时,它会出现一个3向合并/手动合并所需的错误(我不认为错误消息非常通用,足以发布).Git告诉我执行合并然后git rebase --continue用来完成 - 这从来都不行.
我发现"确实"工作正在运行git rebase master --interactive,清理选择列表(在此列表中有5个左右重复的"提交"但具有不同的引用号(相同的消息),因此我将选择其中一个)然后手动执行合并.一旦我为每次提交完成了这个,那么我可以继续使用rebase并且它很高兴...
直到下次我需要执行rebase.
那么有谁知道什么可能会幸福？该项目并非真正"秘密",所以如果需要,我可以发布消息,日志,分支图等.
谢谢
听起来可能会发生的是，您已经更改了那些“重复”提交的提交历史记录，以便它们具有不同的 sha1。每个 sha1 不仅对于提交是唯一的，而且对于提交历史记录也是唯一的。因此，在同一历史中存在两个相同的 sha1 甚至在两个不同的历史中存在两个 sha1 是不可能的（好吧，在宇宙的生命周期中极不可能发生）。如果您更改提交中的任何内容，例如修改或交互式变基，那么您将更改 sha1。因此，看似相同的两个提交实际上会被不同地对待。
因此，很可能，您从另一个分支重新建立基础，进行某种类型的交互式重新建立基础或修改提交，继续提交更多修改代码同一部分的代码，然后在下一个重新建立基础时，您会发生冲突，因为您的提交本地分支中与您要变基的分支不同的分支将从分支中删除，上游将被拉入，包括您已经拉入并更改了 sha1 的提交，然后当提交重播到分支上时您最终会遇到冲突，因为代码的状态已经与提交的预期发生了变化，因为它最初是根据与您现在分支上的历史记录不同的历史记录创建的。哇，这句话好长啊……
当您“清理”选择列表时...您所做的可能是在变基之前删除这些重复的提交，因此现在您不会重新应用已应用的更改，因此不再有冲突。
但是，如果您只是想解决变基期间的冲突，这可能是最好的选择，这样您就不会意外删除所需的提交。解决冲突将使该提交的更改集不同并适用于您拥有的历史记录。一旦您推送此合并冲突解决方案，您就不会再看到这些问题，除非您修改已再次推送的提交。
要查找哪些文件存在合并冲突，请执行以下操作：
git status
或者
git ls-files -u
一旦您知道哪些文件存在冲突，如果您有 mergetool 设置，您可以执行以下操作：
git mergetool <file>
如果您想手动合并，可以通过执行以下操作找到合并标记和行：
grep -Hnr '^=\{7\}\|^<\{7\}\|^>\{7\}' *
在存储库路径的顶层并进行编辑。当您手动编辑时，请确保删除标记并使文件的最终版本看起来像您想要的那样... git 不会为您对标记执行任何特殊操作。完成手动编辑后，请务必执行以下操作
git add <file>
添加文件以将其添加到索引并删除未合并标志。解决完所有未合并的文件后，执行以下操作
git rebase --continue
完成变基。
| 归档时间： |
|
| 查看次数： |
5361 次 |
| 最近记录： |