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 (gitster)commit e379fdf（2016 年 3 月 18 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit d04aa7e，2016 年 4 月 8 日）}

合并：默认拒绝创建太酷的合并

虽然允许合并两个不相关的历史记录是有意义的 以"gitk" was merged to "git" itself aka "the coolest merge ever" 的方式独立启动的项目，这样的合并是 仍然是一个不寻常的事件。
更糟糕的是，如果有人通过从已建立项目的 tarball 开始创建独立历史并向原始项目发送拉取请求，“git merge”却很高兴地创建了这样的合并，而没有任何异常情况发生的迹象。

教“git merge”默认拒绝创建这样的合并， 除非用户将新的“--allow-unrelated-histories”选项传递给 告诉它用户知道两个不相关的项目是 合并。

因为这样的“两个项目合并”是罕见的事件，一个配置 未添加始终允许此类合并的选项。

git merge doc 提到：

默认情况下，git merge 命令拒绝合并不共享共同祖先的历史。当合并两个独立开始的项目的历史时，此选项可用于覆盖此安全性。
由于这是一种非常罕见的情况，默认情况下不存在启用此功能的配置变量并且不会添加，并且本文档顶部的选项列表未提及此选项。
此外，git pull 不会将此选项传递给 git merge（相反，您首先 git fetch 检查将要合并的内容，然后使用此选项在本地检查 git merge）。

---

参见Junio C Hamano (gitster)commit de22496（2016 年 4 月 21 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 175008d，2016 年 4 月 29 日）}

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 允许合并没有公共根提交的提交。结果将包含两个分支中存在的文件的联合。这是将两个项目合并到一个存储库中的常见做法（例如，Git 项目本身在 e83c51633 启动，gitk 在 1db95b00 启动，两个项目后来在 5569bf9bb 合并）。

现在，您是否真的要这样做取决于分支的内容。如果您将沙箱分支合并到功能分支中，那么将功能分支合并到主分支也会将您的沙箱代码带入主分支，这可能是您不想要的。