1. 版本库——Git管理源头
版本库(repository)(或者叫仓库),是一个文件目录,这个目录下的所有文件的增、删、改都能被Git跟踪到。Git会在这个目录下生成一个.git文件夹,这个是用来跟踪管理版本库的,里面的文件不能轻易修改。这里只是一个概念简单的理解,后面版本库里还有具体的内容。
2. Git命令
①Git add
提交文件或提交文件修改到暂存区
②Git commit
每当你觉得文件修改到一定程度的时候,就可以“保存一个快照”到仓库,这个快照在Git中被称为commit。一旦你把文件改乱了,或者误删了文件,还可以从最近的一个commit恢复。git commit的记录的含义类似于WORD里面的在修改过程中不同时期的备份文件。
但是由于你并不能完全记住修改的备份文件,git提供了commit日志打印的帮助选项,即下面的③
③Git log
这个命令可以打印出提交到仓库的快照或者是备份的历史日志,这些快照是用commit ID号来编号的(它一般很长而且看不出什么逻辑,因为是SHA1计算出来的),commit ID号也可以叫版本号。
既然能看到版本历史,也就能由此进行版本回退、版本回退后再重回(这里是重点),也就涉及到下面一点Git reset。这里先说一下,Git把当前版本称作HEAD。
④Git reset
//git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区
当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD ,就回到了场景1,第二步按场景1操作。
⑤Git status
显示文件区里受git管理的文件的修改情况
以及以untracked files形式,显示作者自行添加的、尚未git add的文件。
⑥Git diff
⑦Git checkout
当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout – file。git checkout其实是用版本库里的文件版本替换工作区的修改过的文件版本来达到替代修改。
⑧Git switch
用这个可以在分支切换的时候代替checkout命令,比如用git switch -c代替git checkout -b
⑨Git merge
创建了一个副分支,并想在原来的分支上把副分支上的commit合并过来的时候,用git merge操作,就会把master以fast foward形式迅速把commit合并。不保留副分支上的改动历史
而加了参数的,就会保留副分支历史,且一般会生成新的commit。比如:
已经在dev分支做了一个commit。
然后
$ git switch master
Switched to branch ‘master’
准备合并dev分支,请注意–no-ff参数,表示禁用Fast forward:
$ git merge --no-ff -m “merge with no-ff” dev
这个会出现一个新的commit,将dev上的commit合并过来。
⑩Git stash
要切分支了,但是我现在在这个分支上工作还没做完呢,那咋办?用stash先把工作区的修改全部藏起来,后面再调出来。
需要git stash命令保存现场,才能从dev分支切换到master分支
11、Git push
git push origin HEAD:refs/for/master%r=fu@xx.com.cn
格式是git push /远程分支/ /本地分支/
3. 不同区域如何理解
工作区:能看见的git所管理的代码目录(也就是第一段里.git所在的目录)
版本库 —之——stage暂存区
版本库—之——commit提交区
4. 远程仓库与本地仓库(分身术)
你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的,通过拷贝公钥到gerrit完成认证。
当你从远程仓库克隆时,实际上Git自动把本地的master分支和远程的master分支对应起来了,并且,远程仓库的默认名称是origin。
5.本地分支(平行时空)
一开始的时候,master分支是一条线,Git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点。
每次提交,master分支都会向前移动一步,这样,随着你不断提交,master分支的线也越来越长。
当我们创建新的分支,例如dev时,Git新建了一个指针叫dev,指向master相同的提交,再把HEAD指向dev,就表示当前分支在dev上:
不过,从现在开始,对工作区的修改和提交就是针对dev分支了,比如新提交一次后,dev指针往前移动一步,而master指针不变:
假如我们在dev上的工作完成了,就可以把dev合并到master上。
合并完分支后,甚至可以删除dev分支。删除dev分支就是把dev指针给删掉,删掉后,我们就剩下了一条master分支。
4. Git踩坑与出坑
①关于git pull
②git push失败了怎么办?(参考廖雪峰_git教程_多人协作部分)
git push失败,多半可能是文件冲突,也就是你和你的小伙伴门,在同一个分支上工作,而且你们俩改了同一文件,而你的小伙伴先于你做了提交,就会出现这种情况。
这时候,不慌。先从远程分支把最新的commit拉下来,再在本地加上自己加的代码看有无冲突,解决了冲突,再次commit ,再push。
③both motified出现怎么办?
总结一般这个提示语出现在合并分支的修改的时候,两个要合并的分支上都对某个文件
做了修改,git表示这个我操作决定不了,冲突需要你帮我解决,就会显示both motified。
④A分支上出故障,在哪个分支上改故障,怎么合入呢?(和git merge连在一起看)
A分支上出故障,可以switch切换到A分支上,并基于此A swtch -c创建一个A的副分支A’,在A’上改完后commit提交,再merge到A上比较稳妥。以默认merge方式(fast forward)不会出现新的commit,而是直接会把A分支上的指针指向最新的commit。
(master上直接修改代码容易出问题)
⑤branch diverge是怎么回事
⑥本地master分支向远程master上push代码OK了,但是gerrit上却显示Your change could not be merged due to a path conflict.
Please merge (or rebase) the change locally and upload the resolution for review.