进公司不会用 Git 拉项目！第二天被开除？_程序员入职拉代码是克隆吗

前言

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

1.2 环境配置

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

git config --global core.filemode false
git config --global core.autocrlf false
1
2

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

git config --global core.autocrlf false
1

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

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

git config --global core.ignorecae false
1

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-{[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-gusCo6j6-1620444544764)(https://math.jianshu.com/math?formula=build_version_id%7D%EF%BC%8C%E6%88%96%E8%80%85%E6%98%AFfeature-%7B)]JiraID}，或是有命名意义的功能feature-{$featureName}如：feature-logedit，从develop分支拉出来处理。

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

2.3 临时分支之补丁分支

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

命名为hotfix-*，命名可以是临时处理的事件标识或者JiraID，如：hotfix-{[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PX8rCXdN-1620444544766)(https://math.jianshu.com/math?formula=JiraID%7D%E3%80%81hotfix-%7B)]eventName}，需要从master分支拉出一个补丁分支临时修改。

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

2.4 临时分支之预发布分支

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

命名为release-*，命名需要根据版本，比如release-{[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-G2XIZ3Jm-1620444544768)(https://math.jianshu.com/math?formula=version_id%7D%EF%BC%8C%E6%88%96%E8%80%85%E6%98%AF%E4%B8%B4%E6%97%B6%E5%8F%91%E5%B8%83%E7%9A%84%E7%89%88%E6%9C%ACrelease-%7B)]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
2
3

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 的书，比较短小精炼。

作者：Java斗帝之路
链接：https://www.jianshu.com/p/fd485dbea86a
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。