秋山骏
秋山骏

挣扎中

使用 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

CC BY-NC-ND 2.0 版权声明

喜欢我的文章吗?
别忘了给点支持与赞赏,让我知道创作的路上有你陪伴。

加载中…

发布评论