• 分支管理

    1. 概述

    分支管理是整个开发流程中非常重要的一环,旨在帮助开发团队建立规范,从而进行快速开发与持续交付。通过此页面您将了解到如何规范地在BrDevOps平台中创建分支和管理分支。

    1.1 分支管理策略

    分支是将您的开发工作从主线上分离开来,以免影响主线。BrDevOps平台主要使用 GitLab 进行分支管理。目前平台中支持的分支类型为:master,feature、bugfix、release、hotfix ;此外,您还可以根据需求,创建自定义类型的分支。

    至于分支管理模型,BrDevOps采用了 github-flow 作为分支管理策略的主体。并在此基础上,参考了一些其他策略,从而对开发者的开发分支做了一定程度上的细分。

    image

    1.1.1 主分支 master

    1.1.2 开发分支 develop

    1.1.3 预发布分支 release

    1.1.4 功能分支 feature

    1.1.5 修补 Bug 分支 bugfix

    1.1.6 热修复分支 hotfix

    1.1.7 用户自定义分支 custom

    2 开发流程

    借助BrDevOps平台进行开发,可以实现整个开发流程的规范化与可视化。以下是开发流程中的具体步骤与相应规范。

    2.1 创建分支

    2.1.1 在BrDevOps平台中创建分支

    image

    2.1.2 在本地创建分支

    如果您对 git 操作相对熟练,则可以在本地直接创建 feature 分支。在这里,同样基于 master 来创建。

    image

    2.2 提交分支

    image

    image

    此时若是查看提交记录,应能看到合理、有序的提交信息(非必要)

    image

    image

    image

    将 squash 和 fixup 命令当作命令行参数使用,自动合并 commit 记录。具体可以参考 Florent Lebreton 的文章

    2.3 与主干同步分支

    image

    2.4 推送到远程仓库

    2.5 创建合并请求

    创建合并请求同样支持两种方法,一种是直接在代码中处理,一种是直接在BrDevOps平台中操作
    1. 在git中创建合并请求

      • 发出 feature 到 master 的合并请求,或是按实际情况的合并请求。
      • 向项目代码的管理者提出 code review 要求。
      • 根据 reviewer 提出的建议等进行讨论修改代码,再次提交,重复 code review
      • 在代码审核通过后,接受合并请求,并删除该分支。(强烈建议此步由 reviewer 或是管理者操作)
    2. 在BrDevOps平台中创建合并请求

    分支被推送到远程仓库之后,可以直接在BrDevOps平台中创建分支合并请求,然后在Gitlab中进行分支合并。

    image

    3. 修改分支关联问题

    如果您想修改分支关联的问题,可以点击修改分支,从而对关联的问题进行更改或清空。

    若分支创建时未关联问题,并且分支名称是以某一个问题的issue号开头的则修改分支相关联问题时系统会默认关联到该问题。

    4. 删除分支

    分支创建之后,若发现分支不必要,可以直接进行删除。但是需要注意的是,分支删除之后,分支上的代码也将一起被删除。

    5. 注意事项

    1. 每日工作结束前,必须提交当前的工作目录改动,无论是否完成功能点。

    2. 不论采用哪种分支管理策略,务必严格遵守操作规范。

    3. 提交信息应能清晰描述所做的改动,方便后来人的阅读。

    4. 提交信息可以视具体项目的规定来提交,但是一定要保证格式统一。建议包括改动类型、改动文件位置、改动内容、关联 issue 信息等。

    5. 禁止任何不能清晰表达改动的提交信息。

    6. 如有条件,修改他人关键代码部分最好能够通知当事人。比如口头通知或是代码审核增加 reviewer 等。

    7. 合理使用 git status 命令,任何情况特别是失误操作后,随时可以使用该命令查看当前状态。特别建议新手在每一步的操作中间都增加 git status 命令。

    8. 严禁对 origin 仓库的强制推送,不论方式。除非目标是自己的开发分支并且了解强制推送会造成的后果。

    9. 在要进行或是测试危险操作前,备份当前分支。防止意外造成代码丢失。

    10. 远程仓库合并结束后,必须删除源分支。建议在合并请求勾选 Remove source branch 选项。

    11. 严禁任何类似 [FIX] Handling conflicts 的提交。

    6. 危险操作

    所有可能改变工作目录代码的操作都会是危险操作。所有相关操作过程都需要格外慎重。

    以下列举一些较为常见的 git 上可能会接触使用到的危险操作。

    1. 解决冲突

      • 代码冲突是 git 使用过程中最常见的问题,大量的冲突往往是因为当前分支同步不及时导致的。所以再次强调及时同步。
      • 解决冲突时一定要细心,从代码的第一行开始,由上至下解决冲突部分。 当冲突代码中存在逻辑冲突的,需要仔细分析。如有条件,与当前冲突提交的提交人协商讨论。
      • 解决冲突完成后,全文搜索冲突标志。即 <<<<<<< 、 ======= 、 >>>>>>> 。
      • 冲突解决完成后,提交前必须再次运行并且测试代码。
    2. 强制推送

      • git push –force
      • 强制推送是一个不可避免的危险操作,慎重使用。
      • 若因为种种原因导致分支历史改变,与远程仓库的分支不兼容。可能需要加上 –force 或 -f 参数进行强制推送。
    3. 重置

      • git reset
      • reset 分为 hard-reset 和 soft-reset 。
      • soft-reset 将撤回对应的提交信息。
      • hard-reset 将撤回对应的提交信息以及所有修改。
      • 重置前务必确认当前分支做了备份,以免代码遗失。
    4. 储藏

      • git stash
      • 储藏是个很便捷的应用,但是不推荐使用。
      • 当因为种种原因需要切换当前分支,但是暂存区或者工作目录里,还存在没有提交的修改,它会和你即将检出的分支产生冲突从而阻止 Git 为你切换分支。
      • 切换分支的时候最好保持一个清洁的工作区域,这时可能会用到 git stash 命令。
      • “储藏”可以获取你工作目录的中间状态——也就是你修改过的被追踪的文件和暂存的变更——并将它保存到一个未完结变更的堆栈中,随时可以重新应用。
      • 对于新手时常能造成工作内容丢失,储藏内容丢失等等意外情况。没有充分练习掌握请勿使用以免造成损失。
      • 可以使用 git commit 和 git reset 组合来替代, git reset 虽然同样是个危险操作,但是掌控比储藏操作来的更加简单。
    5. 变基

      • git rebase
      • 把一个分支中的修改整合到另一个分支的办法有两种: merge 和 rebase 。 rebase 可以把在一个分支里提交的改变移到另一个分支里重放一遍。
      • rebase 的操作不当,可能导致原分支被修改等后果。作为一个危险操作,需要慎重。
      • 变基操作解决冲突后应执行 git add . 和 git rebase –continue ,而不是 git commit 命令。
      • 变基操作在操作规范中已有提及,还可以参考 Git 分支 - 分支的变基
    6. 抛弃文件修改

      • git checkout – demo.demo
      • 抛弃文件的改动,使文件恢复到修改前的状态。
      • 在使用前,对当前分支备份。
    7. 重写历史

      • 在 Git 上工作的时候,你也许会由于某种原因想要修订你的提交历史。
      • 通过 amend-commit 、 reset 、 rebase 等多种操作都能达到这个效果,具体参见 Git 工具 - 重写历史

    7. 阅读更多