不使用rebase时，Git cherry-pick的提交能否保持相同Commit ID？

为什么cherry-pick后Commit ID不一样？ #

Git的Commit ID是基于提交内容、父提交指针、作者信息、提交时间戳等多个维度计算出的哈希值。git cherry-pick的本质是把原提交的代码内容复制一份，在当前分支创建一个全新的提交——这个新提交的父提交是你执行cherry-pick时Development分支的最新提交，和原Master分支上的提交父节点不同，所以必然生成不同的Commit ID，这是Git的正常机制。

Azure DevOps显示的分支状态为什么异常？ #

Azure DevOps是通过Commit ID来判断分支差异的：

• “落后1个提交”：指Master上有那个合并feature的原提交，而Development没有（因为你用cherry-pick生成了新提交，不是同一个ID）
• “超前1个提交”：指Development上有那个cherry-pick出来的新提交，而Master没有
  虽然代码内容完全一致，但Git认为这是两个独立的提交，所以会显示这种看似矛盾的状态。

要让两个分支Commit ID一致的正确操作 #

如果你的目标是让Development包含Master上的那个原提交（保持ID一致），别用cherry-pick，换下面两种方法：

方法一：合并Master到Development（推荐，对分支历史友好） #

# 切换到Development分支
git checkout Development
# 拉取远程最新的Development代码（避免本地分支过时）
git pull origin Development
# 合并Master分支的内容到当前分支
git merge Master

合并完成后，Development会包含Master上的原提交（Commit ID一致），Azure DevOps的分支状态也会恢复正常。

方法二：变基到Master（适合Development没有独立新提交的场景） #

如果在Master合并feature之后，Development没有新增任何自己的提交，可以用变基让Development直接基于Master的最新状态：

git checkout Development
git rebase Master

变基后，Development的提交历史会被调整为紧跟Master之后，原Master上的提交会直接出现在Development里，Commit ID完全一致。

内容的提问来源于stack exchange，提问作者firstpostcommenter