这一篇就来介绍版本管理的主要活动——开发过程中的 git 操作。各种操作都只给出一个简单的例子让大家熟悉怎么使用，至于经验之谈就留待后作了。

　　首先，演示一下怎么基于 github 进行协同开发。 其实就是要把各个开发者都加入到版本库的开发者列表中。为了演示，我申请了两个 github 账号，一个在本机 win7 中使用，一个在虚拟机 XP 中使用，这样来模拟两只程序猿的协同开发。

1. 我照着 help 里的教程创建了一个一模一样的 Hello-World：
   https://github.com/1184893257/Hello-World

2. 然后我点击 Settings：

   
   

3. 左边选择 Collaborators（合作者），把另一只程序猿 liuqiaoyu2 加入：

   
   

4. 接着 liuqiaoyu2 把 Hello-World 克隆下来（clone），这样 liuqiaoyu2 就有了一个本地的一模一样的 Hello-World：

   
   

5. 由于我是在 D:\notlong 中启动 Git Bash 进行克隆的，所以在 notlong 文件夹中出现了一个 Hello-World 文件夹。
   打开 Hello-World 文件夹，右击空白区域，发现有好几项 git 相关的菜单，说明这里受 git 版本控制：

   
   

commit

commit 就是提交修改到本地版本库中。
用图形界面比较好弄，在上面的右键菜单中选择 Git Gui 就进人了图形界面的 git。

1. 在 README 中我添加了一行 "new line"， 保存 README 文件，在 Git Gui 中可看到这次改动（可能需要"重新扫描"一下）：

   
   

2. 先"缓存改动"，然后填写"提交描述"（不写不行哦O(∩_∩)O~），最后"提交"：

   
   

3. Git Gui 中可以方便地看到所有提交的修改，在菜单栏中点击 版本库->图示所有分支的历史：

   
   

4. 之后就弹出下面这个对话框，可以看到两个 commit 的发起人不同，本文之后还会出现不少这种版本历史图：

   
   

push

commit 只是提交到本地，要推送到远程就得用 push 了。
这个我习惯上在 Git Bash 中操作。
在进行 push 操作前，先 pull，因为可能有别的开发者推送了变更。

1. 先 pull，因为没有别人推送变更，所以报告"Current branch master is up to date"，然后 push：

   
   

2. 在 github 上看到了远程版本库已经更新了：

   
   

3. 点击 Commits，可看到所有提交：

   
   

pull

pull 是将远程版本库的新变更下载合并到本地。
pull 用 rebase 方式合并比较好，后续文章再来讨论，这里暂且不提。

1. 1184893257 执行 pull 操作：

   
   

2. pull 完成后 1184893257 的 README 就加入了 liuqiaoyu2 的变更：

   
   

3. 1184893257 的版本历史图：

   
   

　　在介绍以上 3 个操作的同时，我们在不知不觉中完成了一次协同开发： liuqiaoyu2 对 README 做了变更，之后 1184893257 获取了这次变更。

　　接下来主要介绍跟分支相关的操作。 一个分支就是独立的一条版本库演化路径，版本库默认只有一个 master 分支，我们可以基于一个已存在的分支创建新的分支。

checkout

checkout 是切换分支的操作， 加上 -b 选项可以创建并切换到新分支。

1. 创建 newbranch 分支，并在 newbranch 和 master 分支间切换：

   
   

   　　由于 newbranch 分支刚从 master 创建出来，没有做任何提交，所以 newbranch 和 master 是一模一样的，它们之间的切换看不出有什么变化。
   　　但是，如果在 newbranch 分支中修改 README 并提交，再切换，就会发现 README 的变化了。

2. 切换分支用右键操作更方便：

   
   

branch

branch 操作可以做什么我也不太清楚，只知道加上 -D 选项是删除分支：

rebase

rebase 是合并两个分支的一种操作（还有merge）。

1. master 修改 README，提交：

   
   

2. 切换到 newbranch，修改 README，提交：

   
   

3. 目前的版本历史图：

   
   

4. 切换到 master 分支，rebase newbranch：

   
   

5. 现在的 README：

   
   

6. 现在的版本历史图：

   
   

   可以看到 master 将 newbranch 的变更踩在了脚底下。

merge

merge 也是合并两个分支的操作。

1. 如果刚才不是用 rebase 而是用 merge：

   
   

2. 现在的 README：

   
   

   效果一样，O(∩_∩)O~

3. 版本历史图：

   
   

   merge 不调整 commit 的顺序，只是在 master 中添加了一个 "merge commit"。

reset

reset 可以重置分支到某个 commit，有点像下棋的时候悔棋。

1. 打开版本历史图，选中某个 commit （这里选了 "first commit"），右击，选择"Reset ..."：

   
   

2. 选择 reset 的模式（这里选了 Hard）:

   
   

   • Soft、Mixed 都不改动版本库中的文件， Soft 变更已缓存、Mixed 变更未缓存。（这里好费解o(╯□╰)o，各位看官实验一下就知道了）
   • Hard 重置版本库中的文件。

3. 看版本历史图，newbranch 下移了：

   
   

4. README 恢复到第一次提交时的样子：

   
   

reset 与"悔棋"不同的是：reset 不仅可以向下，还可以向上O(∩_∩)O~。

总结

commit 是必须的，无论你玩的是单机（没有协同开发，只在本地玩玩）还是网游（协同开发，服务器托管代码）。
pull、push 是与远程版本库互动的操作，协同开发一定要用的。
checkout、branch、rebase、merge、reset 分支操作，方便开发。