产品帮助中心

# 使用技巧

# 向非保护分支发评审

DCR因为使用便捷，所以在实际研发场景中，广受欢迎。 但是默认情况下使用git push命令只有向保护分支提交代码才会自动生成评审。 如果向非保护分支也希望通过命令行快速发起评审，可以使用如下命令:

$git push -o dcr

# 发DCR评审时自动通知评审人

创建DCR时，可通过-o参数直接想评审人发送通知， 例如如下命令可实现向非保护分支发起DCR的同时，同步向liuqing、zhutiankai两个用户发送评审通知。@符号表示后面是指定评审人列表:

$git push -o dcr -o @liuqing,zhutiankai

# 目录层级页面管理目录及目录下代码库

通过在代码库列表点击【层级目录】，可以切换到层级目录设置界面。 层级目录可以非常清晰的展现代码库的层级关系，为部门或者团队统一管理代码库目录和代码库提供了方便的入口。 目录设置

# 新建子目录

点击任意一级目录的[新建子目录]按钮，即可在该目录下新建子目录。 目录设置

# 目录的成员管理

点击任意目录的[目录设置]按钮，可进入目录的成员管理界面。 目录设置 可以设置目录的管理员、维护者、开发者、只读者。目录管理员拥有目录的最高管理权限，可以管理目录下（含子目录）的所有代码库。
维护者、开发者、只读者角色没有固定的权限，并且和代码库中的默认角色是一致的。具体的作用是用于代码库可以继承目录的对应角色的成员。
[目录权限继承]开关的作用是当前目录可以继承父目录的对应角色的成员。

# 删除目录

目前仅支持删除空目录，如果目录下有代码库，则无法删除。 点击空目录的[删除目录]按钮，再完成确认操作后，实现目录的删除 目录设置

# Gitflow与DCR、MR结合使用

完整的Gitflow算是git分支模型中最复杂和严谨的了。 通常在企业研发过程中，都会对Gitflow进行精简。 本例已一个完整Gitflow为例，介绍一个最复杂场景下Gitflow与DCR、MR结合使用。 如下图所示，仅需做如下措施即可：

  • 将代码库所有分支均设置为保护分支，所有入库代码都需要评审，作为企业研发规范（实际上业界很多大厂都要求入库代码必须经过评审）
  • Gitflow中原有分支合并操作依然使用MR，不变
  • 本地向服务器端Feature分支的代码直接提交自动会生成DCR Gitflow

# 常用的Gitflow简化模型

Gitflow的问题就是分支太多，分支类型也太多，所以常见的方式就是减少分支和分支类型数量 分支的目的是起到隔离的做用，而软件工程讲究持续集成，尽量早的集成，所以每种类型分支的减少，都需要团队具备更强大的持续集成能力。

  • 将Gitflow中的Feature类型分支舍去，其他分支保留 直接通过DCR向Develop分支发起代码评审，其他分支合并使用MR 这个时候就需要团队使用例如Feature开关、后端先行、接口兼容等技术手段弥补Feature分支带来的问题。 简化模型1

  • 只留Master分支 这是一种极端的例子，主干开发，只有团队具有极强的工程能力保障才适合此模型。 工程能力强的团队通过代码评审、Feature开关、超强的自动化测试能力、小流量上线机制等 保障主干代码是高质量可随时上线的，如果有线上问题，可及时回滚。 当然也有团队工程能力一塌糊涂的也搞主干开发的，就是搞的会比较狼狈。

  • 分支开发主干发布模型 主要保留Develop分支、Master分支 通过DCR向Develop分支提交代码，提测后，发起MR合入Master分支，Master测试流水线通过后，发布版本，部署上线。 紧急Bug必须通过Hotfix修复的，Hotfix分支处理方式和Gitflow模型类似。 否则通过回滚或者在下一个版本的开发分支上修复。

  • 主干开发分支发布模型 主要保留Master分支、Release分支 在Master上进行开发，测试和问题修复。问题收敛达到提测要求时，拉出Relase分支，如果Relase分支上的测试通过，则打Tag、部署上线。 否则可以在Release 分支继续进行临时问题修复后上线。

# 集成Sonarqube

如果在流水线中配置了Sonarqbue代码扫描插件， 则该插件会在扫描结束后将结果推送到该分支的代码浏览页。 点击该结果即可查看代码质量详细报告。 注：该推送结果只会保留最新被推送的结果，新推送数据会覆盖老数据。 查看代码质量

← Git基本操作 →