Git cherry pick，github分支比较和SHA ID，噢，天哪

我有一个关于cherry pick的问题。我们有一个包含两个主要分支的项目：部署和开发，这是一个简化但准确的视图。部署是我们已经部署到生产服务器上的，而开发是我们正在开发的功能分支，用于单个功能/修复等

我们有一个commit，它通过一个GitHub请求从一个功能分支合并到develope中，该请求来自我们需要推向生产的单个开发人员的fork。在develope上还有其他提交，我们还不想放到部署中，所以我做了一个git签出部署&git cherry pick 049cae3&git push来获取我们需要的一个提交。这一切都很好，代码被推到了生产环境中。但是，我们有一个状态仪表板，它使用GitHub API对deploy..develope进行比较，以查看我们在develope上累积了多少次提交，而没有在deploy上。我注意到数字没有改变，当我在github上查看比较页面时，我的cherry pick提交仍然显示在差异中。我猜这是因为cherry pick使用新的SHA应用提交，所以github不会将其视为在两个分支中-它们是两个不同的提交

这可能没什么大不了的，因为在某个时候我们会将develope合并到deploy中，但是我可能会有一个重复的提交，对吗？是的，我们正在进行合并，rebase吓了我一跳，我还没有真正弄明白

---

那么：鉴于我需要一个具体的承诺，cherry选择了正确的方式吗？如果不是，那是什么？

与您的问题没有直接关系，但您确实应该学会重新设置基础，否则您只是没有尽可能有效地使用Git。你可以认为这和樱桃采摘是一样的，只是你选择了不止一个承诺。在这种情况下，rebase会对我有什么帮助？@grahamb:不会，至少不会直接。但是，您现在可以使用rebase-i重新设置开发分支的基础，这样它就可以在部署中新的cherry-picked提交之后启动，并且省略它自己的cherry-picked提交版本。这是个好主意还是坏主意取决于太多其他变量。