群英汇的开源版本控制系统服务和咨询主要是基于Subversion，群英汇的开源项目管理系统平台主要集成的也是Subversion。但是我们公司（群英汇）内部的开发一直在使用Git，所以实际上，我们在Git上也有着丰富的使用和管理经验。 最近一个客户选择了我们提供Git的培训和部署服务，于是从上周开始着手准备《Git培训讲义》。 这个客户是有着实际的需求，才不得不从 Subversion 迁移到 Git，虽然只是公司的部分项目组。 《Git培训讲义》中开头有一章，我给它命名为“爱上Git”，抓眼球是其次，主要是先让用户能够立刻“爱上Git”。

爱上Git(1): 原位版本库创建

• 需求：要对部署的文件进行原位修改，记录变更并以 patch 形式导入正式版本库

• 要是使用SVN 该怎么办呢？

  $ svnadmin create /path/to/repos
  $ svn checkout file:///path/to/repos
  $ svn add *
  $ svn commit
  思考： 引入.svn 目录，在 Web 服务器上的风险...

• Git 就简单多了:

  git init
  git add .
  git commit

爱上Git(2): 重写提交说明

• 需求：提交说明忘了添加bugid, 或者bugid 写错了，需要重写 commit log
• 要是使用SVN 该怎么办呢？
  • 管理员开放版本属性编辑权限
  • svn ps --revprop -r HEAD svn:log "new log message..."
  • 警告：不要改错版本...
• Git 就简单多了:
  • 对于当前提交

    git ci --amend

  • 对于历史提交

    git rebase -i <commit-id>^

    提示：使用 reword 子命令

爱上Git(3): 撤销提交

• 需求：提交的数据包含一个不应该检入的 .zip 大文件，浪费空间和检出时间
• 要是使用SVN 该怎么办呢？
  • 管理员重整版本库

    svnadmin dump
    svndumpfilter
    svnadmin load

    提示：如果能有以前的备份，痛苦会减轻点...
• Git 就简单多了:
  • 当前提交

    git reset HEAD^

  • 历史提交

    git rebase -i <commit-id>^

    提示：使用 edit 子命令

爱上Git(4): 更好用的change list

• 需求：同时针对多个feature/bug修改，只需要对部分改动提交
• 要是使用SVN 该怎么办呢？
  • 还有谁 在用 svn changelist ？——“还有谁？”（想到了功夫中冯导扮演的鳄鱼帮老大） 一个文件不能属于两个changelist changelist 是一次性的？
• Git 的changelist 太好用了，没有多余的命令

  git add ！
  git add -u
  git add -A

爱上Git(5): 更好用的differ

• 需求：更改一个文件，得到和版本库的差异容易，可以得到和我刚才更改（未提交）的差异么？
• 要是使用SVN 该怎么办呢？ no way
• Git ？

  git diff
  git diff --cached
  git diff HEAD

爱上Git(6): 保存工作进度，切换

• 需求：当前工作区修改尚不能提交，而需要切换分支，或者需要干净的工作区（修改另一问题）
• 要是使用SVN 该怎么办呢？

  svn diff > patchfile
  svn revert -R
  ...
  patch -p1 < patchfile

  注意：二进制文件丢失！
• Git ?

  git stash
  ...
  git stash pop

爱上Git(7): 出差办公，可以一样提交

• 需求：出差在客户现场，发现软件 bug，需要修改代码，重新生成版本？
• 要是使用SVN 该怎么办呢？
  • 所有的更改均保留在本地，不能提交，没有历史修改记录，也没有备份！
• Git ？
  • 周星星版的唐伯虎推介说：“实乃居家旅游，馈赠亲友之佳..品..”

    git commit
    git commit
    ...
    git push

爱上Git(8): 基于上游软件的定制

• 需求：我们基于某个开源软件（android?）做定制，需要定期和上游同步
• 要是使用SVN 该怎么办呢？
  • 卖主分支: vendor branch
  • 定制太多，于上游同步基本上相当于重新开发 :-(
• Git ?
  • topgit
• 参考： http://www.ossxp.com/doc/openparty/oss-hacking/

爱上Git(9): 快

• 问一句：您有项目托管在 sourceforge.net 上么？ 或者你要通过互联网访问公司的代码服务器？
• SVN跨互联网访问？
  • SVN 的提交速度慢
  • 提交进度不可见
  • 查看历史慢
• Git?
  • 跨越互联网克隆和PUSH速度块
  • 且进度可见
  • 查看历史？本地速度！:-)

爱上Git(10): 到处用到分页器

• 你在使用 svn log, svn status, svn diff 都要使用管道  “| more” 对么？
• 这是因为SVN命令没有内置分页器
• 而Git的分页器无处不在

对Git的置疑(1): 版本库和工作区混杂

• 问题：版本库和工作区混在一起，不是很容易误删除版本库？
• 一个人的Git的安全性
  • 创建本地克隆啊
• 团队的Git的安全性
  • 只要用户足够多
• 别忘了还有一个好处
  • 没有了无处不在的 .svn 目录

对Git的置疑(2): 提交随时撤销？！

• 问题：git reset命令可以随意撤销提交，是不是太不负责任了？
• 不是，如果是发生在PUSH到服务器之前
• 不是，如果PUSH到服务器之后，但尚未有其他人同步
• 有安全保证，即使撤销的提交也有办法找回
• 是，会导致merge
• 反过来说：SVN历史提交的提交说明可以更改，数据完整性被破坏。而Git数据完整性始终会保持。

对Git的置疑(3): clone OR checkout?

• 问题：Git同时拥有clone和checkout命令，好迷惑
• SVN的检出，在所有DVCS看来，相当于克隆
• Git中的checkout，是.git目录下的版本库到工作区文件的检出
• Git的checkout，还有切换/创建分支的功能

对Git的置疑(4): 没有部分检出？

• 问题：不能检出某个目录
• 是的Git克隆操作只能是全部，不能是部分
• 可以考虑将模块提升为版本库，即使用多版本库
• Git 的submodule

对Git的置疑(5): 命令和SVN不兼容?

• 问题：SVN可以将checkout 写为co, commit写为ci, Git 不可以？
• 可以
• 您可以自己建立命令别名

对Git的置疑(6): 版本号不是从1开始？

• 问题：SVN的版本号是顺序递增的，Git不是？
• 顺序递增对于集中式版本控制可以保证全局唯一
• 分布式版本控制系统，需要全球唯一的提交标识
• 不会有太多不便，尤其是当SVN的提交号也上到6位数 http://svn.apache.org/repos/asf/!svn/bc/986239/subversion/trunk/
• Git可以使用简写的<commit-ID> （4位以上?），只要不发生冲突

您想要在团队中更好的运用 Git 么？

联系群英汇：http://www.ossxp.com/