可能重复:
使当前Git分支成为主分支
我的Git存储库中有两个分支:
masterseotweaks(最初创建master)我创建seotweaks的目的是迅速将其合并回来master.然而,那是三个月前,这个分支的代码是13个版本master.
它已经有效地成为我们的工作主分支,因为现在所有的代码master或多或少已经过时了.
我知道非常糟糕的做法,经验教训.
你知道如何master用那些替换分支的所有内容seotweaks吗？
我可以删除所有内容master并合并,但这不是最佳实践.
当使用主题分支"B"合并到"A"时git merge,我会遇到一些冲突.我知道使用"B"中的版本可以解决所有冲突.
我知道git merge -s ours.但我想要的是类似的东西git merge -s theirs.
它为什么不存在？在与现有git命令冲突合并后,如何获得相同的结果？(git checkout来自B的每个未合并文件)
更新:从分支A(合并提交点到树的B版本)丢弃任何东西的"解决方案"不是我想要的.
从git-merge的手册页中,您可以使用许多合并策略.
resolve - 这只能使用3向合并算法解析两个头(即当前分支和你从中拉出的另一个分支).它试图仔细检测纵横交错的合并模糊,并且通常被认为是安全和快速的.
递归 - 这只能使用3向合并算法解析两个磁头.当有多个可用于3向合并的共同祖先时,它会创建共同祖先的合并树,并将其用作3向合并的参考树.据报道,这可以减少合并冲突,而不会因为从Linux 2.6内核开发历史记录中进行的实际合并提交而导致错误合并.此外,这可以检测和处理涉及重命名的合并.这是拉动或合并一个分支时的默认合并策略.
章鱼 - 这解决了两个以上的案例,但拒绝进行需要手动解决的复杂合并.它主要用于将主题分支头捆绑在一起.这是拉动或合并多个分支时的默认合并策略.
我们的 - 这解决了任意数量的头,但合并的结果始终是当前的分支头.它旨在用于取代侧枝的旧发展历史.
子树 - 这是一个修改后的递归策略.当合并树A和B时,如果B对应于A的子树,则首先调整B以匹配A的树结构,而不是读取相同级别的树.这种调整也是对共同的祖先树进行的.
我什么时候应该指定不同于默认值的东西？哪些场景最适合？
有没有解决使用结账所有文件冲突的方式--ours和--theirs？我知道您可以为单个文件执行此操作,但无法找到为所有文件执行此操作的方法.
C---D =>b1
/
/ E---F =>b2
| /
A--B =======> master
| \
\ G---H =>b3
\
I---J =>b4
我想合并b1,b2,b3,b4成master,是有可能合并在一次？
就像是:
git checkout master
git merge b1 b2 b3 b4
我有一个项目,我最初使用子模块的一些相关代码.事实证明,子模块并不适合这个项目(并且它们在实践中很难使用),因此我将每个子模块转换为子树(使用新git-subtree功能).
在我的工作存储库中,我已经成功删除了每个子模块,并将旧的子模块repo添加为子树.没问题.
当我转到另一个克隆并尝试从第一个克隆拉出时,我从合并步骤中收到以下错误:
error: The following untracked working tree files would be overwritten by merge:
sub/.gitignore
sub/Makefile
sub/README
sub/src/main.c
... and so on for all files in sub/
Aborting
看来这是因为sub/首先在主存储库中从未真正存在过文件,并且当Git应用补丁进行更新时,.gitmodules它不会删除带有子模块文件的目录.当处理下一次提交时,Git尝试在其中创建新文件sub/,现在它们是主存储库的一部分,所有这些文件都与仍然存在的文件冲突sub/.
我发现的解决方法是使用rm -rf sub之前git pull,这可以避免这个问题.
我的问题是,是否有任何命令行开关我可以使用git merge"覆盖工作目录中恰好存在的任何文件"？更好的方法是git merge查看现有文件的内容,如果内容与它要创建的文件完全相同,则禁止显示错误消息并继续.
更新:我已经创建了演示此问题的Git存储库,以准确显示我正在谈论的内容.重现:
$ git clone https://github.com/ghewgill/q14224966.git
$ cd q14224966
$ git submodule init
$ git submodule update
$ git merge origin/branch
这应该导致错误消息
error: …