先介绍一下本地的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的效果跟前面明显不同）

git与github的一点总结（一）