参考资料
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 reset commitID --hard
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分支