Git Merge承诺进入一个孤儿分支

Question

我很想知道你是否可以,如果将提交合并到我的孤儿分支中是否有任何问题.对于此特定实例,我的Salesforce存储库具有主分支和预发布分支,但由于我们的沙箱环境通常具有不属于生产的元数据,但我们希望对其进行版本控制,但与我们的干净预发布分支分开.

因此,我们有以下内容:

(Production Init Commit)    (official release)
 /                         /
o-------------------------o [master]
 \                       /
  o------o---------o----o [pre-release]
          \       /
           o-----O [feature]
                  \ <-- IS THIS ALLOWED/POSSIBLE/BAD IDEA?
                   \ 
       o------------O [DEV] (orphan branch)
      /
     (Initial commit from our sandbox environment)

Answer 1

使用git 2.9(2016年6月),仍然可以合并孤立分支,但是可以--allow-unrelated-histories选择:

git merge --allow-unrelated-histories a b

请参阅Junio C Hamano()提交的e379fdf(2016年3月18日).^{(由Junio C Hamano合并- -在提交d04aa7e,2016年4月8日)}gitster
gitster

merge:默认情况下拒绝创建太酷的合并

虽然允许合并两个独立开始的项目的无关历史是有意义的,但是" gitk"被合并为" git"本身也称为"有史以来最酷的合并",这种合并仍然是一个不寻常的事件.
更糟糕的是,如果有人通过从已建立的项目的tarball开始创建独立历史并向原始项目发送拉取请求," git merge"然而愉快地创建这样的合并而没有任何异常的迹象正在发生.

git merge默认情况下,教" "拒绝创建这样的合并,除非用户传递新的" --allow-unrelated-histories"选项告诉用户知道两个不相关的项目已合并.

因为这样的"两个项目合并"是一种罕见的事件,所以不会添加始终允许这种合并的配置选项.

该git merge文件提到:

默认情况下,git merge命令拒绝合并不共享共同祖先的历史记录.在合并独立开始生命的两个项目的历史时,此选项可用于覆盖此安全性.
由于这是一个非常罕见的场合,因此默认情况下不存在任何默认启用的配置变量,并且不会添加,本文档顶部的选项列表未提及此选项.
也git pull不会将此选项传递给git merge(相反,git fetch首先,检查您将合并的内容,然后git merge使用此选项进行本地检查).

请参阅Junio C Hamano()提交的de22496(2016年4月21日).^{(由Junio C Hamano合并- -在提交175008d,2016年4月29日)}gitster
gitster

pull:传递--allow-unrelated-histories给" git merge"

代替:

git fetch something &&
git merge --allow-unrelated-histories FETCH_HEAD

如果有人倾向于添加这样的选项,则需要将此更改中的更新测试调整回:

git pull --allow-unrelated-histories something

Answer 2

Git允许合并没有共同root提交的提交.结果将包含两个分支中存在的文件的并集.这是将两个项目合并到一个存储库中的常见做法(例如,Git项目本身在e83c51633处启动,gitk在1db95b00处启动,两个项目稍后在5569bf9bb合并).

现在,你是否真的想要这样做真的取决于分支的内容.如果将沙盒分支合并到功能分支中,则将功能分支合并到主分区也会将沙箱代码转换为主分区,这可能是您不想要的.