前言

hello 大家好！本人前段时间在某站看了个歪嘴战神的视频，视频中提到一包装三年工作经验的程序员，因进公司第一天不会使用 git 拉项目，第二天被开除。想想挺可怕的，学完这篇文章，我相信你会 get 到很多。好了，话不多说，come on！

正片

先介绍一下 git 是什么？

1. Git 是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。

2. Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

1 基本配置

1.1 用户信息

开发人员的用户信息请使用中文拼音全拼写法，比如“Zhang San”、“Li Si”这样的，注意姓和名首字母大写，中间留一空格，电子邮件地址统一填写公司邮箱，比如“zhangsan@company.cn”。 命令行如下：

git config --global user.email "邮箱"git config --global user.name "用户信息"

1.2 环境配置

Windows 由于权限系统和 macOS 有差异，换行也有所不同，所以对于 Windows 平台使用 Git 需要进行下列配置：

git config --global core.filemode falsegit config --global core.autocrlf false

如果是 macOS 系统，则只需要执行：

git config --global core.autocrlf false

修改完成后可以通过 git config --global -l 查看是否改动成功，请注意一下。

在项目开发中，如果改变了文件或文件夹名称的大小写，默认情况下 git 是无法检测到的，请各位执行以下命令关闭大小写忽略。

git config --global core.ignorecae false

2 关于 Git 分支

分支功能是 git 最为强大的功能之一，它能够让你并发地在多个场景下进行开发。并且可以让你同时开发不同功能而不冲突，用于区分功能或版本

长期分支：

master：主分支 可发布的稳定版分支，存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的发布版本

develop：开发分支用于日常开发，存放最新的开发版

公共的开发主线分支，feature 功能分支的代码开发完成后，经过 code review 后会合并到此分支

临时分支：一旦完成开发，它们就会被合并进 develop 或 master，然后被删除。

feature branch：功能分支 一般是从 develop 开发分支上检出(checkout)

hotfix branch：补丁分支 紧急修复，一般是用于修复上线后的生产环境的问题

release branch：预发分支 测试、发布主线，此分支是从 develop 分支上检出(checkout), 一般是提测阶段会使用该分支的代码

2.1 主分支和开发分支

主分支命名为 master，有且只有一个分支，所有正式版本都必须从 master 分支发布，并且又相关发布的 Tag，master 分支只能从其它分支合并，不能在这个分支上修改，禁止直接向 master 分支 Push 代码；

日常开发分支命名为 develop，有且只有一个分支，原则上并行开发的时候，develop 分支承担改动最大的方向，比如进行大规模的代码重构、界面框架替换、大版本升级或者日常常规迭代升级等等。

2.2 临时分支之功能分支

对于较大的功能版本升级，划分不同的功能分支 feature 进行管理，一方面便于功能测试，另外一方面便于需求变更对应的代码变更调整。【当前仅使用在本地分支，不要上传到服务器，减少代码冲突带来的工作量】

命名为 feature-*，后面的命名可以是小版本号，或者功能，或者较大任务的 Jira ID 号，feature-{$build_version_id}，或者是 feature-{$JiraID}，或是有命名意义的功能 feature-{$featureName}如：feature-logedit，从 develop 分支拉出来处理。

处理完成后，代码合并回 develop 分支一起提交服务器，合并后删除该临时分支。

2.3 临时分支之补丁分支

对于正在主线上处理，但是需要临时支援另外一个 bug 或者是另外事件触发，可以单独发布该分支。

命名为 hotfix-*，命名可以是临时处理的事件标识或者 JiraID，如：hotfix-{$JiraID}、hotfix-{$eventName}，需要从 master 分支拉出一个补丁分支临时修改。

修改完后合并到 release 分支预发布以及 master 分支发布，合并完后删除该临时分支。

2.4 临时分支之预发布分支

对于发布的版本，需要发布到预发布环境进行验收，按版本号进行标识。

命名为 release-*，命名需要根据版本，比如 release-{$version_id}，或者是临时发布的版本 release-{$version_id}-{$jiraID/eventName}，需要从其它分支（develop 或 hotfix）合并过来。

预发布后再进行 master 合并。

2.5 同一个代码仓库多个开发分支

对于多个服务共享一个代码仓库的情况，开发过程需要按服务分别拉分支开发，严禁都提交到 Develop 分支。

命名为“服务标识-dev”，当作 Develop 开发分支处理，最后发布页需要合并到 master 分支。

2.6 各分支示意图以及流程图：

3 代码提交

做完一件事情即可提交代码，提交的备注文字尽量准确、简洁，不要同时提交多件事情的代码。

提交 commit 的注释文字，需要简单扼要，且充分考虑影响范围，不要遗漏提交功能实现的描述。

Commit 注释规范，不同情形下区别：

以下是简书上抄下来的，咱们重新规范下，按中文命名更容易记住：

• feat【新增】: Feature 的缩写, 新的功能或特性

• fix【bug 修复】: bug 的修复

• docs【文档】: 文件修改, 比如修改应用了 ngDoc 的项目的 ngDoc 内容

• style【界面】: 格式修改. 比如改变缩进, 空格, 删除多余的空行, 补上漏掉的分号. 总之, 就是不影响代码含义和功能的修改

• refractor【重构】: 代码重构. 一些不算修复 bug 也没有加入新功能的代码修改

• perf【优化】: Performance 的缩写, 提升代码性能

• test【测试】: 测试文件的修改

• chore【其它】: 其他的小改动. 一般为仅仅一两行的改动, 或者连续几次提交的小改动属于这种

如果有版本号，可增加版本号标识，整体更整洁 commit 模板 ps: 首字母小写，并且结尾不加句号, 使用半角(英文)符号

git commit -m '<type>(<scope>): <subject> [<issue_id>]'
git commit -m '新增(影响全局select组件UI样式): 更改了select组件动画效果 [issue-123]'

1. type: 分支行为

2. scope: 说明 commit 影响的范围，比如数据层，控制层，视图层等等，这个需要视具体场景与项目的不同而灵活变动

3. subject: 对于该 commit 目的的简短描述

4. issue_id: 如果你的改动是针对 git 中的 issue 进行，请将 issue_id 添加到 commit 记录中

3.1 .gitignore 文件

这个文件会配置忽略文件列表，请尽量放在工程的根目录下，除了无需提交的临时文件、编译输出等数据之外，本地用户相关的一些配置也可以加入忽略列表。

3.2 每日构建

每日构建服务器一般会基于 release 分支进行，如果确定版本可以发布后，代码会 merge 到 master 以及 develop 分支，然后通过 master 分支构建发布版本。

日常开发中也可以考虑开启 develop 分支的每日构建，但原则上同一时间段只允许开启一个分支的每日构建。

4 代码发布

4.1 申请 master 分支合并：

从 gitlab 中可直接申请 master 合并，并由仓库管理员负责合并；

4.2 申请版本发布：

在发布前的测试环境上，从对应的开发分支进行测试环境构建，至于测试环境规划，另外篇章说明。【开发联调与测试并行时候，需要考虑环境区分】

5 Git 仓库命名规范

项目名称请用大写，空间是部门命名，默认是 CPStudio。

分类：

默认系统入口代码，都以系统缩写命名，比如 CPStudio/EKP

前后端分离的 api，以系统加_api 命名，比如 CPStudio/EKP_API

后端定时任务系统，以系统缩写加_task，比如 CPStudio/EKP_TASK

其它类别的子系统，以下划线加有子系统含义的缩写字母，比如 CPStudio/EKP_RES，代表了 EKP 系统的模板库资源。

6 便于 code review 的合作流程

在编写代码的时候，为了代码的高质量与开发人员的知识共享，通常会加上代码审查也就是 code review 环节。这个环节是借助 merge request 或者 pull request 来做到的，所以我们提交的 commit 记录应该尽量保持为一个，这样的好处有很多：

方便代码审核者进行 code review，只需要看这一个 commit 记录的逻辑即可, 万一该 commit 的代码导致出现问题，我们可以只针对这个 commit 进行快速回退。 一个功能保持一个 commit 记录如果遇到需要对这个功能提前提交到某些环境比如生产环境上，我们可以快速用过 cherry-pick 命令，在对应的分支上"重现"该提交记录，达到提前提交的目的。

也许你会有疑问，单个功能保持一个 commit 记录与 commit 提交记录尽量保持较细的粒度这一原则是否相悖，笔者觉得并没有冲突，因为这两个 git 协作要求是基于不同的角度来看待问题的，对于自己开发的分支上，我们需要保持每个提交的粒度在一个 commit 做一个修改，这样有利于我们记录工作内容与方便自己在本分支上做回滚，但是对于一个软件开发的主分支来说，它上面的提交应该是以功能为单位的，而无需关心这个功能内开发人员开发这个功能做了多少次修改。

面对这种情况，我们会使用 rebase 命令，也就是衍合(变基)操作。所谓衍合就是将你此分支上的 commit 提交，按顺序重新在某个分支上的某个基础点重新"演绎"一次，而这个重新"演绎"重新提交的 commit 记录与原来的 commit 提交会有些许不同，不同点在于 commit 的 HashId 会不同，但是提交内容是一样的。

rebase 命令提供了交互式的界面，并且提供多种的命令让你能够将多个 commit 记录合并为一个，从而达到我们单一功能保持一个 commit 记录的目的，保持提交历史的清爽。

7 git 命令

Git 常用的是以下 6 个命令：git clone、git push、git add 、git commit、git checkout、git pull，当然还有很多命令，可以去官网查

• git clone：拷贝一份远程仓库，也就是下载一个项目。

• git push origin master：将文件给推到服务器上

• git add .：添加当前目录的所有文件到暂存区

• git commit -m "提交文件信息"：提交暂存区到仓库区

• git checkout [branch name]：切换到指定分支，并更新工作区

• git pull：本地与服务器端同步

8 SSH 与 HTTPS 的区别

最后咱们回归主题，对于 clone 项目，在管理 Git 项目上，很多时候都是直接使用 https url 克隆到本地，当然也有有些人使用 SSH url 克隆到本地。

​

这两种方式的主要区别在于：

1.      使用 https url 克隆对初学者来说会比较方便，复制 https url 然后到 git Bash 里面直接用 clone 命令克隆到本地就好了，但是每次 fetch 和 push 代码都需要输入账号和密码，这也是 https 方式的麻烦之处。

2.      而使用 SSH url 克隆却需要在克隆之前先配置和添加好 SSH key，因此，如果你想要使用 SSH url 克隆的话，你必须是这个项目的拥有者。否则你是无法添加 SSH key 的，另外 ssh 默认是每次 fetch 和 push 代码都不需要输入账号和密码，如果你想要每次都输入账号密码才能进行 fetch 和 push 也可以另外进行设置。

相关的文章 Git 的官方站点，最新版本都可以从这里下载：git-scm.com/Pro Git，一本全面介绍 Git 的图书，非常详细。Git Magic，很通俗的一本介绍 Git 的书，比较短小精炼。

今天就到这里啦，get 到的小伙伴点赞支持支持，有哪些不足和欠缺的地方，欢迎评论区纠正！