Git Merge 提交到孤儿分支
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/27641380/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Git Merge commits into an orphan branch
提问by Xtremefaith
I'm curious to know if you CAN and if there is anything wrong with merging commits INTO my orphan branch. For this specific instance my Salesforce repository has a master branch and a pre-release branch but because our sandbox environment often has metadata that is not part of production yet we want to version control it but separate enough from our clean pre-release branch.
我很想知道您是否可以，以及将提交合并到我的孤儿分支是否有任何问题。对于这个特定实例，我的 Salesforce 存储库有一个主分支和一个预发布分支，但因为我们的沙箱环境通常具有不属于生产的元数据，但我们希望对其进行版本控制，但与我们干净的预发布分支足够分离。
So as it is we have the following:
因此，我们有以下内容：
(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)
采纳答案by Matthieu Moy
Merging commits that do not have a common root commit is allowed with Git. The result will contain the union of the files present in both branches. This is a common practice to merge two projects into a single repository (for example, the Git project itself was started at e83c51633, gitk was started at 1db95b00, and both projects were merged later at 5569bf9bb).
Git 允许合并没有共同根提交的提交。结果将包含两个分支中存在的文件的并集。这是将两个项目合并到一个存储库中的常见做法（例如，Git 项目本身在e83c51633开始，gitk 在1db95b00开始，两个项目后来在 5569bf9bb 合并）。
Now, whether you actually want to do that really depends on the content of branches. If you merge your sandbox branch into your feature branch, then merging your feature branch into master will also bring your sandbox code into master, which you probably don't want.
现在，您是否真的想要这样做实际上取决于分支的内容。如果您将沙箱分支合并到您的功能分支，那么将您的功能分支合并到 master 也会将您的沙箱代码带入 master，这可能是您不想要的。
回答by VonC
With git 2.9 (June 2016), merging orphan branches is still possible, but ony with the --allow-unrelated-historiesoption:
使用 git 2.9（2016 年 6 月），合并孤儿分支仍然是可能的，但只有以下--allow-unrelated-histories选项：
git merge --allow-unrelated-histories a b
See commit e379fdf(18 Mar 2016) by Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster--in commit d04aa7e, 08 Apr 2016)
请参阅Junio C Hamano( )提交的 e379fdf(2016 年 3 月 18 日)。（由Junio C Hamano合并-- --在2016 年 4 月 8 日提交 d04aa7e 中）gitstergitster
merge: refuse to create too cool a merge by default
While it makes sense to allow merging unrelated histories of two projects that started independently into one, in the way "
gitk" was merged to "git" itself aka "the coolest merge ever", such a merge is still an unusual event.
Worse, if somebody creates an independent history by starting from a tarball of an established project and sends a pull request to the original project, "git merge" however happily creates such a merge without any sign of something unusual is happening.Teach "
git merge" to refuse to create such a merge by default, unless the user passes a new "--allow-unrelated-histories" option to tell it that the user is aware that two unrelated projects are merged.Because such a "two project merge" is a rare event, a configuration option to always allow such a merge is not added.
合并：默认拒绝创建太酷的合并
虽然允许将两个独立启动的项目的不相关历史合并为一个是有意义的，就像“
gitk”被合并到“git”本身又名“有史以来最酷的合并”一样，这样的合并仍然是一个不寻常的事件。
更糟糕的是，如果有人通过从已建立项目的 tarball 开始创建一个独立的历史记录并向原始项目发送拉取请求，“git merge”然而很高兴地创建了这样的合并，而没有任何异常迹象正在发生。教“
git merge”默认拒绝创建这样的合并，除非用户通过一个新的“--allow-unrelated-histories”选项告诉它用户知道两个不相关的项目被合并。因为这样的“两个项目合并”是罕见的事件，所以没有添加始终允许这种合并的配置选项。
The git mergedocmentions:
该git merge文档提到：
By default,
git mergecommand refuses to merge histories that do not share a common ancestor. This option can be used to override this safety when merging histories of two projects that started their lives independently.
As that is a very rare occasion, no configuration variable to enable this by default exists and will not be added, and the list of options at the top of this documentation does not mention this option.
Alsogit pulldoes not pass this option down togit merge(instead, yougit fetchfirst, examine what you will be merging and thengit mergelocally with this option).
默认情况下，
git mergecommand 拒绝合并不共享共同祖先的历史。当合并两个独立开始的项目的历史时，此选项可用于覆盖此安全性。
由于这是一种非常罕见的情况，默认情况下不存在启用此功能的配置变量，并且不会添加，并且本文档顶部的选项列表未提及此选项。
也git pull不会将此选项传递给git merge（相反，您git fetch首先检查要合并的内容，然后git merge在本地使用此选项）。
See commit de22496(21 Apr 2016) by Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster--in commit 175008d, 29 Apr 2016)
请参阅Junio C Hamano() 的提交 de22496（2016 年 4 月 21 日）。（由Junio C Hamano合并-- --在commit 175008d，2016 年 4 月 29 日）gitstergitster
pull: pass--allow-unrelated-historiesto "git merge"Instead of:
pull: 传递--allow-unrelated-histories给 "git merge"代替：
git fetch something &&
git merge --allow-unrelated-histories FETCH_HEAD
If somebody is inclined to add such an option, updated tests in this change need to be adjusted back to:
如果有人倾向于添加这样的选项，则需要将此更改中的更新测试调整回：
git pull --allow-unrelated-histories something
