我刚接手 java 开发，正在开发新功能和修复一个旧缺陷，这次上线只上线修复缺陷的版本，
我本来是从 dev 分支，选择我修复的 commit 进行 cherry-pick，合并到生产的分支
但是怕这样做和团队原来的风格不一致就问了前辈，前辈就叫我上码云上新建 pull request，在网页上选择我要拉取的 commit 来合并到生产分支。
我突然有个疑问，pull request 除了有个审核的功能之外，它内部选择 commit 拉取到其它分支的做法是不是靠 cherry-pick 实现的呢
 | 1 SilentDepth Apr 26, 2020 Pull Request 就是个 Merge 啊 |
 | 2 VDimos Apr 26, 2020 via Android 是的 |
 | 3 enjoyCoding Apr 26, 2020 pull request 的有三种方式 cherry-pick 只能模拟其中一种 大多数情况下三种是不同的 只有一个提交的话 cherry-pick 更简单些 pr 有用到 merge rebase cherry-pick 的优势在于可以选择 commit |
 | 4 lhx2008 Apr 26, 2020 via Android 可以去 github 体验一下，merge 有三种方法可以选，好像不需要 cherry pick |
 | 5 sfqtsh Apr 26, 2020 via Android  2 你们新功能和 patch 都提交到同一个 dev 分支？但只想 back-port 这个 patch 到发布版本所在分支？ 像我们，提 PR 一个是让团队其它成员评审，一个是可以跑 CI 。都保证没问题再合入到发布分支。(有些 patch 可能 dev 分支没问题，在发布分支就有问题了)。 所以你应该： * 从发布分支拉个新分支，命名 xxx-patch * cherry-pick dev 分支的 patch 提交 到 新分支 * push 新分支 * Web 上选择 PR: 新分支-> 发布分支 PR 发现了问题，可以随时 add commit 或 force push 后重新评审，，而不会影响你的发布分支。你如果直接 cherry-pick 到发布分支，有问题怎么办？回退 or 重新提交次修复？ PR 结果是合入分支，方法一般是 merge (虽然还有 rebase, squash 等)。merge 和 cherry-pick 本质不同，前者是合入 snapshot，后者是应用 change 。 |
 | 7 FinnBai Apr 26, 2020 pr 的三种合并方式对应的应该是 merge 、rebase 、rebase squash |
 | 8 windflowerxx OP 好的 明白了，谢谢大家的解答 |
Select Language