zoukankan      html  css  js  c++  java
  • git分支管理的使用案例及深入分析

    首先谈谈分支管理 :

      常用互联网开发中的分支管理有如下对应关系:

      develop  ------>  常用开发分支,会频繁变动

      release   ------>  测试环境分支, 即产品α版对应的分支,此分支须相对稳定

                     ------> 预发布环境分支, 即产品β版对应的分支, β版与α版分支代码相同,区别在于β版使用线上数据库,α版使用测试环境

      master    ------> 正式环境分支,即产品正式版对应的分支。此分支需要特别稳定, 为正式生产级。

    (以上可能各公司不尽相同,但大体是这样的对应关系)

    谈完常用分支,谈一下分支管理的原则:

       尽可能消除merge 与 revert log记录,尽可能使得git发布路线图单一。

      例如:

      

    这样的发布路线图就是特别成功的分支管理实践。

    而下面:

    这样的路线图关系特别混乱, 是非常不成功的。

     接下来谈下develop分支开发管理实践:

       开发某一特征或者修复某一bug时,

       1先在develop分支(如本地没有,须从本地remote分支checkout出本地的develop分支)进行git pull命令,或者git fetch; git rebase命令;

       2然后进行代码修改, 代码修改完成后git commit(如需与上次未push commit合并,请执行git commit --amend),此操作将修改提交到本地仓库;

       3执行git pull或git fetch ; git rebase;如有冲突解决冲突,然后git commit;

       4git push将本地修改推到远程仓库;

     如果集成了CI,此步操作会自动构建代码到α版环境;

    此时如果测试通过需要构建到 预发布β版环境,则

     1切换到release分支(远程release分支对应的本地分支),git pull;

     2 git merge develop;(此操作建立在预发布最新commit与测试环境分支历史某一刻base相同的情况);

        如果预发布分支最新提交与develop分支没有任何关系,则考虑此最新提交是否要写到develop分支,

       正常是需要的, 正常开发预发布环境和测试环境代码须保持一致;包括配置文件;配置文件可以写多个,

       部署时从其中选择, 做到配置文件不影响代码仓库的整洁性。

       如果这样, 可以保证release分支代码log中不包括merge的log,不包括merge的log可以使提交历史一目了然,所以代码管理的原则就是尽量减少merge以及revert等的log记录。

     3 git pull;确保此过程没有别的用户在release分支有操作。

     4 git push;

    如果此过程出现了问题: 比如产生了冲突,或者遇到了产生merge log 以及revert log的情况,笔者经常遇到这样的情况 :). 需要做的是找到一个develop和release分支的base点:

    如下图:

     图中有release分支及develop分支, 最左侧为master分支打出的tag。这种情况一定不能merge,需要很好地处理。

    1找到图中划线的基准点,确认基准点上的release分支上的所有提交在develop分支都存在,(如果不存在, 则须手动cherry-pick,一定要按提交顺序,以保证不产生merge 和revert 的log, 操作完成后记得执行push操作,因为release分支修改的代码, develop分支也是一定需要的)

    2完成后, 在release分支上执行reset --hard <基准点commit的提交随机串> (PS:你没有看错, 就是--hard,放心, 因为你的代码在远程仓库上是有的, 所以大胆操作吧) 

    3 release 分支上执行 git push --force 此处一定需要--force,如果不这样, 本地分支在提交到remote端时会被rebase或者merge而恢复原有release分支的代码,或者产生merge操作的log, 这项操作就是为了使得远程分支的代码强制回退到基准点。

       有人一定会问, 那这样不是丟掉了分支上的代码么, 对 , 是的, 确实丢掉了, 但是别急, 因为develop 分支已经将release分支所有不一致的修改提交cherry-pick,所以代码还是有的, 放心操作吧。

    4 release分支上执行git rebase develop ;因为release分支现在最新提交是和develop分支的某一历史提交, 所以直接执行git merge 操作不会产生任何问题(或者此时执行rebase操作也是可以的, 但是语义上来说git merge比较合适一点)。

    5 git push 到remote(最好先pull一下以防release分支有别人的修改)

    此时完成预发布环境的代码构建。

    再谈一下master分支:

         master分支是正式环境,线上环境的分支, 需要保持十分的稳定, 当出现bug时(包括紧急bug), 不要直接在master上修改, 需要 在develop分支上改完,合到release验证通过后, 方能合到master。

        所以master分支一般情况都是release分支的某一基准点, 所以在master和代码时,可以直接在master分支,进行git merge release操作。此时不会出现任何问题, 还可以保证代码仓库提交历史的干净整洁,只有功能和特征的描述;发布release notes时 , 可以直接从commit messages提取。效果如下:

    尽情享受干净整洁的代码仓库带来的好处吧!

  • 相关阅读:
    gThumb 3.1.2 发布,支持 WebP 图像
    航空例行天气预报解析 metaf2xml
    Baruwa 1.1.2 发布,邮件监控系统
    Bisect 1.3 发布,Caml 代码覆盖测试
    MoonScript 0.2.2 发布,基于 Lua 的脚本语言
    Varnish 入门
    快速增量备份程序 DeltaCopy
    恢复模糊的图像 SmartDeblur
    Cairo 1.12.8 发布,向量图形会图库
    iText 5.3.4 发布,Java 的 PDF 开发包
  • 原文地址:https://www.cnblogs.com/braveliuchina/p/8312942.html
Copyright © 2011-2022 走看看