因此，我的一位同事尝试使用 GitHub 的 Web 界面中的“通过快进合并”选项来合并分支，以保持历史记录免受虚假合并提交的影响（master自要合并的功能分支启动以来，它们合并到的分支尚未取得进展）。
有趣的是，这并没有按预期工作：所有提交都有新的提交哈希值。
仔细观察，似乎合并选项实际上被称为“Rebase and Merge”，它的作用似乎相当于git rebase --force，改变提交者信息（进行合并的人员以及合并发生的时间）。
我花了很长时间才确认我的怀疑确实如此，因为我无法使用命令行工具来向我展示功能分支上的原始提交和看似相同的提交（具有不同的哈希值）之间的区别在主分支上。
（最后我发现gitk显示提交的提交者和作者；在里面very我发现我还可以通过以下方式获取此信息git log --pretty=raw)
So:
- 有没有办法进行“正确的”快进合并（
git rebase without--force 选项）通过 GitHub 的网络界面？
- 如果不是：为什么？ （我可以看到问责制的优点；例如，它回答了谁对一段给定的代码最终负责的问题
master)
看起来 GitHub 不支持这一点——这是一件可怕的事情。
您基本上无法使用 GitHub UI 运行原子、线性提交策略（最好的策略）。
请注意，Bitbucket 确实支持这一点，并且具有更细粒度的选项来设置 PR 登陆/集成策略。即“变基，快进”选项执行以下操作：--ff-only目标/主线分支的更新。它还有一个'变基，合并'该选项允许您在目标上运行变基（以便您的提交是线性的），但使用合并提交进行集成（如果您想跟踪提交都是一个逻辑单元/PR 的一部分）。
这两个选项似乎都优于 GitHub 的有限选项，即使用非线性合并提交（GitHub 的“合并拉取请求”选项）或线性变基（“变基并合并”选项），它确实实现了线性，但在源分支上创建了重复提交，因此如果您想保持干净和同步，则始终需要在本地进行手动硬重置。
所以...看来是时候切换你的回购提供商了！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
