关于Git版本控制更加深入一点的知识,详细初始使用请查看上一篇:关于Git的配置使用及常见问题
本文主要包括版本回退及分支相关内容。
版本回退
git reset --hard HEAD^
回退到上一版本git reset --hard HEAD^
回退到上上版本git reset --hard HEAD~100
回退到上100个版本git reset --hard 具体版本号
回退到具体版本号
记录每一次命令:git reflog
git checkout -- readme.txt
:
命令git checkout -- readme.txt
意思就是,把readme.txt
文件在工作区的修改全部撤销,这里有两种情况:
一种是readme.txt
自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
一种是readme.txt
已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
总之,就是让这个文件回到最近一次git commit
或git add
时的状态。
删除
删除文件后,Git知道你删除了文件,因此,工作区和版本库就不一致了,git status
命令会立刻告诉你哪些文件被删除了:
现在你有两个选择,一是确实要从版本库中删除该文件,那就用命令git rm filename
删掉,并且git commit
另一种情况是删错了,因为版本库里还有呢,所以可以很轻松地把误删的文件恢复到最新版本: git checkout -- filename
分支
git branch 分支名
:创建分支git checkout 分支名
:切换分支git checkout -b 分支名
:创建与切换同时进行git branch
:列出所有分支git merge dev
:把dev分支的工作成果合并到master分支上git branch -d 分支名
: 删除分支
分支策略
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本;
你和你的小伙伴们每个人都在dev
分支上干活,每个人都有自己的分支,时不时地往dev
分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
多人协助
本文作者:rottengeek
原文链接:https://segmentfault.com/a/1190000016012022