从git-merge的手册页中,您可以使用许多合并策略.
resolve - 这只能使用3向合并算法解析两个头(即当前分支和你从中拉出的另一个分支).它试图仔细检测纵横交错的合并模糊,并且通常被认为是安全和快速的.
递归 - 这只能使用3向合并算法解析两个磁头.当有多个可用于3向合并的共同祖先时,它会创建共同祖先的合并树,并将其用作3向合并的参考树.据报道,这可以减少合并冲突,而不会因为从Linux 2.6内核开发历史记录中进行的实际合并提交而导致错误合并.此外,这可以检测和处理涉及重命名的合并.这是拉动或合并一个分支时的默认合并策略.
章鱼 - 这解决了两个以上的案例,但拒绝进行需要手动解决的复杂合并.它主要用于将主题分支头捆绑在一起.这是拉动或合并多个分支时的默认合并策略.
我们的 - 这解决了任意数量的头,但合并的结果始终是当前的分支头.它旨在用于取代侧枝的旧发展历史.
子树 - 这是一个修改后的递归策略.当合并树A和B时,如果B对应于A的子树,则首先调整B以匹配A的树结构,而不是读取相同级别的树.这种调整也是对共同的祖先树进行的.
我什么时候应该指定不同于默认值的东西？哪些场景最适合？
我有一个大型网站,我正在进入一个新的框架,并在此过程中添加git.当前站点没有任何版本控制.
我开始将网站复制到一个新的git存储库.我创建了一个新的分支,并进行了使其与新框架一起工作所需的所有更改.其中一个步骤是更改所有页面的文件扩展名.
现在,在我一直在处理新站点的时候,已经对旧站点上的文件进行了更改.所以我切换到master并复制了所有这些更改.
问题是当我将分支与新框架合并回主服务器时,在主分支上更改的每个文件都存在冲突.
我不会担心它,但有几百个文件有变化.我曾尝试git rebase和git rebase --merge没有运气.
如何在不处理每个文件的情况下合并这两个分支？
我想知道你如何在Git中处理这样的情况:
Git告诉我的是:
CONFLICT (rename/rename): Rename "foo.c"->"bar.c" in branch "HEAD" rename "foo.c"->"moo.c" in "task001"
Automatic merge failed; fix conflicts and then commit the result.
我该怎么解决？我的意思是,一旦名称冲突得到解决,我仍然希望合并这两个文件.
谢谢.
我对一个特定的git行为有一个困惑:
以下是步骤和情况(稍后还会给出命令列表):
mv,git rm,git add.在master中重命名文件a.txt.在提交期间,我做了git rm src/a.txt但忘了做git add src/b.txt
我在做的主人:git rm src/a.txt和git commit
在master中,我将文件b.txt的内容编辑为"New Content
git add src/b.txt和git commitgit merge XBranch文件src/b.txt冲突,这是完全可以理解的.但内容是" Old Content".为什么？
为什么不是这样的:
<<<<<<< HEAD
New Content
=======
Old content
>>>>>>> XBranch
sabya@SABYA-PC d:/merge_temp/test/case2
$ mkdir source
sabya@SABYA-PC d:/merge_temp/test/case2
$ git init
Initialized empty Git repository in d:/merge_temp/test/case2/.git/
sabya@SABYA-PC d:/merge_temp/test/case2 (master)
$ mkdir …我正在尝试与一个分支合并，这是我得到的错误：
BUG: There are unmerged index entries:
BUG: 2 src/assets/svg/arrow-black.svg
BUG: merge-recursive.c:429: unmerged index entries in merge-recursive.c
我真的不知道还有什么要补充的。我一直在搜索，但我在 5 个不同的网站上看到了完全相同的解释，但没有帮助
重新创建分支无济于事