<?xml version="1.0" encoding="UTF-8"?> <rss
version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
><channel><title>群英汇博客 &#187; 版本控制</title> <atom:link href="http://blog.ossxp.com/tag/%e7%89%88%e6%9c%ac%e6%8e%a7%e5%88%b6/feed/" rel="self" type="application/rss+xml" /><link>http://blog.ossxp.com</link> <description></description> <lastBuildDate>Wed, 14 Sep 2011 03:52:03 +0000</lastBuildDate> <generator>http://wordpress.org/?v=2.9.2</generator> <language>en</language> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <item><title>回到未来 (3)</title><link>http://blog.ossxp.com/2010/12/2269/</link> <comments>http://blog.ossxp.com/2010/12/2269/#comments</comments> <pubDate>Tue, 28 Dec 2010 02:44:29 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[Git]]></category> <category><![CDATA[《Got Git》]]></category> <category><![CDATA[版本控制]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=2269</guid> <description><![CDATA[
9.3.3   时间旅行三
《回到未来-第三集》铁匠布朗博士手工打造了可以时光旅行的飞行火车，使用蒸汽作为动力。这款时间旅行火车更大，更安全，更舒适，适合一家四口外加宠物的时空旅行。与之对应本次实践也将采用“手工打造”：交互式变基。
交互式变基就是在上一节介绍的变基命令的基础上，添加了 -i 参数，在变基的时候进入一个交互界面。使用了交互界面的变基操作，不仅仅是自动化变基转换为手动确认那么没有技术含量，而是充满了魔法。
执行交互式变基操作，会将 &#60;since&#62;..&#60;till&#62; 的提交悉数罗列在一个文件中，然后自动打开一个编辑器来编辑这个文件。可以通过修改文件的内容（删除提交，修改提交的动作关键字）实现删除提交，压缩多个提交为一个提交，更改提交的顺序，更改历史提交的提交说明。
例如下面的界面就是针对当前DEMO版本库执行的交互式变基时编辑器打开的文件：
pick b3af728 ignore object files.
pick 3488f2c move .gitignore outside also works.
pick 48456ab add hello.h
pick b6f0b0a modify hello.h# Rebase d71ce92..b6f0b0a onto d71ce92
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, <a
href="http://blog.ossxp.com/2010/12/2269/" class="more-link">阅读全部内容 &#187;</a>]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/12/2269/feed/</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item><title>回到未来 (2)</title><link>http://blog.ossxp.com/2010/12/2267/</link> <comments>http://blog.ossxp.com/2010/12/2267/#comments</comments> <pubDate>Tue, 28 Dec 2010 02:43:43 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[Git]]></category> <category><![CDATA[《Got Git》]]></category> <category><![CDATA[版本控制]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=2267</guid> <description><![CDATA[
9.3.2   时间旅行二
《回到未来-第二集》布朗博士改进的时间旅行车使用了未来科技，是陆天两用的飞车，而且燃料不再依赖核物质，而是使用无所不在的生活垃圾。而此次实践使用的工具也进行了升级，采用强大的 git rebase 命令。命令 git rebase 是对提交执行变基操作，即可以实现将指定范围的提交“嫁接”到另外一个提交之上。其常用的命令行格式有：
用法1: git rebase --onto  &#60;newbase&#62;  &#60;since&#62;      &#60;till&#62;
用法2: git rebase --onto  &#60;newbase&#62;  &#60;since&#62;
用法3: git rebase         &#60;newbase&#62;               &#60;till&#62;
用法4: git rebase <a
href="http://blog.ossxp.com/2010/12/2267/" class="more-link">阅读全部内容 &#187;</a>]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/12/2267/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item><title>回到未来 (1)</title><link>http://blog.ossxp.com/2010/12/2260/</link> <comments>http://blog.ossxp.com/2010/12/2260/#comments</comments> <pubDate>Tue, 28 Dec 2010 02:39:50 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[Git]]></category> <category><![CDATA[《Got Git》]]></category> <category><![CDATA[版本控制]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=2260</guid> <description><![CDATA[9.3   回到未来
电影《回到未来》（Back to future）第二集，老毕福偷走时光车，到过去（1955年）给了小毕福一本书，导致未来大变。布朗博士正在解释为何产生两个平行的未来Git  这一台“时光机”也有这样的能力，或者说也会具有这样的行为。当更改历史提交（SHA1哈希值变更），即使后续提交的内容和属性都一致，但是因为后续提交 中有一个属性是父提交的SHA1哈希值，所以一个历史提交的改变会引起连锁变化，导致所有后续提交必然的发生变化，就会形成两条平行的时间线：一个是变更 前的提交时间线，另外一条是更改历史后新的提交时间线。
把此次实践比喻做一次电影（回到未来）拍摄的话，舞台依然是之前的DEMO版本库，而剧本是这样的。角色：最近的六次提交。分别依据提交顺序，编号为 A, B, C, D, E, F。
$ git log --oneline -6
b6f0b0a modify hello.h                        # F
48456ab add hello.h          <a
href="http://blog.ossxp.com/2010/12/2260/" class="more-link">阅读全部内容 &#187;</a>]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/12/2260/feed/</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item><title>Git 工作区、暂存区和版本库</title><link>http://blog.ossxp.com/2010/11/2166/</link> <comments>http://blog.ossxp.com/2010/11/2166/#comments</comments> <pubDate>Tue, 30 Nov 2010 07:59:59 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[Git]]></category> <category><![CDATA[《Got Git》]]></category> <category><![CDATA[版本控制]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=2166</guid> <description><![CDATA[
暂存区（stage, index）是 Git 最重要的概念之一，理解了这个概念很多 Git 命令就不再那么神秘了。
今天在写这部分的内容，画了一个图，看看有没有什么问题。
理解 Git 暂存区（stage）
把上面的“实践二”从头至尾走一遍，不知道您的感想如何？—— “被眼花缭乱的 Git 魔法彻底搞糊涂了？”
—— “Git 为什么这么折磨人，修改的文件直接提交不就完了么？”
—— “看不出 Git 这么做有什么好处？”在“实践二”的过程中，我有意无意的透漏了“暂存区”的概念，为了避免用户被新概念吓坏，在暂存区出现的地方用同时使用了“提交任务”这一更易理解 的概念，但是暂存区（stage, 或称为 index）才是其真正的名称。我认为 Git 暂存区（stage, 或称为 index）的设计是  Git 最成功的设计之一，也是最难理解的一个设计。
在版本库（.git）目录下，有一个 index 文件，我们针对这个文件做一个有趣的试验。
首先我们执行 &#8220;git checkout&#8221; 命令撤销工作区中 welcome.txt 文件尚未提交的修改。
$ git checkout -- welcome.txt
$ git status -s我们通过状态输出，看以看到工作区已经没有改动了。我们查看一下 .git/index 文件，注意该文件的时间戳（19:37:44）：
$ ls --full-time .git/index
-rw-r--r-- 1 jiangxin jiangxin 112 2010-11-29 19:37:44.625246224 +0800 .git/index我们再次执行 &#8220;git <a
href="http://blog.ossxp.com/2010/11/2166/" class="more-link">阅读全部内容 &#187;</a>]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/11/2166/feed/</wfw:commentRss> <slash:comments>5</slash:comments> </item> <item><title>Gerrit 代码审核服务器的工作流和原理</title><link>http://blog.ossxp.com/2010/11/2059/</link> <comments>http://blog.ossxp.com/2010/11/2059/#comments</comments> <pubDate>Wed, 10 Nov 2010 09:27:51 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[Git]]></category> <category><![CDATA[Android]]></category> <category><![CDATA[《Got Git》]]></category> <category><![CDATA[版本控制]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=2059</guid> <description><![CDATA[谷歌 Android 开源项目在 Git 的使用上有两个重要的创新，一个是为多版本库协同而引入的 repo，这在之前我们已经详细讨论过。另外一个重要的创新就是 Gerrit —— 代码审核服务器。Gerrit 为 Git 引入的代码审核是强制性的，就是说除非特别的授权设置，向 Git 版本库的推送（Push）必须要经过 Gerrit 服务器，修订必须经过代码审核的一套工作流之后，才可能经批准并纳入正式代码库中&#8230;
6.7   Gerrit 代码审核服务器
首先贡献者的代码通过 git 命令（或 repo 封装）推送到 Gerrit 管理下的 Git 版本库，推送的提交转化为一个一个的代码审核任务，审核任务可以通过 refs/changes/&#60;change-id&#62; 下的引用访问到。代码审核者可以通过 Web 界面查看审核任务、代码变更，通过 Web 界面做出通过代码审核或者打回等决定。测试者也可以通过 refs/changes/&#60;change-id&#62; 引用获取（fetch）修订对其进行测试，如果测试通过就可以将该评审任务设置为校验通过（verified）。最后经过了审核和校验的修订可以通过 Gerrit 界面中提交动作合并到版本库对应的分支中。
在 Android 项目的网站的代码贡献流程图更为详细的介绍了 Gerrit 代码审核服务器的工作流程。代码审核工作流6.7.1   Gerrit 的实现原理
SSH 协议的 Git 服务器
Gerrit 本身基于 SSH 协议实现了一套 Git 服务器，这样就可以对 Git 数据推送进行更为精确的控制，为强制审核的实现建立了基础。
Gerrit 提供的 Git 服务的端口并非标准的 22 端口，缺省是 <a
href="http://blog.ossxp.com/2010/11/2059/" class="more-link">阅读全部内容 &#187;</a>]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/11/2059/feed/</wfw:commentRss> <slash:comments>7</slash:comments> </item> <item><title>Git 和 SVN 协同模型</title><link>http://blog.ossxp.com/2010/11/2049/</link> <comments>http://blog.ossxp.com/2010/11/2049/#comments</comments> <pubDate>Thu, 04 Nov 2010 08:07:29 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[Git]]></category> <category><![CDATA[《Got Git》]]></category> <category><![CDATA[版本控制]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=2049</guid> <description><![CDATA[第五个部分是我撰写的 GIT 图书的最重要的一个部分，这个部分马上就要收尾了，以 git-svn 作为该部分的最后一章。在Git 协同模型部分的最后，我们将会在另外的一个角度上看 Git 版本库的协同。不是不同的用户在使用 Git 版本库时如何协同，也不是一个项目包含多个 Git 版本库时如何协同，而是当版本控制系统不是 Git （如 Subversion）时，如何能够继续使用 Git 的方式进行操作。5.7   Git 和 SVN 协同模型
Subversion 会一直在商业软件开发占据主导，只要商业软件公司封闭源代码的策略不改变。对于熟悉了 Git 的用户，一定会对 Subversion 的那种一旦脱离网络、脱离服务器便寸步难行的工作模式厌烦透顶。实际上对 Subversion 的集中式版本控制的不满和改进在 Git 诞生之前就发生了，这就是 SVK。
在 2003 年（Git 诞生的前两年），台湾的高嘉良就开发了 SVK，用分布式版本控制的方法操作 SVN。其设计思想非常朴素，既然 SVN 的用户可以看到有访问权限数据的全部历史，那么也应该能够依据历史重建一个本地的 SVN 版本库，这样很多 SVN 操作都可以通过本地的 SVN 进行从而脱离网络。当对本地版本库的修改感到满意后，通过本地SVN版本和服务器的SVN版本库的双向同步将改动归并到服务器上。这种工作方式真的非常 酷。
我们不必为 SVK 的文档缺乏以及不再维护而感到惋惜，因为有更强的工具登场了，这就是 git-svn。Git-svn 是 Git 软件包的一部分，用 Perl 语言开发。它的工作原理是：将 Subversion 版本库在本地转换为一个 Git <a
href="http://blog.ossxp.com/2010/11/2049/" class="more-link">阅读全部内容 &#187;</a>]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/11/2049/feed/</wfw:commentRss> <slash:comments>3</slash:comments> </item> <item><title>Topgit 原理及安装</title><link>http://blog.ossxp.com/2010/10/2033/</link> <comments>http://blog.ossxp.com/2010/10/2033/#comments</comments> <pubDate>Thu, 28 Oct 2010 13:26:52 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[Git]]></category> <category><![CDATA[《Got Git》]]></category> <category><![CDATA[版本控制]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=2033</guid> <description><![CDATA[
针对网友 dd 对 topgit 的疑问，我将写作中的 topgit 部分章节摘录如下。关于 dd 问到 windows 如何安装，应该可以在 cygwin 的环境下安装 topgit。我暂时还没有试验，因此并不是十分确定。Windows 下的 Git 我准备专门一章加以介绍，还没有开始呢。 ;-)
后记：Topgit在Windows上部署，参见： http://blog.ossxp.com/2011/03/2392/ 。5.3.2   Topgit 原理
下面的分支图，是一个近似的 Topgit 实现图（略去了重要的 top-bases 分支）。
+---b1--M1---M3--- （特性分支B: refs/heads/t/B）
&#124;     <a
href="http://blog.ossxp.com/2010/10/2033/" class="more-link">阅读全部内容 &#187;</a>]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/10/2033/feed/</wfw:commentRss> <slash:comments>6</slash:comments> </item> <item><title>脱离 Gerrit 审核服务器，使用 repo</title><link>http://blog.ossxp.com/2010/10/2009/</link> <comments>http://blog.ossxp.com/2010/10/2009/#comments</comments> <pubDate>Mon, 25 Oct 2010 11:13:40 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[Git]]></category> <category><![CDATA[《Got Git》]]></category> <category><![CDATA[版本控制]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=2009</guid> <description><![CDATA[
Gerrit 代码审核服务器部署比较麻烦，更不要说因为 Gerrit 界面的学习和用户使用习惯的更改而带来的困难了。而且在一个固定的团队内部使用 repo 可能真的没有必要使用 Gerrit，因为团队成员都应该熟悉 Git 的操作，团队成员的编程能力都可信，单元测试质量由提交者保证，集成测试由单独的测试团队进行，即团队拥有一套完整、成型的研发工作流，Gerrit 并不适合引入。
脱离了 Gerrit 服务器，直接跟 Git 服务器打交道，repo 可以工作么？&#8230;
为了筹备中的 gitbook，我特意为 repo 增加了 repo push 的实现，效果和预期的一样好。5.6.9.3   改进的 Repo 无审核模式
前面介绍的使用 repo forall 迭代器实现无审核服务器模式下向上游提交代码，只是权宜之计，尤其是用 repo start 建立工作分支要求和上游一致，实在是有点强人所难。
我改造了 repo，增加了两个新的子命令 repo config 和 repo push ，让 repo 可以脱离 Gerrit 服务器直接向上游提交。代码托管在 Github 上: http://github.com/ossxp-com/repo 。下面简单介绍一下如何使用改造之后的 repo。5.6.9.3.1   下载改造后的 repo 引导脚本
建议使用改造后的 repo 引导脚本替换原脚本，否则在执行 repo init 命令需要提供额外的 &#8211;no-repo-verify 参数，以及 &#8211;repo-url <a
href="http://blog.ossxp.com/2010/10/2009/" class="more-link">阅读全部内容 &#187;</a>]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/10/2009/feed/</wfw:commentRss> <slash:comments>3</slash:comments> </item> <item><title>关于限制低版本 Subversion 写操作问题的回复</title><link>http://blog.ossxp.com/2010/10/2000/</link> <comments>http://blog.ossxp.com/2010/10/2000/#comments</comments> <pubDate>Wed, 20 Oct 2010 10:23:37 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[Subversion]]></category> <category><![CDATA[版本控制]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=2000</guid> <description><![CDATA[有网友提问：
我在百度文库中看到贵公司发表的一篇文章《开源版本控制SVN 树冲突、目录丢失问题及解决机制探讨》。在文中有提到一个事情是，可以在svn的hook中设置禁止低于某版本的客户端提交操作，不知道具体的脚本是如何实现，还请指教，谢谢。
另外关于svn mergeinfo的问题，对于刚刚创建完的mergeinfo信息是纯在的，但是在开发过一段时间后，这个信息就丢失了，导致在合并的时候出现找不到祖先的错误。（备份库中的mergeinfo信息还是存在的）。不知道这个问题的发生时什么原因呢？
我认为并非因为有人使用了低版本（&#60;1.5）的 SVN 客户端导致了 svn:mergeinfo 属性的丢失。因为低版本的 SVN 客户端，不了解 svn:mergeinfo 属性，又怎么能够会删除该属性呢？
使用低版本 SVN 客户端的副作用主要是在执行 merge 的过程中，不能将合并操作记录在 svn:mergeinfo 中，而不是会删除 svn:mergeinfo 属性。
实际上找到罪魁祸首很容易，因为 svn:mergeinfo 是受版本控制的属性，可以通过 svn log 命令查到何时，何人，何故删除了 svn:mergeinfo 属性。只需要执行下面的命令：
$ svn log -v  PATH/TO/MERGE/ROOT/DIR提到的钩子，对于你的情况：配置邮件通知，及时获取版本库变更通知。
修改 post-commit 和 post-revprop-change 钩子脚本，在有代码/版本控制的属性/非版本控制的属性被修改的时候，发送邮件通知
禁止低版本客户端对 SVN 版本库执行写操作
修改 start-commit 脚本。在 SVNBOOK 中有详细的说明。
你也可以参照我写的 pySvnManager 项目，不过其中的钩子脚本为了支持图形化配置，比较复杂。
http://pysvnmanager.svn.sourceforge.net/viewvc/pysvnmanager/trunk/pysvnmanager/hooks/init/hook1.5/start-commit?revision=176&#38;view=markup]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/10/2000/feed/</wfw:commentRss> <slash:comments>0</slash:comments> </item> <item><title>Android 代码工作区转换为 Android 的Git库镜像</title><link>http://blog.ossxp.com/2010/10/1992/</link> <comments>http://blog.ossxp.com/2010/10/1992/#comments</comments> <pubDate>Fri, 15 Oct 2010 08:29:32 +0000</pubDate> <dc:creator>蒋 鑫</dc:creator> <category><![CDATA[Git]]></category> <category><![CDATA[Android]]></category> <category><![CDATA[《Got Git》]]></category> <category><![CDATA[版本控制]]></category><guid
isPermaLink="false">http://blog.ossxp.com/?p=1992</guid> <description><![CDATA[最近的一段时间博客更新的会比较慢，因为在筹划一本关于 Git 的书。今天将其中的一节贴在这里。
Android 在版本库的管理上有两个重要的发明，一个是 repo ，用来管理 160 多个 git 代码库，另外一个是 Gerrit 代码审核服务器和基于 ssh 的 Git 服务器。因为 Android 代码库非常大，大约 1.6 GB，在开发团队的局域网内建立一个 Android 服务器镜像几乎是必须的。如果在以工作区方式同步 Android 代码后，想转换为镜像模式，repo 没有提供这样的能力。我在书中特意用一节来介绍如何 。。。5.6.9   从 android 的工作区到代码库镜像
当执行 repo sync 命令将 android 众多的版本库克隆到本地后，各个项目在工作区中的部署和实际在服务器端的部署是不同的。这个在之前介绍 repo 的索引库机制的时候，就已经介绍过了。
当 repo 工作区使用不带 &#8211;mirror 的 repo init -u 初始化并完成同步后，如果再次执行 repo init 并附带了 &#8211;mirror 参数，repo 会报错退出：&#8221;fatal: &#8211;mirror not supported on existing client&#8221;。实际上 <a
href="http://blog.ossxp.com/2010/10/1992/" class="more-link">阅读全部内容 &#187;</a>]]></description> <wfw:commentRss>http://blog.ossxp.com/2010/10/1992/feed/</wfw:commentRss> <slash:comments>2</slash:comments> </item> </channel> </rss>
<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Minified using disk
Page Caching using disk (user agent is rejected)
Database Caching 5/13 queries in 0.003 seconds using disk

Served from: blog.ossxp.com @ 2012-02-10 18:53:41 -->
