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

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

也就 -> 也行

在你的分支上 rebase develop

feat_1 能合并说明是 ok 的。 假设你们上线的代码就是 develop 分支，你的 feat2 要上线，那么也一样 merge 回去就行。要是你的 feat2 要单独上线测试，走新部署 直接用你的 feat2

rebase 最新的代码 然后提交 review

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

rebase 再 pr

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

feat_2 上线，理论上有这些问题：1. feat_2 与 feat_1 是否兼容？需要进行兼容性测试；2. feat_2 在合并回 develop 的时候，是否会引入新的风险因素？需要进行测试；根据你们团队的规范（有的是用 merge ，有的使用 rebase ），你需要：1. 先将 feat_2 集成到 develop ，确保即将上线的版本，既包含 feat_1 也包含 feat_2 ，然后进行集成测试；2. 发布 develop

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

就是正常的 PR 流程呀。

rebase/merge 呀, 或者 cherry pick 都行

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

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

根据你同事的 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_12. 本次发布同时带上 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

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

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

feat_1 合到 develop 上线，不合 master ？feat_2 rebase develop ，然后 merge 到 develop

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

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

不应该是先 rebase develop 嘛？ merge 还的解决冲突

先创建 pr 从 develop-> feat_2 ，解决完冲突，再创建 pr 从 feat_2 -> develop ，这样做会有什么问题吗？除了提交可能是 merge pull request from xxx

不考虑 git log 的交叉。直接 f2 merge 到 develop 就行。有冲突就把 develop merge 到 f2 先，在 f2 分支解决冲突，最后再重复 f2 merge 到 develop 。

先更新后提交

这种情况直接 MR 不就行了？

实际开发中确实是你这样操作的。

建议 cherry-pick ，squash commit

经常 rebase

feat2 拉出一个分支，merge develop, 再合并到 feat2