Source code control 一直是软件开发过程中重要的环节，从最初的纯文件备份，到使用工具进行管理。Source code control 工具的作用也不仅仅只是单纯的对同一个版本进行管理了。从目前主流的source code control工具当中不难发现里面的Branch, tag等功能的应用场景越来越多，特别是现在多数企业使用的敏捷编程，结合branch和tag等功能真的能够很好的做到多版本开发，快速迭代。
思考： 没有source code control我们如何快速的基于一份代码同时进行多个功能的并行开发。
回过头来说下本人在行业当中所用到的几款source code control工具。
VSS(Visual Source Salf)，是一款微软提供的代码管理工具，作为Visual Studio的一员，在早期的开发过程当中确实能够确保代码不被开发人员错误的修改，也解决了异地开发协作的代码共享管理的难点。但是依旧有一些不足，比如：
文件基本以独占的形势进行锁定。如果A在修改的时候B没有办法进行修改。
VSS只支持Windows版本，支持的开发工具仅支持微软系。
基于文件存储，服务器必须共享文件夹。安全性值得考虑。以前一般用于内网开发环境。
收费
SVN(Subversion)，一个开源的source code control system。除开最基本的如VSS提供的代码管理功能外，最大的亮点是提供了分支，且提交内容的级别基于代码行了。也就是说，不用再有独占文件开发的问题了。比如，一个实现接口的代码文件可以由多个开发人员同时修改。谁先做完谁可以先进行提交，不会等到必须所有的人做完后再进行合并。对于不能使用VSS的工程师来说，SVN的出现完全是一个福音，直接从CVS跳到了这么强大的工具上。
总结一下，SVN的优劣如下：
优势：
代码一致性高。
支持提交事物性操作。
Diff 功能。
Branch,Tag的引用，方便版本管理。
轻松上手。
劣势
必须是联网状态下才可以进行一些数据的读取。
不是分布式的代码库。
SVN服务器崩溃的灾难是巨大的。
随着开源运动的流行（Liunx开发人员的功劳），Git也就这么流行起来的。说是在随着开源运动的流行而流行起Git的呢？这归功于Git的分布式这一特性。试想，如果全世界所有的Liunx爱好者都在几台机器上进行开发和提交，这酸爽不敢想象。抑或是主服务器崩溃了，那么其他的开发人员也只有泪奔。
Git的牛逼之处在于以下：
每一次Clone就是从服务器上pull到了所有的内容，包括版本信息。
在本地可以根据不同的需要，本地新建自己的分支。
分支之间的任意切换。
单机上就可以进行分支合并。
牛人＋插件加持。 Git flow, 按Vincent Driessen 分支模型提供的一个插件.
git-model@2x.png
A successful Git branching model
安装
$ 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 | 里程碑管理 |
.
.
建议使用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的使用，仅仅只是抛砖引玉。欢迎大家多多指教。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
