功能代码在 Release 分支上测试通过、或 BUG 已在 Hotfix 分支上修复，则需要将代码合并到 Master 分支。
代码合并到 Master 分支，即代表可以随时发版，发版成功时需要基于 Master 分支上的最新提交节点打 Tag。
Hotfix修复分支 + 临时分支。
线上出现紧急 Bug 时，需要基于对应版本的 Tag 创建修复分支，问题修复完成时以此分支进行提测。
问题修复后，需将代码合并到 Develop 和 Master 分支。
基于发版 Tag 创建，最后合并到 Develop 和 Master 分支。
Release预发布分支 + 临时分支。
功能开发完成并合并到 Develop 分支时，基于 Develop 分支创建 Release 分支进行提测 。
Release 分支上出现影响发版的 Bug 时，需要创建 Feature 分支修改 Bug；当测试通过后，需将代码合并到 Develop 和 Master 分支。
基于 Develop 分支创建，最后合并到 Develop 和 Master 分支。
Develop开发分支 + 保护分支。
多人协作开发时的代码合并总分支，功能分支向 Develop 分支合并时，往往会有 CodeReview 流程。
基于 Master 分支创建。
Feature功能分支 + 临时分支。
有新需求时，基于最新的 Deveop 分支创建功能分支，功能开发完成时，需将代码合并到 Develop 分支。
基于 Develop 分支创建，最后合并到 Develop 分支。
3. Tag&Branch 的区别Tag 和 Branch 类似，都是引用或者说者指针。
在工程里 .git/refs 目录下能够清楚的看到，各个 Tag 和 Branch 所指向的提交节点的 SHA-1 值。
区别：Tag：Tag 的位置是固定的，在给指定提交打好标签以后，它就固定于此位置Branch：Branch 的位置是会不断变动的，随着分支的向前推移或者向后回滚，都在不断变化尽量使用 Tag，保存代码片段。
二、Git Commit 提交规范1. Commit Message 格式<type>(<scope>): <subject><空行><body><空行><footer>可以看出分为三个部分，头部、主体、底部。
头部<type>(<scope>): <subject>type 类型，修改的类型级别：feat：新功能（feature）fix：修补 bugdocs：文档（documentation）style： 格式（不影响代码运行的变动）refactor：重构（即不是新增功能，也不是修改 bug 的代码变动）test：增加测试chore：构建过程或辅助工具的变动scope 修改范围：主要是这次修改涉及到的部分，最好简单的概括subject 修改的副标题：主要是具体修改的功能点body：主要对本次 commit 的详细描述，可以分成多行。
footer：主要放置不兼容变更和 Issue 关闭的信息。
为了方便代码的快速提交，body 和 fotter 部分可以省略。
2. 使用介绍需求开发或者修改 Bug 时，提交代码时要添加对应 Jira 编号：git commit -m "feat(CHESS-1217): 我的页面增加分享入口及分享功能开发"修改 Bug 时，需要指明修改代码所在模块：git commit -m "fix(分享): 修改修改部分手机分享大图为空问题"没有具体模块、或者多模块代码一起提交时，可使用其他提交方式：git commit -m "fix(BUG): 修改推送红点提示逻辑"3. 相关工具Git Hook 自定义拦截脚本：commit-msg使用环境：python3.7使用方式：打开工程目录下的 .git/hooks 文件夹将 commit-msg 脚本复制到文件夹下，即可全局设置：通过以下方式，可全局设置，每次 git clone 时，自动将 commit-msg 脚本添加到工程的 hooks 目录中：全局设置 commit-msg。
其他工具：Commitizen：辅助撰写合格 Commit message 的工具Commitlint：Commit message 规则校验工具4. 拓展GitLab 与 Jira 关联效果：Git Commit 时，在 message 里面添加工单号，可在 Jira 对应工单详情页查看到本次提交。
配置：官方文档。
三、代码评审流程1. 评审环节代码评审发生在 Feature 分支向 Develop 分支合并的过程中：（图片来源：ProcessOn 模板）2. 代码评审流程不同的颜色块，代表不同的角色创建一个 Merge Request 可以进行多次 Push开发人员推动整个代码评审流程的执行，包含及时通知组员评审代码、通知组长合并代码等3. 保护分支设置在 GitLab 打开要设置的工程 (Maintainers 角色)，选择 Setting -> Repository -> Protected Branches：将 master 和 develop 分支设置为保护分支，只能是 Maintainers 角色 可以合并请求，并且禁止直接 push 代码。
通过以上设置之后，所有代码只能通过创建 Merge Request 的方式合并到 develop 和 master 分支；为了代码库的安全，需要回收 Maintainers 权限，除组长外的开发人员都是 Developer 权限。
4. Merge Request1. 创建 Merge Request打开 Project -> Merge Requests -> New merge request，选择分支创建合并请求：选择源分支，需要合并的代码所在的分支选择目标分支，将最新代码合并到的分支2. 填写必要信息Title：简单总结本次 Merge 的修改点Description：详细描述修改内容，影响范围等Assignee：委托人，选择具有 Maintainers 角色的成员，该成员会收到合并请求的邮件通知，最后由该成员合并请求Approvers：一般选择小组成员，小组成员具有审核代码权限，对不合格代码可以要求开发者修改分支选择，功能分支向 develop 分支合并时，会有删除源分支选项，建议勾选针对本次合并的提交，一次合并请求可以包含多次提交3. 代码评审及合并请求只有评审成员评审通过时，合并按钮才会高亮，才能合并代码参与代码评审的成员，认为代码没有问题时，可点击该按钮针对当前代码创建的讨论，有讨论存在时，开发者需要及时解决如果代码有问题，可直接创建一个讨论，即 3 列表会增加，开发者修改之后可点击 5 关闭讨论代码修改之后，或者不需要修改，点击关闭讨论5. 其他注意事项1. 提交合并请求时，先同步最新代码提交合并代码前，建议先执行 git fetch 和 git merge/rebase 将 develop 分支下的最新代码更新到开发分支，再提交合并请求，避免造成冲突。
2. 合并代码到 master 分支通过 develop 分支提测且测试通过后，将 develop 分支的代码合并到 master 分支进行发版，版本发布完成时及时打标签。
四、Git 项目集成构建1. 简介GitLab-CIGitLab-CI 是 GitLab Continuous Integration（GitLab 持续集成）的简称。
只要在项目仓库的根目录添加 .gitlab-ci.yml 文件，并且配置了 Runner（运行器），那么每一次合并请求 MR 或者 push 都会触发 CI pipeline。
GitLab-RunnerGitLab-Runner 是 .gitlab-ci.yml 脚本的运行器，GitLab-Runner 是基于 GitLab-CI 的 API 进行构建的相互隔离的机器（或虚拟机）。
GitLab Runner 不需要和 GitLab 安装在同一台机器上，同时考虑到 GitLab Runner 的资源消耗问题和安全问题，也不建议这两者安装在同一台机器上。
PipelinesPipelines 是定义于 .gitlab-ci.yml 中的不同阶段的不同任务。
Pipelines 可理解为流水线，流水线包含有多个阶段（stages），每个阶段包含有一个或多个工序（jobs），比如先购料、组装、测试、包装再上线销售，每一次 push 或者 MR 都要经过流水线之后才可以合格出厂。
而 .gitlab-ci.yml 正是定义了这条流水线有哪些阶段，每个阶段要做什么事。
2. GitLab-CI 功能配置GitLab-Runner 安装（macOS）Install and start gitlab-runner：brew install gitlab-runnerbrew services start gitlab-runnerRegister gitlab-runner：gitlab-runner register配置以下参数：Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com ):Please enter the gitlab-ci token for this runner:Please enter the gitlab-ci description for this runner:Please enter the gitlab-ci tags for this runner (comma separated):Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:具体配置项的值可参考项目信息（Project -> Settings -> CI/CD -> Runners）：右侧是创建好的 Runners；对于多项目可以创建 Shared/Group Runners，多个项目可以共享，不用一一创建；不同 Runners 的创建，仅仅是 Token 不同。
添加构建任务在根目录中创建 .gitlab-ci.yml 文件，具体代码可参照以下示例。
Android 工程：stages: # 构建步骤 - buildbuild job: stage: build tags: # 根据tag，选择执行的runner - tag_0.0.1 only: # 只有在列出的分支合并代码时，才会触发构建 - develop script: # 构建执行的脚本，顺序执行 - chmod a+x gradlew - ./gradlew assembleDebug artifacts: # 构建后的产物 paths: - app_debug/iOS 工程文件配置类似，只是 script 脚本不同；.gitlab-ci.yml 具体语法，可参考以下官方文档：gitlab-ci 语法。
将代码 push 到远程分支或者合并请求时，就会自动执行脚本：点击列表，可看到单个 job 的执行情况，包括控制台日志输出和文件产出：3. GitLab + Jenkins 实现 CI 功能Jenkins 配置登录 Jenkins 账户，打开“系统管理” -> “插件管理” -> “可选插件”安装以下两个插件：打开“系统管理” -> “系统设置” -> “GitLab” 配置 GitLab 服务：在 Jenkins 首页，打开“项目”，“配置” -> “构建触发器”配置以下信息：打开“高级”，生成 Secret token，配置 GitLab 的时候，需要用到：GitLab 配置打开 Project -> Settings -> Integrattions 填写上一步生成的 URL 和 Secret Token 信息：配置完成，当 push 代码或者合并请求时，会自动触发 Jenkins 构建。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）