git使用开发流程（公司新人git使用教程）
一、分支管理规范1. Git Flow 模型(图片来源：A successful Git branching model)2. Git Flow 分支说明Master发版分支 + 保护分支。功能代码在 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 类型，修改的类型级别：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://gitla网站站点" rel="nofollow" />