事先申明一下:网上很有很多git的教程,我写这个博客并不是自己有什么独特的东东,只是为了复习git,因为git上有些东西长久不用,有些忘记,所以借此机会复习一下,如果大家想学这个东东的话(我非常推荐廖雪峰的博客)(本人也是引用这个博客比较多的东西)
git教程
工作区和版本库
工作区就是电脑能看到的目录(文件夹)
版本库(在工作区有一个隐藏目录.git
)
git的版本库里面存了很多东西,其中最重要的就是称为stage
(或者称为index
)的暂存区,还有Git
为我们自动创建的第一个分支master
,以及指向master
的一个指针为HEAD
git add something // 实际上把文件添加到暂存区(第一步)
git commit -m "say something" //提交更改,实际上就是把暂存区的所有内容提交到当前分支
因为我们创建Git
版本库时,Git
自动为我们创建了唯一一个master
分支,所以,现在,git commit
就是往master
分支上提交更改。
撤销修改
git checkout -- 文件名 // 只是撤销工作区的修改
命令git checkout -- 文件名
意思就是把文件名
在工作区的修改全部撤销,这里有两种情况:
1. 文件
自修改后还没有添加到暂存区,撤销修改就回到和版本库一模一样的状态
2. 文件
已经被添加到暂存区,又作了修改,撤销修改就回到添加到暂存区后的状态
总结:就是让文件回到最近一次git commit
或git add
时的状态
如果在工作区修改后,又提交到暂存区这时候可以使用命令
git reset HEAD file //可以把暂存区的修改撤销掉,重新放回工作区 接下来可以采用上面撤销工作区的修改
如果把修改之后的内容提交commit
但是还没push
到远程库可以采用版本回退
git reset -- hard commit_id
HEAD
指向的版本就是当前版本,使用命令git reset -- hard commit_id
- 在版本回退之前,可以使用
git log
查看提交命令,确定要回退到哪个版本 - 也可以重返未来,用
用 git relog
查看命令历史,以便确定要回到未来哪个版本
删除文件
在工作区
rm 文件
接下来有两种选择
1.确实删除
git rm 文件
2.工作区删除错误(这很适合那些粗心的同学)
git checkout -- 文件 //恢复工作区文件(建议在一些重要文件夹下采用git,备份,以免误删)
创建与合并分支
在Git
里,主分支被称为master
分支。HEAD
严格来说并不是指向提交,而是指向master
,master
才是指向提交的,所以HEAD
指向当前分支
当我们创建的分支,例如dev
,指向master
相同的提交,再把HEAD指向dev
,就表示当前分支在dev
Git
创建一个分支很快,因为除了增加一个dev
指针,改改HEAD
的指向,工作区的文件都没有任何变化!
从现在开始,对工作区的修改和提交就是针对dev
分支了,比如新提交一次后,dev
指针往前移动一步,而master
指针不变:
加入我们在dev
上的工作完成了,就可以把dev
合并在master
,怎么合并呢,最简单的方法就是直接把master
指向的当前提交,就完成合并:
所以Git
合并分支也很快!就改改指针,工作区内容也不变!
合并完分支后,甚至可以删除dev
分支。删除dev
分支就是把dev
指针给删掉,删掉后,我们就剩下了一条master
分支:
首先,我们创建dev
分支,然后切换到分支:
git branch //查看当前分支
git checkout -b dev
git check
命令加上-b参数表示创建并切换,相当于一下两条命令
git branch dev
git checkout dev
然后在dev
分支上修改,提交
git add
git commit -m ""
现在,dev
分支的工作完成,就可以切换回master
分支
git checkout master
此时的状态为:
现在,把dev
分支的工作成果合并于master
分支上:
git merge dev
git merge
命令用于合并指定分支到当前分支
现在可以安心删除dev
分支
git branch -d dev
解决冲突
假设master
分支和feature1
分支各自分别有新的提交
这时,不能直接利用git merge
直接合并
解决方案就是在git merge
之后,再利用git add
和git commit -m ""
用带参数的git log也可以看到分支的合并情况:
git log -- graph --pretty=oneline --abbrev-commit
分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;那在哪干活呢?干活都在dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本;你和你的小伙伴们每个人都在dev
分支上干活,每个人都有自己的分支,时不时地往dev
分支上合并就可以了。所以,团队合作的分支看起来就像这样:
多人协作
多人协作时,大家都会往master
和dev
分支上推送各自的修改。你的小伙伴已经向origin/dev
分支推送了他的提交,而碰巧你也对同样的文件作了修改,并试图推送:推送失败,因为你的小伙伴的最新提交和你试图推送的提交有冲突,解决办法也很简单,Git
已经提示我们,先用git pull
把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突,再推送:
如果git pull
也失败了,原因是没有指定本地dev
分支与远程origin/dev
分支的链接,根据提示,设置dev
和origin/dev
的链接.
git branch --set-upstream dev origin/dev
再pull:
git pull
git pull
成功,但是合并有冲突,需要手动解决,解决的方法和分支管理中的解决冲突完全一样。解决后,提交,再push:
小结
查看远程库信息,使用
git remote -v
本地新建的分支如果不推送到远程,对其他人就是不可见的;
从本地推送分支,使用
git push origin branch-name
,如果推送失败,先用git pull
抓取远程的新提交;在本地创建和远程分支对应的分支,使用
git checkout -b branch-name origin/branch-name
,本地和远程分支的名称最好一致;建立本地分支和远程分支的关联,使用
git branch --set-upstream branch-name origin/branch-name
;从远程抓取分支,使用
git pull
,如果有冲突,要先处理冲突。