Git 如何声明我们的历史包含它

我做了以下工作：

git fetch upstream
git cherry-pick xyz

拾取的提交已被干净地应用，只是在其中一个文件中，它的更改与我在上一次提交中所做的更改完全相同，因此不会重新应用这些更改

代码方面的一切都很好，但我希望在我的历史记录中有提交哈希。在我的历史中，它以一个新名字出现。这可能吗？就我所阅读的git合并“我们的”策略而言，这似乎是普遍可行的，但如何为一次提交做到这一点呢

我希望这样做，以便以后更容易确定上游提交的内容有哪些是我没有的。目前，在github

network

视图中，我认为提交是独立的，我没有

其他信息： @CharlesB说的对我来说很有意义。但是，

merge-s-ours

如何实现这一魔法呢？在这种情况下，对我来说挑选樱桃并不重要。因为我想做的更改只有一个，而且在

上游/master

的顶端。所以我只是想试试：

git merge-s我们的上游/master

现在执行git log--graph--pretty=oneline--abbrev commit时，我看到如下内容：

*   9e8108b Merge remote-tracking branch 'mgencur/master' for better github netw
|\  
| * aa7117d Fix displaying watchers/watching for incorrect user // this commit magically appeared after merge -s ours
* | ff05f8c Fix displaying watchers/watching for incorrect user // this is commit from cherry-pick of aa7117d
* | b7ca8ec older commit in my fork
* | <more commits in my fork>
|/  
* 94d6870 Fix obtaining available users for testing purposes
* <older commits of upstream/master>

正如您在认真挑选commit aa7117d后所看到的，没有迹象表明aa7117d已经应用于我的叉式回购。但是在合并之后，它被指示它在那里，尽管我的文件中没有任何更改

这使我认为，确实可以声明分支中包含的许多提交，尽管它们并没有像应用于上游一样应用于

---

更新2：我看到了这个问题及其最好的答案。因此，如果能解释为什么不可能或没有实施，也将不胜感激

根据定义，提交哈希对于每个提交都是唯一的

樱桃采摘时，您正在创建一个新的提交，即使您应用了相同的修改，因为它具有不同的父提交

但是，您可以添加ask git以在提交消息中放置消息：

樱桃从提交中挑选

从：

-x

记录提交时，在原始提交消息后附加一行，上面写着“（cherry picked from commit…”，以指示 cherry是从哪个提交人那里挑选的。这只是为了 樱桃采摘没有冲突。如果您需要，请不要使用此选项 从你的私人分支机构挑选樱桃，因为信息是 对接受者没用。另一方面，如果你正在采摘樱桃 在两个公开可见的分支之间（例如，将修复向后移植到 维护分支（用于开发分支的旧版本）， 添加这些信息可能很有用

---

Git不允许你这么做。Git哈希唯一地标识提交及其所有历史记录。这意味着，当你选择一个提交时，你会将一个补丁应用到另一个历史，因此没有办法（除非在一些奇怪的情况下，散列冲突）使散列保持相同

---

执行合并时仍然可以看到原始散列数的原因是，这里的情况完全不同。合并不是具有单亲提交的正常提交。相反，它有两个（甚至更多）父提交，将单独的开发链组合在一起。因此，合并头的原始历史记录得以保留。

请参阅我问题中的“附加信息”。在我看来，可以将某些提交声明为应用于当前分支，尽管它们实际上并不相同。也许不是cherry-pick命令？我不明白“声明提交应用于当前分支”是什么意思。您的意思是要在合并操作中选择要包括/排除的提交吗？请参阅

ours

合并策略说明。我希望它们像合并操作一样被应用。我想这可以通过一些分支和合并操作来实现。但如果

cherry-pick

命令自动执行，那就太酷了。你似乎对什么是cherry-pick和merge感到困惑。前者将指定的提交应用于当前分支。这就像导出修补程序文件然后应用它的捷径。没别的了。后者还创建了一个新的提交，但该提交有两个父提交。因此，没有承诺会在另一个分支上修补，这更像是将开发链合并到一个分支中。这就是为什么您会在历史记录中看到原始的哈希字符串，但这只是因为它们仍然存在，没有从原始状态进行修改。@Michael Wild，是的，我想要某种合并/樱桃选择组合。这永远不会起作用。这不是Git的工作方式。散列唯一地标识提交，如果更改其父提交，则散列必须更改。这就是为什么说提交哈希在Git中是加密安全的。若您可以验证分支头的散列，那个么您已经有效地验证了它的整个历史。任何修改该历史记录的操作都将更改哈希值。句号。@MichaelWild，谢谢你的评论，我想我所有的作品都各就各位了。如果你愿意写一个答案，我就给你评分。

* ff05f8c Fix displaying watchers/watching for incorrect user // this is commit from cherry-pick of aa7117d
* b7ca8ec older commit in my fork
* <more commits in my fork>
* 94d6870 Fix obtaining available users for testing purposes
* <older commits of upstream/master>