1
BeautifulSoap 2023-11-07 14:41:50 +08:00 via Android
把最新的 develop 合并到 feat_2
当然把 feat_2 给 rebase 到最新的 develop 也就 |
2
BeautifulSoap 2023-11-07 14:43:03 +08:00 via Android
@BeautifulSoap 也就 -> 也行
|
3
choah 2023-11-07 14:43:31 +08:00
在你的分支上 rebase develop
|
4
cdswyda 2023-11-07 14:44:00 +08:00
feat_1 能合并说明是 ok 的。
假设你们上线的代码就是 develop 分支,你的 feat2 要上线,那么也一样 merge 回去就行。 要是你的 feat2 要单独上线测试,走新部署 直接用你的 feat2 |
5
iosyyy 2023-11-07 14:44:14 +08:00
rebase 最新的代码 然后提交 review
|
6
HankAviator 2023-11-07 14:46:13 +08:00
觉得先 feat2 rebase develop 再 develop merge feat2 比较好
|
7
Lin0936 2023-11-07 14:47:30 +08:00 via iPhone
rebase 再 pr
|
8
idealhs 2023-11-07 14:48:13 +08:00
这不是蛮基础的,你拉一下 develop 然后该推送推送该提 MR 提 MR 好了啊
|
9
charlestang 2023-11-07 14:53:28 +08:00
feat_2 上线,理论上有这些问题:
1. feat_2 与 feat_1 是否兼容?需要进行兼容性测试; 2. feat_2 在合并回 develop 的时候,是否会引入新的风险因素?需要进行测试; 根据你们团队的规范(有的是用 merge ,有的使用 rebase ),你需要: 1. 先将 feat_2 集成到 develop ,确保即将上线的版本,既包含 feat_1 也包含 feat_2 ,然后进行集成测试; 2. 发布 develop |
10
43n5Z6GyW39943pj 2023-11-07 14:56:56 +08:00
这图画的什么呀?都是基于 dev 出来,把 feat_2 合到 dev 不就完事了?
|
11
dfkjgklfdjg 2023-11-07 14:57:53 +08:00
就是正常的 PR 流程呀。
|
12
wu67 2023-11-07 14:58:20 +08:00
rebase/merge 呀, 或者 cherry pick 都行
|
13
zengguibo 2023-11-07 15:06:22 +08:00
git flow 工作流程,怎么弄都不会乱
|
14
angryfish 2023-11-07 15:08:36 +08:00
我的最佳实践,直接将 feat_2 代码 merge 回 develop
|
15
suiterchik 2023-11-07 15:19:51 +08:00
根据你同事的 feat_1 是否需要跟着你的 feat_2 一起上线,有以下两种情况:
1. 本次发布只紧急发布 feat_2, feat_1 不跟车发布,则对 master 发起 feat_2 的 merge request ,只发布 feat_2 ,后续 feat_1 需要发布的时候,对 develop 分支 rebase master 分支,相当于 commit 顺序是 develop -> feat_2 -> feat_1 2. 本次发布同时带上 feat_1, feat_2 ,则对 feat_2 分支进行 rebase develop 操作,然后向 master 发起 feat_2 的 merge request 操作;或者先向 develop 发起 feat_2 的 merge request 操作,然后向 master 发起 develop 发起 merge request 。相当于 commit 顺序是 develop -> feat_1-> feat_2 |
16
tedzhou1221 2023-11-07 16:48:14 +08:00
我的理解和 #10 ,feat_2 合到 dev
|
17
tedzhou1221 2023-11-07 16:49:00 +08:00
除非有冲突,不然的话,直接合过去就好啦
|
18
1018ji 2023-11-07 18:03:46 +08:00
feat_1 合到 develop 上线,不合 master ?
feat_2 rebase develop ,然后 merge 到 develop |
19
pkoukk 2023-11-07 18:18:57 +08:00
它都合进去了,分支理论上都删除了,你就当它不存在就完事了,直接往 dev 合就行啊
|
20
rqzrqh 2023-11-07 18:33:12 +08:00
feat_2 先尝试能否 rebase develop ,如果能,走正常的分支合并流程。
如果存在冲突 rebase 失败,从 develop 中拉一个分支 develop_tmp ,用 cherry-pick 的方式把 feat_2 的 commit 逐渐合并到 develop_tmp ,逐渐解决冲突,解决完毕后,把 develop_tmp 的代码合并到 develop 。 无论哪种方式,合并后注意一下逻辑是否正常。 |
22
ccagml 2023-11-07 19:00:17 +08:00 via Android
先创建 pr 从 develop-> feat_2 ,解决完冲突,再创建 pr 从 feat_2 -> develop ,这样做会有什么问题吗?除了提交可能是 merge pull request from xxx
|
23
oneisall8955 2023-11-07 20:43:57 +08:00 via Android
不考虑 git log 的交叉。直接 f2 merge 到 develop 就行。有冲突就把 develop merge 到 f2 先,在 f2 分支解决冲突,最后再重复 f2 merge 到 develop 。
|
24
pianjiao 2023-11-08 07:39:50 +08:00 via Android
先更新后提交
|
25
yolee599 2023-11-08 08:55:23 +08:00 via Android
这种情况直接 MR 不就行了?
|
27
mineqiqi 2023-11-08 09:02:51 +08:00
建议 cherry-pick ,squash commit
|
28
dayeye2006199 2023-11-08 09:35:23 +08:00 via iPhone
经常 rebase
|
29
waterlaw 2023-11-08 14:29:01 +08:00 via Android
feat2 拉出一个分支,merge develop, 再合并到 feat2
|