Git的状态转换
近期公司用Git来管理代码,用起来是要比svn爽一些。就是刚接触的时候比較痛苦,特别是那些状态(版本号的提交/合并/回退)。差点把我搞晕了。
如今回过头来总结一下,就清楚多了。
就本地仓库来看。Git能够分成5个不同的状态。能够通过$ git status来查看。这五个状态能够互相转换。详细操作详见以下的“版本号回退/整合”。
当然。有些文件非常实用。不能删除又不能提交,如Eclipse的项目文件. project等。
这样的情况最好就是选择把他们忽略掉,能够通过改动根文件夹的.gitignore文件,或者update-index来忽略掉。
status
显示Git的版本号管理信息:$ git status
一般分成3个区域:
a) Changes to becommitted:暂存区中有改动的文件,但还没commit。
b) Changes notstaged for commit:工作区中已跟踪且有改动的文件,但还没add;
c) Untrackedfiles:工作区中未跟踪文件。未纳入Git的管理,每一个新建的文件都属于这样的。
从上面也能看出非常多操作的提示。
[Changes notstaged for commit]和[Untracked files]都能够通过add把文件加入到[Changes to be committed]。
另外,还能够使文件消失在Git的监控范围(ignore掉),这样status就看不到了。
也能够使用简略的显示模式:$ git status –s
版本号回退 / 整合
依据之前工作区/暂存区/版本号库的状态跳转图,可知道回退也是有多种情况。
a) Untrack区回退
Untrack区存放的是没有纳入Git跟踪的文件。如新创建的还没add的文件。一般Git是不会理会这部分文件的,假设你嫌碍眼,能够通过clean来清楚他们:
先通过$ git clean –n查看要会清楚的文件,然后把n去掉,清除。也能够在后面指定文件名称,文件-f,文件夹-d。
b) 工作区回退
$ git checkout -- XXX意思是,把XXX文件在工作区的改动所有撤销:先检查暂存区有没有XXX,假设有则把工作区的XXX恢复到暂存区的状态;假设没有,则到版本号库取。
$ git checkout . 撤销所有工作区的改动。
这个命令事实上挺危急的。一运行记录都被恢复了,改动都被丢弃了。也能够用$ gitcheckout HEAD XXX。回退暂存区和工作区。
c) 暂存区回退
面的checkout --仅仅是撤销工作区的文件改动,假设我们想撤销暂存区的,就须要使用$ gitreset HEADXXX。它会把暂存区的记录清空掉。
我们通过$ git status就能看到Changes to be committed的内容都跑到Changes notstaged for commit中去了。
也能够用$ git checkout HEAD XXX,回退暂存区和工作区。
对于暂存区来说。这样的方式和commit都会清空记录。前者直接清空,后者先往版本号库写。再清空。
d) 版本号库回退
假设你不小心把脏内容commit到本地master了,上面两种方式就无效了。这时候须要回退版本号库:$ git reset--hardHEAD^
在Git中,用HEAD表示当前版本号。上一个版本号就是HEAD^,上上一个版本号就是HEAD^^。也能够写成HEAD~2。你能够用HEAD后面加n个^。或者HEAD~n来表示回退多少个版本号。
上面是相对版本号的reset,当然也能够指定某一个详细版本号。这时候commitID版本号号就大派用场: $ git reset --hard3628164
3628164仅仅是版本号的前一小部分,Git会帮我们去自己主动匹配。当然也有可能找到多条。所以还是写全比較靠谱。
事实上对于Git来说。HEAD是一个当前版本号号的指针,用reset来切换版本号。实际上是调整HEAD的指向。
所以。假设你reset 到HEAD~10。还行又回去原来的HEAD,那么也能够通过【reset+ 版本号号】的方式切换过去。
当然你要知道相应的版本号号,这时候你能够通过 $ git relog 来查看你的命令历史和相相应的版本号号。
e) 远程版本号回退
Git是分布式版本号控制系统,仅仅要你把内容push出去了,那么远程库就会有记录,你也不能主动改动别人的版本号,这时候就仅仅能覆盖了。
可是你干过的坏事也就公诸于世了。
回退merge
假设仅仅是在merge。则能够直接回退: $ git reset--hard HEAD^
假设merge 以后还有别的操作和改动,则能够使用revert:
$ git revert -m merge线的编号 (从1開始计算,或者merge前的版本号号)
★ 版本号整合
东西已经commit了。可是又想改动,怎么办呢?能够通过上面“版本号库回退”的方法来实现:reset再commit。可是那样commit的改动就没有了,须要又一次改动,工作量大。
所以除此之外。我们还能够:
l 假设仅仅是合并已commit的版本号:$ git rebase -i HEAD~2
l 假设有补充的改动:$ git commit --amend
近期公司用Git来管理代码,用起来是要比svn爽一些。就是刚接触的时候比較痛苦,特别是那些状态(版本号的提交/合并/回退)。差点把我搞晕了。
如今回过头来总结一下,就清楚多了。
就本地仓库来看。Git能够分成5个不同的状态。能够通过$ git status来查看。这五个状态能够互相转换。详细操作详见以下的“版本号回退/整合”。
当然。有些文件非常实用。不能删除又不能提交,如Eclipse的项目文件. project等。
这样的情况最好就是选择把他们忽略掉,能够通过改动根文件夹的.gitignore文件,或者update-index来忽略掉。
status
显示Git的版本号管理信息:$ git status
一般分成3个区域:
a) Changes to becommitted:暂存区中有改动的文件,但还没commit。
b) Changes notstaged for commit:工作区中已跟踪且有改动的文件,但还没add;
c) Untrackedfiles:工作区中未跟踪文件。未纳入Git的管理,每一个新建的文件都属于这样的。
从上面也能看出非常多操作的提示。
[Changes notstaged for commit]和[Untracked files]都能够通过add把文件加入到[Changes to be committed]。
另外,还能够使文件消失在Git的监控范围(ignore掉),这样status就看不到了。
也能够使用简略的显示模式:$ git status –s
版本号回退 / 整合
依据之前工作区/暂存区/版本号库的状态跳转图,可知道回退也是有多种情况。
a) Untrack区回退
Untrack区存放的是没有纳入Git跟踪的文件。如新创建的还没add的文件。一般Git是不会理会这部分文件的,假设你嫌碍眼,能够通过clean来清楚他们:
先通过$ git clean –n查看要会清楚的文件,然后把n去掉,清除。也能够在后面指定文件名称,文件-f,文件夹-d。
b) 工作区回退
$ git checkout -- XXX意思是,把XXX文件在工作区的改动所有撤销:先检查暂存区有没有XXX,假设有则把工作区的XXX恢复到暂存区的状态;假设没有,则到版本号库取。
$ git checkout . 撤销所有工作区的改动。
这个命令事实上挺危急的。一运行记录都被恢复了,改动都被丢弃了。也能够用$ gitcheckout HEAD XXX。回退暂存区和工作区。
c) 暂存区回退
面的checkout --仅仅是撤销工作区的文件改动,假设我们想撤销暂存区的,就须要使用$ gitreset HEADXXX。它会把暂存区的记录清空掉。
我们通过$ git status就能看到Changes to be committed的内容都跑到Changes notstaged for commit中去了。
也能够用$ git checkout HEAD XXX,回退暂存区和工作区。
对于暂存区来说。这样的方式和commit都会清空记录。前者直接清空,后者先往版本号库写。再清空。
d) 版本号库回退
假设你不小心把脏内容commit到本地master了,上面两种方式就无效了。这时候须要回退版本号库:$ git reset--hardHEAD^
在Git中,用HEAD表示当前版本号。上一个版本号就是HEAD^,上上一个版本号就是HEAD^^。也能够写成HEAD~2。你能够用HEAD后面加n个^。或者HEAD~n来表示回退多少个版本号。
上面是相对版本号的reset,当然也能够指定某一个详细版本号。这时候commitID版本号号就大派用场: $ git reset --hard3628164
3628164仅仅是版本号的前一小部分,Git会帮我们去自己主动匹配。当然也有可能找到多条。所以还是写全比較靠谱。
事实上对于Git来说。HEAD是一个当前版本号号的指针,用reset来切换版本号。实际上是调整HEAD的指向。
所以。假设你reset 到HEAD~10。还行又回去原来的HEAD,那么也能够通过【reset+ 版本号号】的方式切换过去。
当然你要知道相应的版本号号,这时候你能够通过 $ git relog 来查看你的命令历史和相相应的版本号号。
e) 远程版本号回退
Git是分布式版本号控制系统,仅仅要你把内容push出去了,那么远程库就会有记录,你也不能主动改动别人的版本号,这时候就仅仅能覆盖了。
可是你干过的坏事也就公诸于世了。
回退merge
假设仅仅是在merge。则能够直接回退: $ git reset--hard HEAD^
假设merge 以后还有别的操作和改动,则能够使用revert:
$ git revert -m merge线的编号 (从1開始计算,或者merge前的版本号号)
★ 版本号整合
东西已经commit了。可是又想改动,怎么办呢?能够通过上面“版本号库回退”的方法来实现:reset再commit。可是那样commit的改动就没有了,须要又一次改动,工作量大。
所以除此之外。我们还能够:
l 假设仅仅是合并已commit的版本号:$ git rebase -i HEAD~2
l 假设有补充的改动:$ git commit --amend