17

我很想知道您是否可以以及将提交合并到我的孤立分支中是否有任何问题。对于这个特定的实例，我的 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)
4

2 回答 2

28

使用 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

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

虽然允许将两个独立启动的项目的不相关历史合并为一个是有意义的，但就像“ gitk”被合并到“ git”本身也就是“有史以来最酷的合并”一样，这样的合并仍然是一个不寻常的事件。
更糟糕的是，如果有人通过从已建立项目的 tarball 开始创建独立历史并向原始项目发送拉取请求，“ git merge”但是很高兴创建这样的合并，而没有任何异常发生的迹象。

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

因为这样的“两个项目合并”是罕见的事件，所以没有添加始终允许这样的合并的配置选项。

该git merge文档提到：

默认情况下，git mergecommand 拒绝合并不具有共同祖先的历史。当合并两个独立开始的项目的历史时，此选项可用于覆盖此安全性。
由于这是非常罕见的情况，默认情况下不存在启用此功能的配置变量并且不会添加，并且本文档顶部的选项列表未提及此选项。
也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
于 2016-04-10T10:22:13.223 回答
12

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

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

于 2015-04-24T20:57:08.057 回答