浅谈版本控制 Git
最近写项目心烦，考虑到自己做的项目，由于自己经常同时在多台电脑上操作调试程序，需要不断同步代码，但总是忘记更新该文件。了解到最近比较火的版本控制（Version control），于是自己就学习了一下，将版本控制及相关文件的更新比较操作来交给计算机来完成。
我一直听说代码托管Git， Git是分布式存储控制，每个成员可以下载、编译生成自己的分支，相互之间互不冲突，就像一棵树不断的长出各种躯干叶子一样 。Git是什么？
Git是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。
Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
Git 与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持。
GIT不仅仅是个版本控制系统，它也是个内容管理系统(CMS),工作管理系统等。
如果你是一个具有使用SVN背景的人，你需要做一定的思想转换，来适应GIT提供的一些概念和特征。
Git 与 SVN 区别点：
1、GIT是分布式的，SVN不是：这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。
2、GIT把内容按元数据方式存储，而SVN是按文件：所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。
3、GIT分支和SVN的分支不同：分支在SVN中一点不特别，就是版本库中的另外的一个目录。
4、GIT没有一个全局的版本号，而SVN有：目前为止这是跟SVN相比GIT缺少的最大的一个特征。
5、GIT的内容完整性要优于SVN：GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。
Git是目前世界上最先进的分布式版本控制系统（没有之一）。
Git有什么特点？简单来说就是：高端大气上档次！
那什么是版本控制系统？
如果你用Microsoft Word写过长篇大论，那你一定有这样的经历：
想删除一个段落，又怕将来想恢复找不回来怎么办？有办法，先把当前文件“另存为……”一个新的Word文件，再接着改，改到一定程度，再“另存为……”一个新文件，这样一直改下去，过了一周，你想找回被删除的文字，但是已经记不清删除前保存在哪个文件里了，只好一个一个文件去找，真麻烦。看着一堆乱七八糟的文件，想保留最新的一个，然后把其他的删掉，又怕哪天会用上，还不敢删，真郁闷。更要命的是，有些部分需要你的财务同事帮助填写，于是你把文件Copy到U盘里给她（也可能通过Email发送一份给她），然后，你继续修改Word文件。一天后，同事再把Word文件传给你，此时，你必须想想，发给她之后到你收到她的文件期间，你作了哪些改动，得把你的改动和她的部分合并，真困难。于是你想，如果有一个软件，不但能自动帮我记录每次文件的改动，还可以让同事协作编辑，这样就不用自己管理一堆类似的文件了，也不需要把文件传来传去。如果想查看某次改动，只需要在软件里瞄一眼就可以，岂不是很方便？
几乎每个开发者每天都在用版本控制系统，那么为什么我们要用它呢？
为什么需要版本控制系统（VCS）
最基本最重要的原因当然是版本回复reversion。随着开发，代码不断地在演化。如果你在写代码的时候发现一秒钟前错误的删除了一行代码，你会很快的用ctrl+z来撤销修改，从而回复你错删的代码。但是如果你经过一个小时的努力，改了很多的代码文件，你发现这个修改是不可行的，需要倒退回去，你改怎么办？有人有比较好的习惯，当认为目前有里程碑意义的时候就把代码全备份，如果后面发现想倒退回来的时候就删除修改后的，重新启用之前备份的。这样可以解决一些问题，但是这是手工的，很麻烦。只要是麻烦的事情都会容易让你懒于去做。如果有可以工具，让你很方便的退回到以前的某个时候的代码状态，是不是很好？这就是版本控制系统要解决的问题。
还有一个重要的原因就是变更跟踪。如果你手工备份，是不是也得写一个readme文件，说明为什么要修改。如果是多人协同开发，你还想知道是谁修改的。如果有一个工具可以帮你自动维护这些信息，让你很容易达到目的，何乐而不为呢？
还有一个重要的原因就是bug跟踪。如果你在一个稳定的版本上做了修改，发布以后发现有bug了。你首先想到的肯定是你修改导致的，如果你能快速的找到你的修改点，是不是很容易定位错误。还有另一种情况，在发现bug的时候你的代码又前进了很多，你要想重现bug是不是要利用之前的哪一个版本来测试？
综合这些问题，我们需要一个版本控制系统来：
- 维护代码的演化历史
- 记录历史变化的原因和说明
- 如果是多人开发，就会发生多人修改同一个文件的可能，还得保证彼此不会覆盖他人的代码，甚至能智能地合同。
版本控制系统 - 基本概念
-
Atomic operations - 原子操作
当你向VCS提交一些变更的时候，要么全部提交成功，要么全部提交失败。这样可以保证系统的一致性。试想如果只是成功提交了一部分，很可能导致整个系统因为缺失部分没有提交上来的文件而出错。并不是所有的VCS都有这个功能，CVS就没有。SVN和Git就有。 -
File locking - 文件加锁
如果你在修改一个文件，你希望别人不要同时修改，不然就会冲突。所以你需要在这个文件上加锁，告诉别人我在修改，你先别动。等你修改好了，你提交了，释放了锁，别人才能接着修改。但这样会导致一些问题，如果你一直加锁，别人也想修改，不然就做不下去，那么别人就得等待。这样就会影响效率。如果你全球性的开发就更是问题，特别是你睡觉前忘了解锁，别人就一天不能干活了。如果不加锁就得解决合并的问题，也就是帮你们把多个人的修改合并到一起。 -
Version merging - 版本合并
如果允许多人同时修改一个文件，比如svn和git，就得解决合并问题。如果多个人都在修改一个文件，第一个人提交的时候当然没有问题。第二个人提交的时候系统就要求他手工合并，这对于一般的文本文件来说相对容易，尤其是如果你们修改的不是同一行，一秒钟就合并好了。如果修改了同一行，你得当心，不要再合并的时候破坏了别人的修改从而导致系统一致性受到破坏。如果是图片等二进制文件的合并就更加困难。这个也能体现vcs的功能的强大。还有协同开发模式的优劣。 -
Baselines, labels and tags - 基线和标签
工作中的提交是频繁的，琐碎的。但是当你认为当前的版本是一个里程碑行的稳定版本的时候，或者是一次release的时候你就需要价格标签，说明他的重要性，以便今后快速的退回到这里。 -
Truncks & Branches - 主干与分支
分支可以看做是一条代码演化路径，也是开发路径。"branch head"就是指该branch的最新commit。下图中的Branch A和B就是分别指向了着两个branch的头。master指向了主干上的head。
Java代码 收藏代码
o–o--o <-- Branch A
/
o–o--o <-- master
\
o–o--o <-- Branch B
基本上很多人一起开发的时候大家都是共同基于一份代码库，修改的也是一份。这就是主干Truncks。但是如果这种事情发生了：你发布的系统出了问题bug，需要测试修改bug。同事主干上正在进行大规模的架构重构和升级，这两方面的工作有冲突，必须只能做一件。这时候你可以从主干里面拉出一个分支，让维护人员去修改bug，从而发布，这些修改不会提交到主干。在主干上主力人员还可以继续修改，互不影响。
- Distributed revision control - 分布式代码控制
传统的vcs，代码库是集中式的，所有人都从一个地方下载代码，并提交到这里。git是一种分布式的代码库管理方式。分布式的代码库是基于点对点的复制和交换，这样更快。
如何使用分布式版本控制系统 - Git
7. 下载安装msysgit， 在Windows上运行的git开源项目
8. 打开git-cmd.bat， 创建一个目录，建立一个版本库git-repository\depot
9. 如果你的项目已经开始，就把项目copy到depot，然后添加:
10. Clone， 如果自己在本地工作，你就可以clone本地的repository, 在你的workspace执行：
详细使用可看：
Git 完整命令手册地址：http://git-scm.com/docs
PDF 版命令手册：github-git-cheat-sheet.pdf