Git

Git 版本控制系统

Subversion 用户眼中的 Git (1): 集中式 vs 分布式

1月14日

由蒋鑫发表在 Git

没有评论

“Git 很古怪” —— 使用 Subversion 的用户说道。

那么从 Subversion 用户的角度来看，Git有哪些古怪之处，或者说特别之处呢？

我们将会以连载的方式一一道来。

如果您有什么建议和补充，或者想知道 Subversion 中的某个 git 对应物，可以在博客后留言 …oO

两种不同类型的版本库：集中式和分布式

Subversion 属于集中式的版本控制系统：

每个版本库有唯一一个“官方地址”，每个用户都从这个唯一地址获取代码、数据；
获取代码库的更新，也只能连接到这个唯一的代码库，同步以取得最新数据；
提交必须有网络连接（非本地版本库）；
提交需要授权，如果没有授权，提交失败；
提交并非每次都能够成功。如果有其他人先于你提交，会提示“改动基于过时的版本，先更新再提交”… 诸如此类
冲突解决是一个提交速度的竞赛：手快者，先提交，平安无事；手慢者，后提交，可能遇到麻烦的冲突解决

Git 属于分布式的版本控制系统：

众生平等，每个检出(checkout)的版本库，或者更准确的说每个克隆(clone)的版本库都是平等的。
你可以从任何一个版本库的克隆来创建属于你自己的版本库，同时你的版本库也可以作为源提供给他人，只要你愿意。
获取版本库的更新，可以来自任何源。
你可以从张三那里获得上游的改动，包括张三自己的提交；你也可以从李四那里获得上游的改动，也可能包括李四的提交。
提交完全在本地完成。无须别人给你授权，你的版本库你作主。
当然你在你的版本库中的改动是否别人愿意合并到他们的版本库则是另外的一回事了。
提交总是会成功，因为提交是在本地进行的么。
甚至基于旧版本的改动也可以成功提交，提交会基于旧的版本创建一个新的分支
冲突解决不再像是SVN一样的提交竞赛，而是在需要的时候才进行合并和冲突解决
- Subversion的提交竞赛，在多人协作开发时，提交经常被打断。坏的体验 :-(
- Git 的每个用户就好像工作在独立的 Feature Branch （功能分支）中
- Git的提交不会被打断，直到你的工作完全满意了，PUSH给他人或者他人PULL你的版本库
  合并会发生在PULL和PUSH过程中，不能自动解决的冲突会提示您手工完成

Git 也可以模拟集中式的工作模式

Subversion只有一种集中式的工作模式
所有人都和服务器同步，提交直接到服务器上
Git 也可以模拟集中式的工作模式
- Git版本库统一放在服务器中
- 可以为 Git 版本库进行授权：谁能创建版本库，谁能向版本库PUSH，谁能够读取（克隆）版本库
- 团队的成员先将服务器的版本库克隆到本地；并经常的从服务器的版本库拉（PULL）最新的更新；
- 团队的成员将自己的改动推（PUSH）到服务器的版本库中，当其他人和版本库同步（PULL）时，会自动获取改变
Git 的集中式工作模式非常灵活
- 你完全可以在脱离Git服务器所在网络的情况下，如移动办公／出差时，照常使用代码库
- 你只需要在能够接入Git服务器所在网络时，PULL和PUSH即可完成和服务器同步以及提交
- Git提供 rebase 命令，可以让你的改动看起来是基于最新的代码实现的改动
Git 有更多的工作模式可以选择，远非 Subversion可比

Git, Subversion, 版本控制

Git 如何拆除核弹起爆码，以及 topgit 0.7到0.8的变迁

1月13日

由蒋鑫发表在 Git

2条评论

我们使用 topgit 和 git 进行公司内部版本控制已经久矣，今天要求大家彻底清除 git 配置中的 push 选项。

要求使用如下命令，先找到遗留topgit错误配置的 git 配置文件：

$ find . -maxdepth 4 -name .git -type d | \
  while read x; do \
  grep -H push $x/config; done

然后对于包含有 push 语句的 config 文件，逐一用 vi 打开，删除包含的 push 语句。

我们为什么这么做呢？这涉及到 git 的 non-fast-forward 以及 topgit 0.7含之前版本的bug 和0.8 的改进。

为什么标题这么吓人呢？什么叫做核弹起爆密码？实际上，这是我们在 Subversion 培训中经常拿来打击商业版本控制工具的一个说法，就是说 SVN 能够将错误提交的代码库中的敏感数据彻底删除（包括历史的删除），这在商业版本控制工具是很难实现的。Git作为开源版本库的No.1，当然可以支持对敏感数据的彻底删除（但是不要在删除前被别人PULL走，否则要逐一“灭口” :X-P: ）。

Git的拆除核弹密码，就是如何进行 non-fast-forward的问题。

阅读全部内容 »

Git, topgit, 版本控制

版本库转换：hg->git->svn->git

1月8日

由蒋鑫发表在 Git

3条评论

有一些在客户现场定制的软件，要把这些零散的工具软件合并到一个 Git库中—— utils 库。如：

一个名为 ldap_import 的工具，是在客户现场完成的，使用 hg 做版本控制，包含16次提交。

目录结构为：

~/test/ldap_import-hg$ ls -aF
./  ../  .hg/  .hgignore  Makefile   sendmail.py*  test/  test.py*  to_ldif.py*

需要导入到一个git库下，但是代码要放在一个目录 ldap_import 下，而不是版本库的根目录。

整个转换过程涉及到使用 fast-export 完成 hg 到 git 的转换；使用git-svn 实现git库向svn的转换；使用 svnadmin dump/load, svndumpfilter 对版本库目录结构进行整理，最后使用git-svn将版本库转换为 git，在合并到统一的 utils Git库中。

补充说明：实际上Git本身可实现路径重构，而无需本文介绍的繁复的版本库转换。
例如：Git的子树合并可以将一个项目的根目录转换为子目录，使用 git filter-branch 可以将子目录提升为根目录等等。

阅读全部内容 »

Git, Hg, Subversion, 版本控制