Git学习

Git学习

1.     文件状态

Modified(workingdirectory)：被修改过的文件

Staged(stagingarea)：通过gitadd添加到暂存区域的文件

Committed(gitdirectory)：通过gitcommit提交到仓库的文件

2.     两个查看命令—status，diff

git status 用于查看本地工作区内文件的变化情况（对比的是缓冲区）

可以用于查看这些修改是否是这次代码功能需求中的，建议一一查看。当然，使用git add后也可以使用git status追踪文件变化，但效果差不多。

git diff --staged 查看两次暂存的快照之间的差异，git status主要是文件差异提醒，diff就可以看到差异详情。

【小结】：当使用git add将缓存区准备妥当之后便可以提交了，但在此之前先使用git status确定本次修改的内容是否都提交成功，然后使用git diff看看提交的是不是都是自己修改的，如果不是，很有可能出现了代码回溯， 然后再git commit。

3.      写好commit message

• Mod: XXX, 表示修改（Modify）
• Add: XXX, 表示新增（Add）
• Rem: XXX, 表示移除（Remove）
• Ref: XXX, 表示重构（Refactory）

【小结】：在开发阶段每一次commit尽量只提交1,2变化，将git当做协作开发的工具，而不是最终的代码提交存储的地方。协作开发过程中，如果大家都是在本地写完了自己的所有task才进行提交合并，容易出现代码回溯，出现冲突的概率变大，情况变复杂，修改起来也容易出现错误。所以在开发过程中，尽量保持修改一两处的时候就提交一次，并严格检查提交的是否是自己修改的，在commit注释中写清楚这次提交的变化，便于自己记忆和他人了解。

当出现有阶段性的迭代成成果时，建议采取写message段落的方式，而不是 -m，将这一阶段的修改进行陈列，可以参考之前提交的commit -m。

【题外话】：如何提交成段的注释信息

首先，使用下面这个命令来设置git默认的编辑器，其中的“editor”替换成你自己的编辑器，如Vim、Emacs、gedit、subl等——git config --global core.editor "editor -w"；然后，在做提交的时候使用命令不要写"-m"参数，直接写成git commit这样子就行，这样就会自动打开你刚才指定的编辑器，你可以在里面添加大段注释。

4.     协作冲突

 git pull将最新的提交从分支上抓取下来，在本地合并，然后解决冲突。

实验环境：两个操作者A和B，一个远程仓库gitlearn，文件a.txt，里面有一个数字1

操作：A加了一行Hello并且add到缓冲区。

操作：B加了一行Hi。未add前可以看到，git status命令可以看到提示，有一个有趣的现象是，如果文件的修改未提交的缓冲区，提示都是红色的，添加到缓冲区后，提示都是绿色的

操作：A成功push，无错误信息

操作：B在A之后push，出现错误

操作：B进行pull，可以看到最后一行的提示正是出现冲突需要修复，此时master后面也有一个merging提示目前处于合并工作下

操作：这时我们让A也进行一下pull，可以看到A并不知道B提交的代码与自己遇到冲突，一切显示正常

在B工作区下的a.txt已经出现问题，git系统自动进行冲突检查和提示，Head下的内容是B修改的，==符号下面直到一串字符中间的则是远程仓库中的代码

B根据情况进行修正，后进行add->diff->commit->push

【小结】：A同学添加了Hello并成功push，这时B同学在同一个文件下进行了修改，在push Hi的时候，提示出现冲突，于是需要进行了pull工作，这时下下来的文件已经被github智能划分过了，需要B同学进行冲突解决，需要注意的是，这个冲突对A来说是不可见的，他进行pull的时候提示的仍然是Already： up-to-date，当B修改完冲突后push，便出现如图上所示的合并。

5.      解决冲突的错误示范

操作A并不知道B加了一行Hi，同时在自己的原有代码基础上进行开发，添加了一行YEAH，并push，发现错误后pull下仓库的最新代码，并用git diff查看到git自动查找错误后的代码，发现自己的Yeah被改成了HEAD一堆一堆，然后A同学任性地再重复一遍add->commit，发现在不解决冲突的情况下仍然可以自己的代码更新到远程仓库中。原因是，当重复commit，git会自动认为冲突已经解决。

【小结】：当我们很“坑队友”地忽略错误提示不进行冲突解决，重复进行git add、git commit，那么就会将带有错误提示的代码上传到远程仓库中，从而也影响了其他人的开发工作，特别是代码量很大的时候，会造成更大的修改困难。

 

6.      错误示范的危害

B在不知情A上传错误代码的情况下pull下来，一切正常，无论是diff还是status都提示无变化，但代码已经被污染了

 

建议不要在工作之前就先pull下别人的更新，然后直接在别人的更新下进行自己的代码开发工作，因为如果别人的git操作出现问题，轻易pull很容易就把自己的工作区代码“污染”了，出现代码回溯或者代码错误的现象。而是在工作完成后严格按照add->status->diff->push，这时候如果出现冲突是好事，我们就可以进行pull->diff，查看别人更新上去的代码区域和自己修改的代码区域出现的冲突，一一确认一一解决再重新push上去，如果出现不确定的情况，也可以和队友进行讨论最终确定update的最新代码，从而也避免了自己的上次或者什么时候的正确代码被别人覆盖了却也毫不知情。

 

7.      回滚到以前的状态

先用reset将某一个版本从仓库回滚到暂存区，然后用checkout将暂存区的东西恢复到工作区

这时候也无法直接提交到远程仓库中

只能重新pull下最新的“错误”代码，并手动覆盖，再进行add->commit->一系列操作，才能将仓库恢复到正常状态。

小结：恢复过程很麻烦，所以大家一定要负责任地解决冲突和提交代码啊~~( ⊙ o ⊙ )！