Git/GitHub-学习记录

一、Git 概述

1.1 Git 介绍

Git 是一个开源的分布式版本控制系统(Distributed Version Control System，简称 DVCS)。可以有效、高速地处理从很小到非常大的项目版本管理。

---

1.2 Git 的特点

• 快速、简单的设计
• 对非线性开发模式的强力支持（允许成千上万并行开发的分支）
• 完全分布式
• 有能力高效管理类似 Linx 内核一样的超大规模项目（速度和数据量）
• 协同开发

---

二、GitHub 概述

2.1 GitHub 介绍

• GitHub 是为开发者提供 Git 仓库的托管服务
• 这是一个让开发者与朋友、同事、同学及陌生人共享代码的完美场所

---

2.2 GitHub 与 Git 区别

• Git 和 GitHub 是两个完全不同的概念!
• Git 是一个版本管理工具，开发者将源代码存入名叫“Git 仓库”的资料库中并加以使用，由 Linus Torvalds 编写。
• GitHub 是在线的基于 Git 的代码托管服务,2008 年由 Ruby on Rails 编写而成。
• GitHub 除提供 Git 仓库的托管服务外，还为开发者或团队提供了一系列功能，帮助其高效率、高品质地进行代码编写。

---

三、相关概念

3.1 Git 仓库基础概念

1. 工作区：存放代码的地方
2. 暂存区：临时存储，将工作区的代码让 git 知道，通过 git add 将代码放到暂存区
3. 本地库：将暂存区的代码提交到本地库，就会生成对应的历史版本，这个代码就无法删除
4. 远程库：将本地库的代码推送到远程库

---

3.2 origin

你的代码库(repository)可以存放在你的电脑里，同时你也可以把代码库托管到 Github 的服务器上。在默认情况下，origin 指向的就是你本地的代码库托管在 Github 上的版本

假设 user1 首先在 GitHub 上创建了一个 Repository，叫做 repository，GitHub ID 是 user1,这个时候指向代码库的链接是:
https://github.com/user1/repository
如果在 terminal 里输入：
git clone https://github.com/user1/repository
那么 Git 就会克隆一份托管在 GitHub 上的代码库至本地，这时，本地仓库和远程仓库建立连接，这个时候你 cd 到 repository 目录，可以查看映射关系：
$ git remote -v
结果如下：

`origin` https://github.com/user1/repository.git (fetch)
`origin` https://github.com/user1/repository.git (push)

总结：git 默认创建了一个指向远端代码库的标识 origin，没有特殊意义，只是一个默认的习惯，比如叫 zhangSan 也可以

---

3.3 master

1. master 概念

• 在初始化本地 Git 仓库时，Git 已经默认帮我们创建了一个名字叫 master 主分支，通常我们把这个 master 分支叫做主分支
• master 主分支的作用是：用来保存和记录整个项目已经完成的功能代码

2. master、origin master 与 origin/master 的区别

• master 这个很好理解，它代表本地的某个分支名，通常叫做主分支
• origin master 代表着两个概念，前面的 origin 代表远程名，后面的 master 代表远程分支名
• origin/master 只代表一个概念，即远程分支名，是从远程拉取代码后在本地建立的一份拷贝（因此也有人把它叫作本地分支）

以下例子更好说明区别：

• 执行 git fetch origin master 时，它的意思是从名为 origin 的远程上拉取名为 master 的分支到本地分支 origin/master 中。既然是拉取代码，当然需要同时指定远程名与分支名，所以分开写。

• 执行 git merge origin/master 时，它的意思是合并名为 origin/master 的分支到当前所在分支。既然是分支的合并，当然就与远程名没有直接的关系，所以没有出现远程名。需要指定的是被合并的分支。

• 执行 git push origin master 时，它的意思是推送本地的 master 分支到远程 origin，涉及到远程以及分支，当然也得分开写了

---

3.4 branch

1.Git 的分支是什么

• 顾名思义，分支就是从主线上分离出来进行另外的操作，而又不影响主线，主线又可以继续干它的事，是不是有点像线程，最后分支做完事后合并到主线上而分支的任务完成可以删掉了。这样是不是很方便，主线继续做它的事，分支用来解决临时需求，二者互不相干。
• git 的分支功能特别的强大，它不需要将所有数据进行复制，只要重新创建一个分支的指针指向你需要从哪里开始创建分支的提交对象(commit)，然后进行修改再提交，那么新分支的指针就会指向你最新提交的这个 commit 对象，而原来分支的指针则指向你原来开发的位置，当你在哪个分支开发，HEAD 就指向那个分支的最新提交对象 commt。没弄清楚没关系，先有这么一个概念，后面慢慢就会弄清的。

2.分支的新建与合并

• 我们可以用命令 git branch 来查看我们的 git 仓库有几个分支，而我们目前工作处于那个分支，前面有个*号的就为我们目前所处的分支。
• 我们可以通过命令 git branch name 来创建分支，而这个分支的指针就指向最新的 commit 对象，也就和 HEAD 指向同一对象。
• 我们可以通过命令 git checkout name 来切换到目的分支，我们默认的主分支为 master。在分支的创建和切换，其实只是简单的创建指针找指针而已，而根据找到的指针找到所指向的 commit 对象，然后将工作空间恢复成该 commit 对象所指的文件快照让我们来工作

3.本地分支，远程分支和追踪分支

• local branch
  本地分支就是我们可以通过 git branch 查看到的分支，也就是我们自己 git 仓库所拥有的分支，git 中默认是 master 分支,我们都可以利用

• remote branch
  远程分支是对远程仓库的分支的索引，它其实也是本地分支，只是我们无法移动它，必须要在和中心服务器交互根据服务器更新到本地来的代码移动的，远程分支的作用就是我们上次和中心服务器交互更新得到的最新版本，它也是个指针。

• tracking branch
  追踪分支比较难理解，它也是一个本地分支，只是它对应了一个远程分支，如果我们本地的某个分支对应了一个特定的远程分支，那么它就是追踪分支，比如我们最初的 master 分支就是一个追踪分支，它对应远程分支 origin/master，这里 origin 是远程仓库名，当我们在 master 分支里执行更新(fetch，pull)或是推送(push)，在不指定分支的情况下，默认就是从 origin/master 分支更新来或者提交到 origin/mster 分支

---

3.5 branch types

分支类型	Branch Types
master branch	主分支
feature branch	功能分支
dev branch	开发分支
hot-fix branch	紧急修复分支

1. master 主分支

• master 主分支的作用是:用来保存和记录整个项目已完成的功能代码
• 不允许程序员直接在 master 分支上修改代码，因为这样做的风险高，容易导致整个项目崩溃，因此我们需要在自己负责开发的分支上进行开发

2. feature 功能分支

• 由于程序员不能直接在 master 分支上进行功能的开发，所以就有了功能分支的概念
• 功能分支指的是专门用来开发新功能的分支，它是临时从 master 主分支上分叉出来的，当新功能开发且测试完毕后，最终需要合并到 master 主分支上

3. dev 开发分支

dev 分支是开发分支，用于存储正在开发过程中的代码。开发人员在 dev 分支上进行新功能的开发、bug 修复等操作。

4. hot-fix 紧急修复分支

解决问题，修复 bug 的分支，解决之后合并到主分支上

---

3.6 commit

commit 就是把本地变化提交到本地仓库

---

3.7 commit message types

我们在每次提交代码时，都需要编写 Commit Message，否则是不允许提交的。书写好的 Commit Message 能大大提高代码维护的效率。避免开发人员在项目中群魔乱舞，搞得代码一团糟，搞的项目就被糟践了。且开发日后的维护，都将是灾难。

因此，编写 Commit Message 需要遵循一定的范式，内容应该清晰明了，指明本次提交的目的，便于追踪问题。往往在日常开发中由于缺少对 Commit Message 的约束，导致填写内容随意，可读性低亦难以维护

1.规范

Commit Message 的格式大致分为三个部分 (使用空行分割):

• 标题行 Header：必填，描述主要修改类型和内容
• 主题内容 Body：描述为什么修改，做了什么样的修改，以及开发的思路等等
• 页脚注释 Footer：说明 Breaking Changes（中断更改） 或 Closed Issues（已解决的问题）

Commit Message 提示说明：

 标题行 类型（影响范围）：50个字符以内，描述主要变更内容
 空一行
 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
 他如何解决这个问题? 具体描述解决问题的步骤
 是否存在副作用、是否会有风险?
 空一行
 尾部：是需要的化可以添加一个链接到issue地址或者其它文档，或者是关闭了某个issue。

2.格式拆解 Header

Header 部分只有一行，包括三个字段：type（必需）、scope（可选）和 subject（必需）

• type：

type	描述
feat	新增 feature(功能)
fix	修复 bug
docs	仅仅修改了文档，比如 README，CHANGELOG，CONTRIBUTE 等
style	修改了空格、格式缩进、逗号等，不改变代码逻辑
refactor	代码重构，没有加新功能或者修复 bug
perf	优化相关，比如提升性能、体验
test	测试用例，包括单元用例、集成测试等
chore	改变构建流程、或者增加依赖库、工具等
revert	回滚到上一个版本

• scop：
  scope 为选填项，用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同，格式为项目名/模块名。

如果你的修改影响了不止一个 scope，你可以使用*代替。

例如：global、common、http、* 、数据库等等，记得加上括号

• subject：
  subject 是 commit 目的的简短描述，不超过 50 个字符

示例：

feat(*): 添加网站主页静态页面

3. 格式拆解 Body

Body 填写详细描述，主要描述改动之前的情况及为什么修改，对于小的修改不作要求，但是重大需求、更新等必须添加 body 来作说,可以分成多行进行详细说明。

填写要求：

• 要以动词开头，使用第一人称现在时，比如 change，而不是 changed 或 changes
• 第一个字母小写
• 结尾不加句号

4. 格式拆解 Footer

• 不兼容变动(break changes)

  break changes 指明是否产生了破坏性修改，涉及 break changes 的改动必须指明该项，类似版本升级、接口参数减少、接口删除、迁移等。

• 关闭 Issue(affect issues)

  affect issues 指明是否影响了某个问题。例如使用项目管理系统的唯一 ID，在 commit message 中可以填写影响的 jira_id，若要开启该功能需要先打通 jira 与 gitlab。

---

3.8 push

push 用于将本地分支的更新，推送到远程主机

---

3.9 pull

将远程代码仓库中(新)的内容下载到本地，并更新本地代码仓库的内容

---

3.10 merge

merge 一般有以下两种用途：

• 用于整合另一代码仓库中的变化
• 用于从一个分支到另一个分支的合并

---

四、总结

记录自己的学习过程，温故知新
a_id，若要开启该功能需要先打通 jira 与 gitlab。

---

3.8 push

push 用于将本地分支的更新，推送到远程主机

---

3.9 pull

将远程代码仓库中(新)的内容下载到本地，并更新本地代码仓库的内容

---

3.10 merge

merge 一般有以下两种用途：

• 用于整合另一代码仓库中的变化
• 用于从一个分支到另一个分支的合并

---

四、总结

记录自己的学习过程，温故知新