进公司不会用 Git 拉项目!第二天被开除?天!那还在等什么,快点进来看看

12,626 阅读10分钟

前言

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 false
git config --global core.autocrlf false

如果是 macOS 系统,则只需要执行:

git config --global core.autocrlf false

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

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

git config --global core.ignorecase 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 各分支示意图以及流程图:

96028705770516198.jpg

12943723466411170.jpg

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 clonegit pushgit addgit commitgit checkoutgit 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克隆到本地。

InkedQQ图片20210415110447_LI.jpg

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

  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到的小伙伴点赞支持支持,有哪些不足和欠缺的地方,欢迎评论区纠正!