## 参考资料

###### https://www.bilibili.com/video/BV1BE411g7SV?from=search&seid=18079811304776446653&spm_id_from=333.337.0.0

###### https://www.jianshu.com/p/4079284dd970

###### https://blog.csdn.net/u010312474/article/details/107915694

## 为什么要使用git工具

在毕业写论文时，从新建word到最终提交的最终版，在老师的要求和查重改进的过程中，要修改无数版本。

如果把论文换成代码工程，你的代码前一秒可能还0 err, 0 warning，下一秒就make failed了，经过无数次Ctrl+Z和Ctrl+Y还是救不回来。

版本控制的作用之一，就是解决这些问题的，它可以管理不同的版本，并随时回退到任意版本。

第二个作用就是协同开发。当三个人同时编写电赛项目代码时，有人负责写移植驱动，有人负责算法，有人负责控制逻辑，但最终进行编译的代码一定是一个工程，而不是三个工程。三人的开发没有交叉还好，如过有两人或多人对同一个文件进行修改，还需要进行对比整合，那工作量就太大了。如果是十个人一起开发呢？

## 使用git管理代码

### 如何将代码clone到本地

- 进入仓库服务器
  - http://10.10.0.49:8080/

- 登录
  - 
- 获取仓库地址
  - Project-List-INP_xxx
  - 一般使用ssh，复制git clone指令
    - 
- 本地Clone
  - 右键->Git Bash Here
  - 粘贴指令，并运行
    - 

### 如何操作git

##### git status

- 查看仓库当前状态信息
- 红色表示工作区变动文件
- 绿色表示暂存区文件

##### git log

- 查看仓库历史记录日志

##### git add _filename_

- 将文件加入暂存区进行追踪
- git add后再执行git status，会发现文件已经变成绿色

##### git add .

- 将所有的未追踪邮件加入缓存区
- git add _filename_ 和 git add . 不止在文件新建时起到追踪文件的作用，还可在已被追踪的文件修改时将变更内容覆盖进缓存区

##### git commit -m _message_

- 提交变更，-m参数是指message的意思
- 此操作会将暂存区的文件提交到本地仓库进行版本追踪
- git commit后，执行git log指令，会发现此次commit的内容出现在了log中
- 每次commit都会生成一个唯一的hash值，用来绑定此次commit，可理解为commit的身份证

##### 再次更改文件后需要做哪些操作

- 修改文件内容后，执行git status命令，发现此文件又会变成红色，说明更改被记录到了本地工作区
- 想保存此次更改，需要做的操作如下:
  - git add _fileName_将更改保存到暂存区(使文件名变绿) -> git commit 将此次变更提交到本地仓库进行版本追踪
  - 若有两个文件被修改，只git add了一个文件，此时git commit只会提交add 过的文件
    - 即git commit只会提交暂存区(变绿的)文件
  - 若commit后发现有遗漏，修改后git add，想重复使用上一次的commit内容而不新增，可以使用 git commit –-amend，这样暂存区的文件会被提交到本地仓库，并且沿用上一次commit的log，相当于commit了两次，但只留下了一条log
  - git commit –-amend还可用于修改commit log内容，例如修改错别字...(使用vim操作)

##### git reset _filename_

- 在commit前将暂存区的文件退回工作区，即将绿色的文件变回红色

##### 文件的状态

- 
- 可以反向考虑
  - commit前，需要保证所有的文件进入Staged状态
  - 在进入Staged之前的文件是从哪来的？
    - 新建的文件，即从未被追踪的Untracked新加来的(git add _fileName_)
    - 如果该文件有过commit记录，那commit之前，它是Modified
    - 当commit之后，所有文件会变成Unmodified
      - 两者之间有差异，称为“变更”。git中的“变更”，是指已commit的文件内容和现有的文件之间的对比，对"变更"的内容再次commit，差异就消失了
      - git是对比仓库里的文件和现有文件之间的差异，如果是一致的，则认为是Unmodified，简单来说，只要提交了文件，就是Unmodified

##### git reset _commitID_

- 
- 如果想将文件内容回退到loop.liu提交的那次commit版本
  - 找到当时的commit ID，通过 git commit 8bce42f21a8d9757a40f20b6fb1121df80180c75，即可将现有文件恢复到当时提交时的文件状态(指文件内容)
- reset到loop.liu提交的版本后，又想回到最新的aurel.guo提交的版本，该怎么做？
  - 此时通过git log查看日志已经没有了aurel.guo提交的信息了，此时可以通过git reflog查看所有的操作记录，其中就包括回退掉的_commitID_，再使用git reset _commitID_即可
- git reset _commitID_ --_mode_ 参数
  - git reset _commitID_ --hard
    - 简单粗暴，文件恢复到_commitID_版本，并丢弃所有变更(物理意义上的永久删除)
  - git reset _commitID_ 或 git reset _commitID_ --mixed
    - 不加_mode_参数时，默认为此。
    - 文件恢复到_commitID_版本，且保留变更内容，使其处于Modified状态
    - 即 将文件变更内容放回到工作区
  - git reset _commitID_ --soft
    - 文件恢复到_commitID_版本，且保留变更内容，使其处于Staged状态
    - 简单来说，git reset _commitID_ --soft = git reset _commitID_ --mixed + git add .
    - 即 将文件变更放到暂存区

##### git checkout -b _name_ _template_

- 创建新分支，可以用来修改自己的代码，而不用来回reset变更版本
- _name_是新分支的名字；_template_是指以哪个分支或者commit为模板，缺省时则默认以当前分支为模板
  - 
- 注意，从原分支切出新分支时，新分支与原分支所有文件状态保持一致；切出后，两个分支所做的改动与对方再也没有任何关系了。
- 进行新的代码开发和修改验证，可以在新分支上进行修改，即使新分支上出现了错误，也不影响原分支(master)
- 如果想回退到某个版本，可以使用新建分支的方法 git checkout -b _branchName_ _commitID_
- 假设模板是远程仓库中的分支，需要在_template_之前加上origin声明是远程仓库，git checkout -b _branchName_ origin _template_ 

##### git branch

- 查看所有分支

  - ```shell
    $ git branch
    * loop
      master
    ```

  - 带*的为当前所在的分支

##### git merge _branchName_

- 将_branchName_分支的变更内容合并到当前分支
- 处理完冲突后，需要git add . 将变更加入缓存区(Staged)，然后git commit提交

##### git push

- git push可以将当前commit版本上传到远程仓库

##### git fetch

- 拉取远程仓库的所有分支名

##### git pull

- 将远程仓库的代码拉取到本地，并合并
- git pull origin master = git fetch origin master + git merge origin/master

##### git rebase

- 变基，即改变新分支的起始基点
- 假设新分支dev从master文件内容为<u>1-2</u>时切分出来，随后master又有了新的commit，变成了<u>1-2-3</u>；而dev分支也有了新的commit，变成了<u>1-2-4-5</u>。此时想将dev分支做的改动<u>4-5</u>加到master中，由于master的提交已经到了远程仓库，dev分支再提交时，想把新变更的<u>4-5</u>加到<u>1-2-3</u>之后，变为<u>1-2-3-4-5</u>，此时需要以master当前的<u>1-2-3</u>为基础，将dev新增内容<u>4-5</u>加入。此时用到了git rebase master
- 注意：与merge的区别
  - dev的内容为1-2-4-5，master的内容为1-2-3，当前处于dev分支，通过指令git merge master，进行合并代码，dev分支会变成1-2-4-5-X (X为3的内容，与dev合并后重新进行的commit)
  - 而**git rebase master，会已master的内容为基础，将dev的新增内容加到master的后面**，git log也会保持为master(全部) log + dev(新增) log，即1-2-3-4-5
  - **merge是以dev的内容为基础，将master变更的内容合并进来**，并将master变更的内容重新进行commit，git log会变为dev(全部) log + 新commit的log，即1-2-4-5-X

## 我理解的git四个区域

git有四个区域

- 本地工作区
  - git add _fileName_ -> 暂存区
- 本地暂存区
  - git reset _fileName_ -> 工作区
  - git commit -m _message_ -> 本地仓库
- 本地仓库
  - git reset _commitID_ -- hard -> (将变更文件)销毁(永久删除)
  - git reset _commitID_ --soft -> (将变更文件放入)暂存区
  - git reset _commitID_ --mixed -> (将变更文件放回)工作区
  - git push -> 远程仓库 
- 远程仓库
  - git pull origin master -> (将远程仓库的文件内容拉取到)本地仓库

## 工作中的实践

#### 克隆仓库和代码开发

**1. git clone _ssh_ //将远程仓库的代码克隆到本地**

**2. git branch _userName_ //新建一个用户分支**

**3. git checkout _userName_ //切换到用户分支**

- 2+3可以合并为 git checkout -b _userName_ //新建用户分支并切换到该分支

**4. //代码开发、修改、调试**

**5. git add _fileName_ 或 git add . //将新增文件加入到缓存区进行追踪，或更新已追踪的文件的变更内容**

**6. git commit -m _message_ //提交代码到本地仓库，并添加log**

#### 进行提交代码前的操作

**1. git checkout master //切换回master分支**

**2. git fetch origin master //下拉远程仓库最新的master代码**

**3. git merge origin/master //把远程仓库最新代码合并到到本地仓库master中**

- 2+3可以合并为 git pull  (origin master) //将远程仓库中最新的master分支代码拉取合并到本地master分支中

**4. git checkout _userName_ //切回用户分支**

**5. git rebase master //将用户分支的更新以master分支的内容为基础进行衍合，master的commit在前，用户分支的commit在后，此处操作可利用vs code的rebase功能**

**6. git checkout master //切到master分支**

**7. git merge _userName_ //将衍合后的用户分支代码合并进master (代码冲突已经在步骤6.中解决）**

**8. git push origin HEAD:refs/for/master //将用户分支修改的代码上传至服务器等待评审，提交到远程仓库master分支**

- git push 是推送代码
- origin 是指远程仓库
- HEAD 是一个指针，指向当前的本地仓库分支，用于告诉git目前工作在哪个分支
- refs/for 意为提交代码到服务器之后是需要经过code review 之后才能进行merge
- master 意为评审通过之后，会merge到远程仓库的哪个分支
  - HEAD:refs/for/master是gerrit的规则，用于code review，即代码评审
  - git push origin HEAD:refs/heads/master 意为不需要代码评审，就merge进远程仓库的master分支