我有一些意想不到的结果，这些结果似乎是基于在执行章鱼合并时给予 git merge 的分支顺序。
以下脚本将复制我的情况
#!/usr/bin/env bash
rm -rf TEMP
# create area to work in
mkdir TEMP
cd TEMP/
git init
# work on master
echo "hello world" > file
git add file
git commit -m "initial commit"
# create branch which is at the same point as master
git branch hasnt_moved
# create another branch 1 commit ahead
git checkout -b feature_branch_with_work
echo "some interesting work" > other_file
git add other_file
git commit -m "work on feature branch"
git checkout master
# always should also have some work ahead of master
git checkout -b always
echo "some work on always" > other_other_file
git add other_other_file
git commit -m "work on always branch"
# back to master
git checkout master
# now try a merge
#git merge --no-edit --strategy=octopus always hasnt_moved feature_branch_with_work
# however if I had ran this then it would be merged in
#git merge --no-edit --strategy=octopus hasnt_moved always feature_branch_with_work
# I would also expect this to give the same resutls
#git merge --no-edit --strategy=octopus always feature_branch_with_work hasnt_moved
这是运行上述脚本后我的 git 树的状态
您可以在末尾看到 3 条注释掉的行，下面是每一行以及在树上运行该命令产生的图形（通过 生成gitk --all，运行每个命令后，您可以通过 '返回' 开始git reset --hard hasnt_moved）
以下2种情况符合预期（注意分支参数的顺序）
git merge --no-edit --strategy=octopus hasnt_moved always feature_branch_with_work
git merge --no-edit --strategy=octopus always feature_branch_with_work hasnt_moved
最后一种情况会产生意想不到的结果，因为 always 分支不包含在最终合并的 master 分支中（注意分支参数的顺序）。
git merge --no-edit --strategy=octopus always hasnt_moved feature_branch_with_work
如果我一一运行合并，我会得到预期的结果：
git merge --no-edit --strategy=octopus always
git merge --no-edit --strategy=octopus hastn_moved
git merge --no-edit --strategy=octopus feature_branch_with_work
我想知道为什么给予章鱼合并的提交的顺序有时会导致always分支不合并到主控中。