标签:
先介绍一下本地的git使用流程吧(linux系统环境)
1、切换到你存放代码的文件夹下,执行git init,这样git就接管了当前文件夹下的代码版本管理事项,使用ls -a命令会发现当前目录下出现了一个.git的隐藏目录,这就是git进行管理的大本营。
2、初步配置git。主要就是以下两个命令
git config --global user.name "xxxx"
git config --global user.email "xxxx"
3、这时就可以恣(xiao)意(xin)折腾你的所有代码了,比如有一个名为code.c的代码文件,要跟踪它的所有变动,首先要将其添加到“跟踪列表”中:
git add code.c
这时,执行git status(这是个极其常用的命令,主要就是查看当前的状态),将会看到以下结果:
如果此时新建一个文件new.c,但不添加到跟踪列表,就会如下所示:
现在修改一下code.c,会发生什么呢?
git会觉察到code.c的变动,不过正如提示所言,要保存这些增加的内容,需要再次运行git add code.c。可能有人会问,那第一次运行的git add code.c时,code.c不是没有变动吗,干嘛还要多此一举?实际上,git认为改动前后的code.c不是同一个文件,目前只跟踪了改动前的它,还没跟踪改动后的。我们对比一下new.c的命运就知道了:
可以看到,对于new.c的变动,git根本不鸟它的。。。因为它连首次的git add都没运行,git根本没有跟踪记录。
另外,如果不想再跟踪某个文件,就可以像提示的那样做:git rm --cached code.c,但是这个撤销命令有一些要注意的地方:比如对于本文的code.c,它已经作出了修改,但是还没有提交,故此时它的状态是dirty而不是clean的,所以直接运行的话会是下面这种效果:
解决办法有三个:
(1)放弃对code.c所做的修改,恢复其刚才的面目,如提示给出的那样:git checkout -- code.c,执行这个命令后就能恢复该文件的clean状态,
如图所示,git rm --cached file 只对clean状态的文件有效,clean状态是指,文件的修改被提交或者修改被撤销。该方法显然是撤销。
(2)提交所做的修改,我们继承上面code.c的状态,然后在此基础上操作,首先要重新跟踪code.c:
然后修改code.c:
跟踪并提交此次修改:
提交之后,发现code.c在状态列表中消失了,但是只要code.c一有变动,那么变动就会立刻出现在列表中,换句话说,git其实仍在监视着它(这点就不再做实验了,自己动手试试吧)。想要git不再监视,就执行git rm --cached code.c,如下图:
(虽然不再跟踪code.c,但是会保留”删除“这个动作的痕迹,以备恢复,这点以后再谈)
(修改了code.c,但是git没有反应,说明不再监视它了)
(3)最暴力的一种,就是强制删除了,即git rm -f --cached code.c,我就不上图了。
在实验中我还发现一件事,即下图的这个现象:
只会在第一次跟踪文件然后做出修改时出现,如果code.c已经有过提交记录,就不会再有这种提示了,我们接着(2)中的状态继续:
(这里不在有绿色的”新文件“提示)
(这里也没有add变动,但是rm的效果跟前面明显不同)
标签:
原文地址:http://blog.csdn.net/u012668018/article/details/42386841