git 多人开发的一个疑问

[yujianwjj]

我同事开发的 feat_1 ，它的代码已经合到 develop 并且上线了，这个时候我的代码要上线，需要把我的代码合到 develop ，这个时候，最佳实践是啥？

[BeautifulSoap]

把最新的 develop 合并到 feat_2
当然把 feat_2 给 rebase 到最新的 develop 也就

[BeautifulSoap]

@BeautifulSoap 也就 -> 也行

[choah]

在你的分支上 rebase develop

[cdswyda]

feat_1 能合并说明是 ok 的。
假设你们上线的代码就是 develop 分支，你的 feat2 要上线，那么也一样 merge 回去就行。

要是你的 feat2 要单独上线测试，走新部署 直接用你的 feat2

[iosyyy]

rebase 最新的代码 然后提交 review

[HankAviator]

觉得先 feat2 rebase develop 再 develop merge feat2 比较好

[Lin0936]

rebase 再 pr

[idealhs]

这不是蛮基础的，你拉一下 develop 然后该推送推送该提 MR 提 MR 好了啊

[charlestang]

feat_2 上线，理论上有这些问题：
1. feat_2 与 feat_1 是否兼容？需要进行兼容性测试；
2. feat_2 在合并回 develop 的时候，是否会引入新的风险因素？需要进行测试；

根据你们团队的规范（有的是用 merge ，有的使用 rebase ），你需要：
1. 先将 feat_2 集成到 develop ，确保即将上线的版本，既包含 feat_1 也包含 feat_2 ，然后进行集成测试；
2. 发布 develop

[43n5Z6GyW39943pj]

这图画的什么呀?都是基于 dev 出来,把 feat_2 合到 dev 不就完事了?

[dfkjgklfdjg]

就是正常的 PR 流程呀。

[wu67]

rebase/merge 呀, 或者 cherry pick 都行

[zengguibo]

git flow 工作流程，怎么弄都不会乱

[angryfish]

我的最佳实践，直接将 feat_2 代码 merge 回 develop

[suiterchik]

根据你同事的 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

[tedzhou1221]

我的理解和 #10 ，feat_2 合到 dev

[tedzhou1221]

除非有冲突，不然的话，直接合过去就好啦

[1018ji]

feat_1 合到 develop 上线，不合 master ？


feat_2 rebase develop ，然后 merge 到 develop

[pkoukk]

它都合进去了，分支理论上都删除了，你就当它不存在就完事了，直接往 dev 合就行啊

[rqzrqh]

feat_2 先尝试能否 rebase develop ，如果能，走正常的分支合并流程。
如果存在冲突 rebase 失败，从 develop 中拉一个分支 develop_tmp ，用 cherry-pick 的方式把 feat_2 的 commit 逐渐合并到 develop_tmp ，逐渐解决冲突，解决完毕后，把 develop_tmp 的代码合并到 develop 。
无论哪种方式，合并后注意一下逻辑是否正常。