参考资料

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到本地

• 进入仓库服务器

  • 通过浏览器进入公司的代码仓库地址/github仓库

• 登录

  • 

• 获取仓库地址

  • 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 8bce42f21a8d9xxxxxxxxxxxxxx，即可将现有文件恢复到当时提交时的文件状态(指文件内容)

• reset到 用户“l” 提交的版本后，又想回到最新的 用户“a” 提交的版本，该怎么做？

  • 此时通过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

• 查看所有分支

  • $ 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文件内容为1-2时切分出来，随后master又有了新的commit，变成了1-2-3；而dev分支也有了新的commit，变成了1-2-4-5。此时想将dev分支做的改动4-5加到master中，由于master的提交已经到了远程仓库，dev分支再提交时，想把新变更的4-5加到1-2-3之后，变为1-2-3-4-5，此时需要以master当前的1-2-3为基础，将dev新增内容4-5加入。此时用到了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分支