pull request 是不是用 cherry-pick 实现的呢?

2020-04-26 10:26:33 +08:00
 windflowerxx

我刚接手 java 开发,正在开发新功能和修复一个旧缺陷,这次上线只上线修复缺陷的版本,

我本来是从 dev 分支,选择我修复的 commit 进行 cherry-pick,合并到生产的分支

但是怕这样做和团队原来的风格不一致就问了前辈,前辈就叫我上码云上新建 pull request,在网页上选择我要拉取的 commit 来合并到生产分支。

我突然有个疑问,pull request 除了有个审核的功能之外,它内部选择 commit 拉取到其它分支的做法是不是靠 cherry-pick 实现的呢

2758 次点击
所在节点    git
8 条回复
SilentDepth
2020-04-26 11:05:41 +08:00
Pull Request 就是个 Merge 啊
VDimos
2020-04-26 11:30:41 +08:00
是的
enjoyCoding
2020-04-26 11:40:04 +08:00
pull request 的有三种方式
cherry-pick 只能模拟其中一种 大多数情况下三种是不同的 只有一个提交的话
cherry-pick 更简单些

pr 有用到 merge rebase
cherry-pick 的优势在于可以选择 commit
lhx2008
2020-04-26 11:43:34 +08:00
可以去 github 体验一下,merge 有三种方法可以选,好像不需要 cherry pick
sfqtsh
2020-04-26 12:22:02 +08:00
你们新功能和 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 。
itstudying
2020-04-26 12:39:27 +08:00
@sfqtsh 这个应该是正解,因为我们这流程就是这样 😂
baiyi
2020-04-26 13:29:18 +08:00
pr 的三种合并方式对应的应该是 merge 、rebase 、rebase squash
windflowerxx
2020-04-27 08:23:03 +08:00
好的 明白了,谢谢大家的解答😀

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/666175

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX