【发布时间】：2018-10-06 16:39:19
【问题描述】：
背景： 我们是一个程序员团队，他们从事具有多个分支的项目 ：
Master, Release, Develop
有时我们需要在发布时修复错误，我们需要在开发时报告此修复，以报告我们使用的错误修复：git cherry-pick commit-SHA
使用此命令，错误修复在开发中得到了很好的报告，但提交具有不同的哈希
我们需要什么：
有时我们需要知道尚未报告的提交列表，为此，我们使用比较两个分支的命令，并为我们提供发布中存在但开发中不存在的提交列表：git log develop..origin/release
问题：
此命令比较提交的哈希值，但正如我之前所说，当我们报告我们的提交时，它们的哈希值发生了变化，因此，我们得到一些提交，就好像它们没有被报告一样
我正在寻找一种在不更改提交哈希的情况下报告我们的错误修复的方法，或者一种列出两个分支之间提交差异的方法，不是通过哈希而是基于消息或其他东西
谢谢
【问题讨论】：
-
cherry-pick不是将提交应用到两个分支的正确方法。阅读此series of articles 以了解为什么cherry-pick不好以及如何正确地做到这一点。 -
提交哈希永远不会改变。具有不同哈希的两件事是不同的提交。听起来您正在寻找
git patch-id，它计算来自git show的差异列表的哈希，即变更集的哈希ID，而不是提交的哈希ID。对于“相同”的某些定义，如果两个不同的提交对相同的文件进行相同的更改，它们将生成相同的补丁 ID。 -
因为这个特定的概念非常有用，Git 有额外的命令来处理补丁 ID：
git cherry为分支集执行此操作，git rev-list有--cherry-mark执行此操作与对称差分操作.他们都在内部使用git patch-id代码来执行此操作，但如果他们不执行您需要的操作，您可以调用git show <commit> | git patch-id来计算您自己的补丁ID 并随意使用它们。 -
话虽如此，请参阅@axiac 的链接以获取更好的方法：只有在陷入可怕情况时才应该使用补丁 ID 进行此操作。
标签： git git-commit git-cherry-pick git-workflow git-worktree