从VSS到SVN再到Git 记Git的基本操作

Source code control 一直是软件开发过程中重要的环节，从最初的纯文件备份，到使用工具进行管理。Source code control 工具的作用也不仅仅只是单纯的对同一个版本进行管理了。从目前主流的source code control工具当中不难发现里面的Branch, tag等功能的应用场景越来越多，特别是现在多数企业使用的敏捷编程，结合branch和tag等功能真的能够很好的做到多版本开发，快速迭代。思考： 没有source code control我们如何快速的基于一份代码同时进行多个功能的并行开发。回过头来说下本人在行业当中所用到的几款source code control工具。

VSS

VSS(Visual Source Salf)，是一款微软提供的代码管理工具，作为Visual Studio的一员，在早期的开发过程当中确实能够确保代码不被开发人员错误的修改，也解决了异地开发协作的代码共享管理的难点。但是依旧有一些不足，比如：文件基本以独占的形势进行锁定。如果A在修改的时候B没有办法进行修改。

VSS只支持Windows版本，支持的开发工具仅支持微软系。

基于文件存储，服务器必须共享文件夹。安全性值得考虑。以前一般用于内网开发环境。

收费

SVN

SVN(Subversion)，一个开源的source code control system。除开最基本的如VSS提供的代码管理功能外，最大的亮点是提供了分支，且提交内容的级别基于代码行了。也就是说，不用再有独占文件开发的问题了。比如，一个实现接口的代码文件可以由多个开发人员同时修改。谁先做完谁可以先进行提交，不会等到必须所有的人做完后再进行合并。对于不能使用VSS的工程师来说，SVN的出现完全是一个福音，直接从CVS跳到了这么强大的工具上。
总结一下，SVN的优劣如下：优势：
代码一致性高。

支持提交事物性操作。

Diff 功能。

Branch,Tag的引用，方便版本管理。

轻松上手。

劣势
必须是联网状态下才可以进行一些数据的读取。

不是分布式的代码库。

SVN服务器崩溃的灾难是巨大的。

Git

随着开源运动的流行（Liunx开发人员的功劳），Git也就这么流行起来的。说是在随着开源运动的流行而流行起Git的呢？这归功于Git的分布式这一特性。试想，如果全世界所有的Liunx爱好者都在几台机器上进行开发和提交，这酸爽不敢想象。抑或是主服务器崩溃了，那么其他的开发人员也只有泪奔。
Git的牛逼之处在于以下：每一次Clone就是从服务器上pull到了所有的内容，包括版本信息。

在本地可以根据不同的需要，本地新建自己的分支。

分支之间的任意切换。

单机上就可以进行分支合并。

牛人＋插件加持。 Git flow, 按Vincent Driessen 分支模型提供的一个插件.



git-model@2x.png
A successful Git branching model

如何使用Git

安装

$ Brew install git
创建仓库
$ git init

文件操作有了仓库后就可以对文件进行 add , commit, push 和pull等操作了。

Tables	Are
git add	添加至暂存区
git add–interactive	交互式添加
git apply	应用补丁
git am	应用邮件格式补丁
git annotate同义词，等同于 git blame
git archive	文件归档打包
git bisect	二分查找
git blame	文件逐行追溯
git branch	分支管理
git cat-file	版本库对象研究工具
git checkout	检出到工作区、切换或创建分支
git cherry-pick	提交拣选
git citool	图形化提交，相当于 git gui 命令
git clean	清除工作区未跟踪文件
git clone	克隆版本库
git commit	提交
git config	查询和修改配置
git describe	通过里程碑直观地显示提交ID
git diff	差异比较
git difftool	调用图形化差异比较工具
git fetch	获取远程版本库的提交
git format-patch	创建邮件格式的补丁文件。参见 git am 命令
git grep	文件内容搜索定位工具
git gui	基于Tcl/Tk的图形化工具，侧重提交等操作
git help	帮助
git init	版本库初始化
git init-db*	同义词，等同于 git init
git log	显示提交日志
git merge	分支合并
git mergetool	图形化冲突解决
git mv	重命名
git pull	拉回远程版本库的提交
git push	推送至远程版本库
git rebase	分支变基
git rebase–interactive	交互式分支变基
git reflog	分支等引用变更记录管理
git remote	远程版本库管理
git repo-config*	同义词，等同于 git config
git reset	重置改变分支“游标”指向
git rev-parse	将各种引用表示法转换为哈希值等
git revert	反转提交
git rm	删除文件
git show	显示各种类型的对象
git stage*	同义词，等同于 git add
git stash	保存和恢复进度
git status	显示工作区文件状态
git tag	里程碑管理

.
.

Best practice

建议使用github进行上手实验。使用邮箱注册一次Git hub后即可在Github上创建自己的Repository.



2.png
创建完成后，我们会得到一个Repository的地址。有了这个地址我们就可以进行Git的练习了。


3.png
使用git clone 将远程仓库clone到本地。

git clone

5.png
添加一些文件

echo "Hello Scott" -> "Hello"   //写了一个文件到Hello
git add Hello // 将Hello文件添加到暂存区。(Index)
git commit -m "this is my first file" // 提交到本地仓库
git push  //推送本地仓库到远程仓库

6.png
以上，文件就被推送到了远程仓库。其他工程师如果执行Pull操作的话即可把变动的文件拉到本地。


7.png
如果有其他工程师修改了文件，需要远程获取下。

git pull  //拉取远端文件
git log //可以查看变更历史

A5B85BFD-764E-468F-81C4-0B727BA70428.png
冲突的解决
冲突往往是因为版本不一致而产生。如工程师A修改了Hello文件并提交到远端仓库，而B在本地修改了Hello，也想提交。由于A和B的Hello文件并不一致，所以冲突产生了。



4EB9EB75-2FF9-4363-AD78-9E13D1415EA8.png
只需要git pull一次即可。 （注：git pull 会自动merge，但是通常情况下自动merge效果不会太好。比如A和B 都在修改function A (){} ）
冲突长这模样。


10.png
一般手动解决冲突后，重新添加，提交，push即可。



11.png
如上描述，手动合并冲突比较麻烦。建议使用工具进行git 的操作，现在一般的工具都提供了分支管理，合并等功能。
推荐 SourceTree

分支的管理

在很多时候会遇到同时需要开发多个功能，开发任务将会交给多个工程师进行开发，这个时候在Git上的实践为－－>创建多个分支。 N个工程师从Master或Dev分支进行分支创建。

git checkout -b NewFeature   // 分支建好后，会直接切换到该分支。git push --set-upstream origin NewFeature //与远程分支关联

完成开发后，需要合并到Master 或Dev 分支。

git merge origin/NewFeature  // 将远程分支NewFeature与当前分支合并。

12.png

写在最后

以上从source code control扩散到Git的使用，仅仅只是抛砖引玉。欢迎大家多多指教。