使用 git flow 时 feature 分支的处理

目前尝试使用 git flow ，但是不知道一个 feature branch 应该持续多久 。我一星期前从 develop 分出来的 feature A branch ，现在别人的 feature B branch 开发完成后 merge 到了 develop ，我的 feature A branch 上是没有 feature B branch 的代码的。这就导致了一些问题。讨论后得到很棒的回答！汇总如下：

问：

1. feature B branch 的代码如果在我这里会对我有帮助，我该怎么办？

答：

「有帮助」意味着你依赖 B 的一些内容，

a. B 还没合并到 dev， 你可以 cherry-pick 过来先用着.

b. B 合并到了 dev，你的分支是来自 dev 的，那你直接 rebase 你的分支到最新的 dev 就完了

另一个答：

难道不是 git rebase 一把梭？

另一个答：

建议尝试 jetbrains ide task management

可以用开源项目申请 jetbrains

问：

2. 如果等我的 feature A branch 开发完成后 merge 到 develop 上产生一堆 conflict ，我该怎么办？

答：

a. 你应该至少每天 rebase 一下 dev 避免自己分支太旧（太旧意味着可能累计 conflict，到时候即使简单的 conflict 堆起来也会很头大）

b. 只要是在合并三路（一般是你自己的，别人自己的，你们公共的）内容，该发生的 conflict 一定会发生，不管你用任何方式合并都会发生，看的懂就自己修，看不懂就找变更的另一头的人来辨识一下

c. 尽量不要和别人碰相同的地方（避免冲突的可能性

问：

我在网上查了一下，有的人说把最新的 develop 拉到本地，然后从 feature A branch 分出一个 stage branch ，把 develop merge 到 stage branch 上，然后处理好 conflict ，然后把 stage branch merge 到我的 feature A branch 上。我感觉这样好麻烦。

答：

很麻烦是的，打死那个人，只需要 fetch（拿到新版 dev） + rebase（让你自己的分支基于最新的 dev） 就完了，不需要单独糊分支，

具体看

https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase

问：

然后我在想，我是不是当初应该把 feature branch 的目的定小一点，尽量让一个 feature branch 只持续一两天，这样是否就可以避免多个 branch 来回 merge 的痛苦了呢？但是这样做的话，岂不是把 feature branch 当成 commit 在用？那我还要 git flow 干嘛？直接大家都在 develop 上开发不就完了。

答：

时间不是因素，量别太大就行. 定合适的量这种事情自己判断吧（

btw 千万避免「来回」merge 这种事情，这会让你想干死告诉你应该来回 merge 的人，也会让帮你 debug 的人想干死你（或者没救了，等死吧

另一个答：

我有时候也觉得 一个分支就够（逃

但是本地的 feature 分支有一个重要的作用是，时刻保持着自己写的最新代码

以防被别人干掉

参考：

https://stackoverflow.com/questions/21661263/gitflow-safely-merge-develop-changes-to-a-feature-branch

https://zellwk.com/blog/git-flow/

https://git-scm.com/docs/git-rebase#_description