search

zhangsanshi / issue-blog

It's a blog rather than issue
0 stars 0 forks source link

git分支开发 #19

Open zhangsanshi opened 7 years ago

zhangsanshi commented 7 years ago

git分支开发的两种方式

一点不成熟的想法，感觉最近流程上出了点问题

1.方法一

分支结构:

-- master
-- release1
    -- feature1
    -- feature2
-- dev

步骤:

a. feature 均从 release1 检出分支，任意合并到 dev，feature 产生的 bug 均归属于该 feature，保证 feature 和 dev 之间形成闭环，不允许在 dev 上修改属于 feature 的功能以及 bug

b. 如果 master 出 bug，检出分支，修复后合并到 dev、release1、master 分支，并确保产生 release2，后续 feature 从 release2 产生

c. UAT 时，若 feature1、feature2 确认开发完成并发布，从 release2 开出新分支，合并相应的 feature1、feature2 到 release3，即使此时 dev 可能有 feature1、feature2、feature3 ...

d. UAT 出现 bug，确认出现问题的 feature，修复该 feature，合并至 dev、release3

问题:

a. 在 feature1 和 feature2 出现功能冲突的时候，同时发到 dev，会出现功能覆盖的问题

b. dev 代码很杂乱，产生问题需要进行排查

2.方法二

分支结构:

-- master
-- release1
-- dev
    -- feature1
    -- feature2

步骤:

a. feature 均从 dev 检出分支获得

b. 需要测试 feature1/2，则把分支切成 feature1/2，待测试完毕后，合并到 dev，同时 bug 均属于该 feature

c. master 出现 bug，检出新分支，修复后合并到 dev master，可能需要合并到各个 feature

d. UAT时，检出 dev 到 release2 即可

问题:

a. 在 feature1、feature2 ... 合并到 dev 后，又出现 feature1 的功能不发布的情况，需要较大改动 dev 分支，但是可以通过检出另一个干净的分支解决

b. 无法及时测试各个 feature 代码之间产生的影响，如果需要动 dev 的代码，需要各个分支同时合并 dev
zhangsanshi commented 7 years ago

在这里描述一下 git flow 的流程：

  1. 分支 dev、master。所有的 feature 均从 dev 迁出，当 feature 完成后，再次合并到 dev 分支，如果在合并后但又未检出 release 分支，这时候出现错误，可以选择从 dev 检出新分支 或者 在老 feature 上继续开发。
  2. 当检出 release 分支进行测试，出错直接在 release 分支上修复 bug，待 bug 修复完毕，检出 master 分支，合并回 dev 分支，并且打好标签。
  3. 当 master 出现 bug，检出 hotfix 分支，修复 bug，合并回 master 分支，dev 分支，打好标签。

问题：

a. 遇到 feature 临时决定不发布的情况（别问我，为什么会这样）。。。如何快速干净的抽出该 feature。