首页 文章

git merge:即使没有合并冲突,有一种方法可以对涉及的文件进行操作吗?

提问于
浏览
2

当且仅当两个分支在合并之前修改了同一行时,才会发生合并冲突 . 但是,即使没有发生合并冲突,也可能是两个完美工作分支合并的结果不起作用 . 有一种方法可以预先合并两个分支,处理应该由合并产生的文件(也可以添加/删除/修改其他分支),然后提交合并结果?我已经尝试过,但只有当合并冲突发生时才会出现这种可能性,并且仅在涉及的代码行上 . 我确信可以在git中完成(我不能成为唯一有这个问题的人),但我不知道要启动的命令序列 .

3 回答

  • 4
    git merge --no-commit <branchName>
    

    是为了这个目的(见doc) .

    (之后您不需要执行 git merge --continue ,只需在当前状态满足您的需求时提交您的工作 . 不要忘记 add 您在非提交合并后可能已经引入的任何修改)

  • 2

    (这应该是一个注释,但它有点长,需要一些格式化 . )

    我写这篇文章的时候有两个答案:

    • git merge --no-commit ,根据需要调整结果(和 git add ),并使用 git commitgit merge --continue 进行提交;要么

    • git merge ,测试并修复(并根据需要使用 git add ),并使用 git commit --amend 将旧的合并提交移开,将其替换为新的改进提交 .

    两者都有效 . 但请注意,有一种思想流派认为你不应该做其中任何一种,因为将来不可能使用自动化系统来重复合并 . 我不清楚订阅这条规则的人选择哪个选项,因为有两个选项:

    • 在合并之前,进行一次提交(或多次提交)以准备所有内容,以便自动合并成功并生成有效结果 .

    • 或者,在成功但产生无效结果的自动合并之后,进行后续提交以修复它 .

    在任何一种情况下,任何"prepare"或"fix"提交,以及任何不能自行工作的提交,都应该有一个解释性的日志消息 . 如果's the merge itself that doesn'工作,请注意在合并提交的日志消息中:用以下内容替换相当无意义的 merge branch <name> 消息:

    automatic but broken merge of branch <name>
    
    This merge has the contents that Git produces on its own,
    and exists so that someone who is repeating the work in the
    future can do it automatically as well, and compare.  The
    *next* commit contains the manual change that makes the
    merge functional, so when bisecting, use the *next* commit,
    not this one.
    

    当然,如果您更喜欢说"don't make broken commits on purpose"的思想流派,那么您只需合并并修复(使用 --no-commit--amend ,无论您喜欢哪种方式) .

  • 1

    您也可以先进行合并,然后测试它,修复问题,最后在推送之前修复合并提交.9129_ .

相关问题