假设您在处理功能分支时从远程存储库中提取数据，并将新提交添加到主分支中。
您完成功能分支上的工作，提交更改，然后将其合并/变基到主分支。功能提交插入到 master 分支的哪个位置，是在拉取的提交之前还是之后？如果您从未执行过拉动操作，它们会插入哪里？会得到同样的结果吗？
另外，如果将 master 合并/变基到功能分支而不是相反，会发生什么？如果您在拉取之前或之后合并/变基，master 会插入到功能分支的哪里？会得到同样的结果吗？它的历史看起来与前面提到的将功能合并/变基到主版本中会有什么不同吗？
更简洁地说，合并的方向和/或合并的顺序是否会对合并结果产生不同的结果？我怀疑这并不重要。
旁白：对于使用 Git 的人来说，这个问题可能很容易回答，但是有数百甚至数千的文档和教程资源，我从未见过它被直接解决。如果不知道答案，Git 可能会非常难以理解。
因为操作顺序在某些 Git 概念和一般编程中很重要，所以它可能会导致某人得出这样的结论：它会产生影响。此外，我们通常倾向于认为修订是按时间顺序发生的，并期望 Git 也以同样的方式工作。用户界面和命令行也通过暗示操作顺序来体现这种看法。
其他版本跟踪工具在抽象这种认知腐蚀性操作方面做得更好。
因此，我正在制作一个脚本，从主远程存储库获取最新标签，并将其与我的自定义更改合并到我的本地存储库中，在单个脚本中大约有 10-20 个存储库。合并部分看起来像这样：
git fetch -q https://android.googlesource.com/platform/$REPO_PATH $TAG
git merge -q --no-ff FETCH_HEAD
if [ $? -eq 0 ]; then
echo -e "$REPO_PATH merged succesfully"
else
echo -e "\n$REPO_PATH has merge conflict(s)\n"
fi
重点是我想知道哪些提交已成功合并（并且需要推送到我的自定义 git）。但有时存储库已经是最新的（即远程存储库中的新标签没有任何新提交），在这种情况下，即使没有真正合并任何内容，也会显示“合并成功”消息。
我只想知道哪些所有存储库都经过了合并并且需要推送到我的 git，并且还想知道哪些存储库存在合并冲突（不过这在我的脚本中工作得很好）。我所注意到的是，当 git 进行真正的合并时，它会打开 nano 询问提交消息。但我不知道如何使用它来检测合并。提前致谢。
我当前在Heroku上运行一项服务。
Heroku 的部署方式是将代码推送到 git 存储库，这会触发构建并随后触发新代码的部署。
由于这是将服务部署到 Heroku 的唯一方法，因此该 git 存储库包含大量敏感信息，例如一些配置文件中的令牌和客户端机密。因此，该存储库目前是一个私有存储库，但我想将其变成公共存储库。
通常我只是 .gitignore 配置文件并完全排除它们，但由于提交文件是将它们发送到 Heroku 的唯一方法，所以我不能这样做。
我想我可以通过创建两个分支来解决这个问题，我只需将它们推送到不同的遥控器，其中一个是前往 Heroku 的私有分支，另一个是 GitHub 上的公共分支。
在开发过程中，我会推送到私有分支，然后将这些更改（减去配置）合并到公共分支，一切都会好起来的。不幸的是，这样做会导致合并包含来自私有分支的所有历史记录，其中将包含敏感数据，因此这是不行的。
是否可以通过其他方式做到这一点？
我也愿意接受替代解决方案。
这些情况通常如何解决？
我觉得这并不是一个独特的情况。
我从开发中分支出一个功能。我在该功能分支上做了几次提交。然后，我将该功能分支合并回开发中，并将所有内容推到原点。
我只是注意到 git 做了一个我并不真正想要的快进。是否可以恢复该合并？在 git log 中没有合并的提交（当我这样做时也没有要求我发表评论）。
如果重要的话，自从我推动合并以来，一切都没有改变。
我最近在 git merge 方面遇到了很多麻烦。我发现，如果它是一个只有很少更改的小分支，那么一切都会按预期工作，但是每当我合并一个已触及文件分配并提交数天/数周的分支时，我发现运行“git mergebranch”时所有的提交没有被应用，所以我必须回顾并确定哪些提交没有被应用并挑选它们。这似乎是错误的，但我不太确定我的工作流程出了什么问题，使得我不得不这样做。
如何确保合并时“应用”指定分支中的所有更改？
任何帮助，将不胜感激！
编辑 -
对于那些想知道 git rebase 本质上是我正在寻找的东西的人来说。这并不是说我的更改被覆盖，也不是其他人所说的任何内容，我的分支远远落后于 master，而且可能是我使用 rebase -interactive 来压缩提交，我认为 git 在某种意义上失去了对已更改内容的引用。在我的分支上进行 Git rebase，检查 master 然后将我的分支合并到 master 修复了所有更改未通过合并的问题。
2020 年 12 月更新 -
我已经更新了我的合并流程，专门使用在线 github gui 并创建拉取请求，这完全解决了我曾经遇到的所有合并问题。
我正在尝试将一个分支重新设置为一个完全不同的分支。这是一个 React 项目。如果我粗暴地合并两个分支，我什至无法编译代码。因此，我尝试以交互方式变基。
在这样做的同时，我想确保在每个变基步骤之后代码库都可以编译。node_modules每次之后自动重新安装并重新运行项目（假设我用来yarn start运行项目）的方法是什么git rebase --continue？
或者，如果我不在理想的路线上，合并这两个分支的正确方法是什么？
我在 dev 分支中创建了一个 git 标签。但是如果我将它从 dev 合并到主分支，git 标签是否也会自动添加到主分支中？
换句话说，快进合并是否保证产生与要合并的源分支的 HEAD 相同的 GIT SHA？
我在终端中测试了此行为，它适用于我的测试场景：
$ git rev-parse some-branch
0fc9fba2fb1c8a13556da4a333351bc12909c497
$ git merge some-branch --ff-only
Updating 90c6244..0fc9fba
Fast-forward
b | 0
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b
$ git rev-parse HEAD
0fc9fba2fb1c8a13556da4a333351bc12909c497
我可以在我的工具中利用这个条件，例如，我使用源 GIT SHA 标记构建工件。如果快进保证 SHA 不会发生变化，我就不必进行一些可能成本高昂的重建检查。问题是我必须确定这是真的。
我正处于混乱、冲突的 git 合并操作之中。由于某种原因，我忘记了当前正在合并哪些分支或提交。如何查看启动当前合并操作的提交列表？
我在一家公司工作，我们决定要更正确地使用 git。我负责将开发分支集成到主分支中，我对如何在不同场景下正确合并感到困惑。
我们现在的工作方式：开发人员只需在dev分支上重新调整他们的功能分支即可。完成后，他们将向dev分支提交合并请求。然后，我会检查代码（我们是一个小团队），并接受合并请求。之后他们只需删除功能分支即可。当dev分支经过正确测试后，我会在 GitLab 中创建一个到主分支的合并请求，将其分配给我自己并批准它。这会在main分支上创建一个提交：
将分支“dev”合并到“main”
然而，现在该dev分支落后了一次提交main。我该如何最好地解决这个问题？到目前为止，我只是简单地再次合并main，dev但这看起来很麻烦而且奇怪，因为它们现在是我dev分支中的另一个提交；
将分支“main”合并到“dev”
我也可以在 main 上对 dev 进行 rebase，但我了解到“你永远不能对公共分支进行 rebase”
这个问题告诉我正确的方法是首先将 main 合并到 dev 中，以确保 main 分支保持干净。这是实现合并的最佳方式吗dev --> main？
这是否受到 git fast-forwards 默认合并这一概念的影响？我读到，当从当前分支尖端到目标分支存在线性路径时，就会发生快进合并。这意味着，当合并时dev分支只是在x提交 to之前main，并且同时没有对 main 进行提交（这在我们的工作中很常见，因为我们技术上只提交 from main）dev，合并将自动进行快进合并？这种行为对于合并dev到来说是否有问题main，-no-ff合并时是否应该使用该标志？
如果我理解正确，则快进合并会将提交集成dev到分支中main，而--no-ff合并会导致合并始终创建一个新的提交对象，即使可以通过 …