使用 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
喜欢我的作品吗?别忘了给予支持与赞赏,让我知道在创作的路上有你陪伴,一起延续这份热忱!