Git安装与使用及一般规范

一、Git安装与使用

1. 安装

• windows

https://gitforwindows.org/

https://registry.npmmirror.com/binary.html?path=git-for-windows/

• mac

http://sourceforge.net/projects/git-osx-installer/

• 查看安装版本

$ git --version 

2. 设置个人信息

$ git config --global user.name "yourname"
$ git config --global user.email yourname@ddysq.com

3. Git常用命令

说明：

• workspace：工作区

程序员进行开发改动的地方，是你当前看到的，也是最新的。平常我们开发就是拷贝远程仓库中的一个分支，基于该分支进行开发。在开发过程中就是对工作区的操作。

• staging area：暂存区/缓存区

.git目录下的index文件, 暂存区会记录git add添加文件的相关信息(文件名、大小、timestamp…)，不保存文件实体, 通过id指向每个文件实体。可以使用git status查看暂存区的状态。暂存区标记了你当前工作区中，哪些内容是被git管理的。

当你完成某个需求或功能后需要提交到远程仓库，那么第一步就是通过git add先提交到暂存区，被git管理。

• local repository：版本库或本地仓库

保存了对象被提交过的各个版本，比起工作区和暂存区的内容，它要更旧一些。git commit后同步index的目录树到本地仓库，方便从下一步通过git push同步本地仓库与远程仓库的同步。

• remote repository：远程仓库

远程仓库的内容可能被分布在多个地点的处于协作关系的本地仓库修改，因此它可能与本地仓库同步，也可能不同步，但是它的内容是最旧的。

常用命令：**git clone**、**git push**、**git add** 、**git commit**、**git checkout**、**git pull**

• git init 初始化仓库
• git add 添加文件到暂存区
• git commit 将暂存区内容添加到本地仓库中
• git clone 拷贝一份远程仓库，也就是下载一个项目
• git pull 下载远程代码并合并
• git push 上传远程代码并合并
• git remote 远程仓库操作
• git fetch 从远程获取代码库
• git log 查看历史提交记录
• git blame 以列表形式查看指定文件的历史修改记录
• git rm 删除工作区文件
• git mv 移动或重命名工作区文件
• git status 查看仓库当前的状态，显示有变更的文件
• git diff 比较文件的不同，即暂存区和工作区的差异
• git reset 回退版本
• git branch 创建分支
• git checkout 切换分支
• git tag -a 创建tag

Tips: 一般我们都是使用客户端工具来操作git，比如source tree、idea等。但相关命令也是需要了解的。

4. GitLab使用

4.1 登录

https://git.ddysq.com

4.2 设置中文

Preferences` -> `Localization` -> `Language` -> `Chinese, Simplified

5. 设置ssh密钥

5.1 确认本地秘钥

SSH 秘钥默认储存在账户的主目录下的 ~/.ssh 目录 (也就是本地电脑C盘你的账户下)

5.2 生成秘钥信息

• 在.ssh目录下右键打开Git Bash(.ssh目录不存在，则在任一目录下操作，或者手动创建该目录)
• 生成秘钥：ssh-keygen -t rsa -C "your_email@ddysq.com" ，直接Enter就行，然后会提示输入密码(可输可不输)

**说明：**命令中的email，就是gitlab中的账号绑定的邮箱，需要保持一致

• 执行完成之后，在.ssh目录下就会生成秘钥文件（没有.ssh目录的会自动生成，手动创建的则不会重复生成）

在~/.ssh/下会生成两个文件，id_rsa和id_rsa.pub

id_rsa是私钥

id_rsa.pub是公钥

• gitlab添加秘钥

• • 访问登录gitLab，登录进去后搜索ssh，点击进入ssh密钥添加页面
  • 把id_rsa.pub中的信息输入到密钥输入框中，标题可以随便起，见名知意即可
  • 然后点击添加密钥即可

二、分支约定

Git是一个无中心的分布式版本控制系统，一个中心版本库(origin)需要包含两类分支：核心分支、辅助分支。

1. 核心分支

核心分支，主要为主分支和开发分支。

1.1 master

整个项目主分支，有且仅有一个，除项目负责人以外的开发人员不能向主分支合并内容，禁止Commit，确保任何时间获得的都是处于可发布状态的代码。每次分支合并后需要标记Tag。

1.2 develop

日常开发分支，总能够获得最新开发进展的代码。

2. 辅助分支

辅助分支，大体包括如下几类：

• 管理功能开发的分支；
• 帮助构建可发布代码的分支；
• 可以便捷的修复发布版本关键BUG的分支。

辅助分支的最大特点就是生命周期十分有限，完成使命后即可被清除。并且一半情况下只应该存在本地，不要提交到远程库。

2.1 feature branch

从develop分支上面拉取的分支，用于开发后续版本的功能。开发完成稳定后，通过Merge Request 合并到develop分支，并删除此分支。

2.2 hotfix branch

从master分支上面拉取的分支，用于修复重大bug。修复结束以后，再合并进master和develop或release分支，并删除此分支。

2.3 release branch

从develop分支上面拉取的分支，用于部署测试环境，此分支禁止push，禁止提交新功能，只能提交bug修改。测试通过后合并至master分支、develop分支，并删除此分支。

**Tips：**测试不应该参与到每个分支中来，只应该参与到release分支中去。其它的开发分支，都应该由开发人员自己测试，测试没有问题的时候，通过Merge Request合并到develop，这就要求每一个开发要提高自己交付的产品质量。

三、使用流程

Git Flow是目前比较主流的git工作流，采用功能驱动式开发（Feature-driven development，简称FDD）。它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。

Tips: 合并到上游分支的功能必须相对独立而且是可用的。

1. 创建新项目

提交代码初始版本到master分支，并推送至GitLab系统，设置为Protectd分支。

• 本地创建项目
• 项目初始化Git
• 在GitLab中创建项目
• 关联远程仓库
• 添加暂存区文件
• 提交文件
• 推送到GitLab

# 初始化git
git init

# 关联远程仓库
git remote add origin git@git.ddysq.com:test-group/gitflow.git

# 添加暂存区文件
git add .

# 提交文件
git commit -m "Initial commit"

# 推送到gitlab
git push -u origin master

2. 进行项目开发

在master分支上创建develop分支，并推送至GitLab系统，设置为Protectd分支。

• develop分支与master分支一样，有且仅有一个；
• 对于非并行项目可以使用develop分支开发方式；
• 对于多人并行开发项目，使用feature分支开发方式。

# 在master分支上创建develop 分支
git checkout -b develop master

Tips: develop和feature开发方式不应同时使用。

3. 开发新特性

每个新需求或新的功能创建一个feature分支，feature分支的生命周期不能跨一次迭代。

# 在develop分支上创建feature分支
git checkout -b feature/user_login develop

git checkout -b feature/user_logout develop

4. 完成功能开发

新功能开发完成后，在GitLab中发起Merge Request，请求合并 feature分支到develop分支上。

• 相关负责人Code Review后，如果同意合并后，删除远程 feature 分支；
• 如果不同意，重新修改后再上传 feature 分支，重新发起Merge Request。

Tips: 禁止直接Merge或Push，到develop或master分支。当然，研发人员也没有权限。

5. Merge Request

通过Merge Request来做Code Review。

6. 发布测试环境

新功能代码通过Merge Request合并到develop中后，在develop分支上创建预发布分支release/*，交付测试环境。

# 创建release分支
git checkout -b release/user_login develop

7. 修复待发布版本中的BUG

如果有Bug直接在release分支上面进行修改。

Tips: 如遇到“致命”BUG，可在release修复后，及时合并回develop分支。

8. 发布正式环境

经过若干Bug修复后，release branches上的代码已经达到可发布状态，此时可将release分支代码合并回master分支后，基于master分支构建镜像。

• release 合并回 develop；
• release 合并到 master；
• 为master 打 Tag，作为版本里程碑；
• 删除release分支。

# release 合并回 develop
git checkout develop
git merge release/user_login
git push

# release 合并到master
git checkout master
git merge release/user_login
git push

# 删除release分支
git branch -d release/user_login

Tips: Tag建议在GitLab上进行创建，填写清楚标签名称及发行说明。

9. 修复线上BUG

发布正式环境后，用户体验发现有未知Bug。此时从master分支上拉出了hotfix/*分支，提交修改以解决问题。使用hotfix/*分支在测试环境重新验证，验证通过后发布正式环境。

• hotfix/* 合并回 develop；
• hotfix/* 合并回 master；
• 为master 打 Tag，作为版本里程碑；
• 删除hotfix/*分支。

# hotfix 合并到master
git checkout master
git merge hotfix/user_login
git push

# hotfix 合并回 develop
git checkout develop
git merge hotfix/user_login
git push

# 删除release分支
git branch -d hotfix/user_login

四、使用注意事项

• 所有在master分支上的Commit应该打上Tag，一般情况下master不存在Commit，develop分支基于master分支创建；
• 代码提交前，必须进行git pull，且进行git diff进行比对代码，确保提交代码为自己修改内容，防止出现代码回溯；
• Release branch产生新提交的最好时机是develop分支已经基本到达预期的状态，至少希望新功能已经完全从Feature branches合并到develop分支了。

五、GitLab使用规范

1. 基本要求

• 所有Commit必须有注释，内容必须按照注释格式严格执行；
• 合理控制提交内容的颗粒度完成一个功能进行一次Commit提交，严禁一次提交涵盖多个功能；
• 正确为每个项目设置Git提交用到的user.name和user.email信息。

2. 命名规范

2.1 tag

• 规则：tag/${版本名称}-${发布版本}
• 示例：tag/user_login-V1.0.0

2.2 feature

• 规则：feature/${版本名称}
• 示例：feature/user_login

2.3 release

• 规则：release/${版本名称}
• 示例：release/user_login

2.4 hotfix

• 规则：hotfix/${版本名称}
• 示例：hotfix/luser_login

3. 提交规范

良好的Commit提供更多的历史信息，方便快速浏览，不仅可以过滤某些Commit（比如文档改动），便于快速查找信息，还可以直接从Commit生成Change Log。

<type>[<scope>]: <subject>  //本行内容git在push到中央仓库时会被校验
//空行
[<body>]
//空行
[<work_item_id>]

• type表示提交类别

type在Commit中是必须存在的，用于说明 Commit 的类别。

• • feat：新功能(feature)
• • fix：修复 bug
  • docs：文档(documents)
  • style： 代码格式(不影响代码运行的格式变动，注意不是指 CSS 的修改)
  • refactor：重构(既不是新增功能，也不是修改 bug 的代码变动)
  • test：提交测试代码(单元测试，集成测试等)
  • chore：构建或辅助工具的变动
  • misc：一些未归类或不知道将它归类到什么方面的提交
  • revert：回滚到上一个版本

• scope表示修改范围

scope用于说明 Commit影响的范围（非必填）。建议填写建议填写影响的功能模块，如果你的修改影响了不止一个scope，你可以使用*代替。

• subject表示标题行

Commit 目的的简短描述，不超过50个字符（必填）。以动词开头，使用第一人称现在时，比如change，而不是changed或changes。

• body表示主体描述内容

可描述当前修改的行为详细信息或修改的目的，可分多行。

既不是新增功能，也不是修改 bug 的代码变动)

• test：提交测试代码(单元测试，集成测试等)

• chore：构建或辅助工具的变动

• misc：一些未归类或不知道将它归类到什么方面的提交

• revert：回滚到上一个版本

• scope表示修改范围

scope用于说明 Commit影响的范围（非必填）。建议填写建议填写影响的功能模块，如果你的修改影响了不止一个scope，你可以使用*代替。

• subject表示标题行

Commit 目的的简短描述，不超过50个字符（必填）。以动词开头，使用第一人称现在时，比如change，而不是changed或changes。

• body表示主体描述内容

可描述当前修改的行为详细信息或修改的目的，可分多行。