Git学习笔记
写在前面: 参考廖雪峰老师博客文章的Git 文章, 书写个人学习总结. 本篇文章, 目的是用于 Git 总结.
1. 多人协同工作使用分布式的版本控系统(Git)时, 也是需要类似于 GitHub 一样的远程版本库的. 那么与集中式版本控制系统不同的是: 分布式版本系统中每个节点都是一个完整的库, 这样的好处是, 某一个人的机器 down 了, 可以再从其他人机器上 clone 一份完整的版本库; 而集中式版本系统服务器, 如果down了, 所有人都完蛋了, 因为完整的版本库只存在服务器上. 例如使用 svn, 在本地都没有完整的历史版本.
2. svn上你要创建分支，必须联网。git就不用，直接就可以创建分支。感觉上就像是你在自己的机器上同时安装了svn服务端和客户端。 我觉得git与svn的区别就是git相当于svn服务端和客户端的集合。git你可以在自己的机器上一个人随便开发，它拥有完整的版本控制服务。而github这种服务就相当于很多个svn的server端互相同步
PS: svn对于小团队来讲很好用啊，入手门槛低，同步好，联网作为基本功能，基本就没断网过，一般都在公司开发啦，如果回家或者出差，用在线的SVN足矣。
3. git没有权限控制。svn可以设定每个账号都有哪些权限，比如只读，读写权限等。git只要有账号就拥有了所有的权限，随便弄（因为是本地的嘛）其实我觉得对于一般人来说版本控制系统用起来都一样。vss我之前也觉得挺好呢。版本控制系统的主要作用不就是用来记录你都改了那些代码么？大家都能实现，至于其他功能有些人用的到有些人用不到。
对于没有权限控制的git来说，更适合开源程序的开发。而svn等则适合公司内部商业软件的开发，毕竟权限这一条就足够让公司选择svn等集中式的版本控制系统了。 据说git也可以通过自定义脚本实现权限控制，但毕竟麻烦了很多不是。
“权限”问题是很多商业软件选择svn的最重要的原因。企业开发商业软件，通常一个开发者只有一部分模块的权限，用来避免完整的代码被太多人获取从而影响利益。商业软件release一个版本通常会有专人负责，或者用软件自动构建。 开源就不同了，完全不用考虑这些
4. git的分支远比svn高效。
5. Git 的缺点:
7.1 公司一个项目n多人在改,本地打分支基本不可能,一天不拉取代码,本地的代码就已经不是最新的了,所以总要拉取代码,一不小心代码就过时了.提交更是哦.两个人一起做项目,要尽可能快的看到对方的修改,这还要先提交本地,在推上去.感觉除了麻烦,啥好处没感觉到
7.2 只能显示编辑一个分支.经常做项目的时候发现,之前的代码有bug.这时候打分支修改,只能来回切换分支.改着改着,就不知道现在在哪个分支上写代码了
6. VSS，ClearCase,SVN,Git都用过。如果说功能强大，还真要算ClearCase。尤其是项目迭代维护好多年，项目人员水平鱼龙混杂的时候。Git就很麻烦。而CC管理起来相对轻松一些。
7. 所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。
不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的，前面我们举的例子只是为了演示，如果要真正使用版本控制系统，就要以纯文本方式编写文件。
因为文本是有编码的，比如中文有常用的GBK编码，日文有Shift_JIS编码，如果没有历史遗留问题，强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持。
8.
相关命令备忘:
| 0 | git init | 将所在的目录变成 Git 能管理的仓库 |
| 1 | git add <filename> | 将文件从工作区(Working Dictionary)添加到暂存区(Stage) |
| 2 | git add . | 将所有文件从工作区(Working Dictionary)添加到暂存区(Stage) |
| 3 | git commit <filename> -m "description" | 将文件从暂存区(Stage)提交到分支(本地版本库) |
| 4 | git commit -m "description" | 将所有文件从暂存区(Stage)提交到分支(本地版本库) |
| 5 | git log | 查看工作日志 |
| 6 | git log pretty=oneline | 查看简洁版的工作日志 |
| 7 | git reset --hard HEAD^/HEAD^^/HEAD~100 | 通过 HEAD 指针 版本回退 |
| 8 | git reset --hard commit_id | 通过 commit_id 版本回退 |
| 9 | git reflog | 查看操作记录, 方便通过 commit_id 进行版本回退 |
| 10 | git reset --hard | git reset --hard会回退到你最近提交的版本上，如果你修改了工作区的内容只add了没有commit 那么使用了这个命令之后会回退到你最近一次commit的那个版本，你在工作区的修改就会丢失掉。 |
| 11 | git diff |
note: 如果是未被git 管理的文件, 在 add 到 暂存区(stage)之前, 都是 diff 无内容的 比较的是工作区和暂存区(stage)的内容 |
| 12 | git diff --cached | 比较的是暂存区(stage)和分支(master)的内容 |
| 13 | git diff HEAD -- <filename> | 查看 filename(工作区中文件) 和版本库中文件的区别 |
| 14 | git checkout -- <filename> |
1. 当没有 add 到暂存区时, 使用命令意思是: 直接恢复到上一个 commit 2. 已经 add 到暂存区支付, 再对文件修改, 使用命令的意思是:回复到 add 状态 |
| 15 | git reset HEAD <filename> |
3.在1中, 没有 add, 可是加入 add 之后, 发现想要恢复到 没有 add 之前呢? 我的意思是, 把 add 到 stage 中的文件, 重新拉回工作区, 即: 可以把暂存区的修改回退到工作区. {此时仍然保留之前的修改, 只不过是被拉回了工作区} |
| 16 | git checkout {} | 切换到另一个分支 |
| 17 | git rm <filename> |
对比学习: git add <filename> 如果删错了, 还想要找回来, 直接使用: git checkout -- <filename> |
| 18 | ||
对 git 命令进一步补充:
1.对于 git checkout -- <filename> 和 git reset HEAD <filename> 的理解
① 修改后 未add（添加到暂存区） 需要撤销修改时：
git checkout -- myfile.txt 或 手动删除工作区修改
工作区 ： clean 暂存区： clean
② 修改后 add了（未commit） 再次修改文件 要撤销第二次修改时：
git checkout -- myfile.txt (将暂存区恢复到工作区)
暂存区有第一次的修改需要commit
③ 修改后 add了（未commit），需要撤销修改时：
git reset HEAD myfile.txt (将暂存区修改删除) 此时工作区的修改还未撤销, 之后直接修改工作区就可了
④ 修改后 add并commit了，需要撤销修改时：
git reset --hard HEAD^ (版本回退)**/ git reset --hard HEAD~100/ git reset --hard commit_id
