最近做的一个 go 语言的项目需要频繁读写 git config 文件，一些看似现成的解决方案并不能满足需要：不考虑调用外部命令git config，因为在 Windows 平台性能差。不考虑libgit2，因为会给静态编译和发布带来麻烦。在 github 上找到一个能够解析 git config 文件的项目goconfig，该项目的代码直接从 Git 项目的git/config.c移植过来，可以确保兼容性。但是这个项目只是一个半成品，因为：不支持多值配置项。Git 的很多设置实际上是多值配置项，例如：push.pushOption、remote..fetch等。不支持配置文件嵌套，即不支持通过include.path指令包含其他配置文件，而这在我们要开发的应用中至关重要。不支持配置文件继承（多级配置）。Git 在读取一个配置项时，会依次读取系统级配置（/etc/gitconfig）、用户全局配置（$HOME/.gitconfig）、仓库级配置文件（.git/config）、嵌套的配置文件（include.path指向的配置文件）。从优先级上看，仓库级配置文件高于全局配置，更高于系统级配置。不支持写配置文件。于是派生了一个项目到jiangxin/goconfig，实现了上述特性。增加多值配置特性实际上 Git 配置项，无论单值（如user.name），还是多值（如remote..f ...继续阅读 (7)

1. 问题现象Git 2.8.0 版本即将发布，今天把本地的 Git 版本升级到2.8.0-rc0，结果悲剧了。所有使用 HTTP 协议的公司内部 Git 仓库都无法正常访问！在确认不是网络和公司 Git 服务器问题之后，自然怀疑到了 HTTP 代理。果然清空了http_proxy环境变量后，Git 命令工作正常了：http_proxy= git ls-remote http://server.name/git/repo.git然而一旦通过http_proxy=bad_proxy环境变量设置了一个错误的代理，即便通过no_proxy=*期望绕过代理，Git 2.8.0 却无法正常工作：$ http_proxy=bad_proxy no_proxy=* git ls-remote http://server.name/git/repo.git fatal: unable to access 'http://server.name/git/repo.git/': Couldn't resolve proxy 'bad_proxy'可是我记得升级之前 Git 工作是正常的啊！于是在 Git 2.7.0 下进行了尝试。将版本切换到v2.7.0，编译安装 Git。（注意一定要安装，而不是执行当前目录下的 Git。这是因为该命令执行过程中会依次调用git-ls-remote和git-remot ...继续阅读 (20)

1. 问题现象Git 2.8.0 版本即将发布，今天把本地的 Git 版本升级到2.8.0-rc0，结果悲剧了。所有使用 HTTP 协议的公司内部 Git 仓库都无法正常访问！在确认不是网络和公司 Git 服务器问题之后，自然怀疑到了 HTTP 代理。果然清空了http_proxy环境变量后，Git 命令工作正常了：http_proxy= git ls-remote http://server.name/git/repo.git然而一旦通过http_proxy=bad_proxy环境变量设置了一个错误的代理，即便通过no_proxy=*期望绕过代理，Git 2.8.0 却无法正常工作：$ http_proxy=bad_proxy no_proxy=* git ls-remote http://server.name/git/repo.git fatal: unable to access 'http://server.name/git/repo.git/': Couldn't resolve proxy 'bad_proxy'可是我记得升级之前 Git 工作是正常的啊！于是在 Git 2.7.0 下进行了尝试。将版本切换到v2.7.0，编译安装 Git。（注意一定要安装，而不是执行当前目录下的 Git。这是因为该命令执行过程中会依次调用git-ls-remote和git-remot ...继续阅读 (27)

能够写出漂亮代码的程序员就是有品味的程序员么？还不够。品味来自于每一个细节，有品位的程序员会把每一次提交做小、做好、做对，尽量做到整个开发的过程的无可挑剔，这样才够逼格，才可以称为有品位。熟练使用 Git，会让程序员更有品味。提交做小写小提交就是将问题解耦：“Do one thing and do it well”。开源软件的提交通常都很小，每个提交只修改一个到几个文件，每次只修改几行到几十行。 在你的仓库里执行下面的命令，可以很容易地统计出来每个提交的修改量。$ git log --no-merges --pretty="" --shortstat可是在开发过程中，程序员一旦进入状态，往往才思如泉涌，写出一个大提交。比如我又一次向 Git 贡献代码时， 提交还不算太大，就被 Git 的维护者 Junio 吐槽，要我拆分提交，便于评审：TODO那么如何将提交拆分为若干个小提交呢？先以拆分最新的提交为例，可以如下操作：重置到上一次提交。$ git reset HEAD^通过补丁块拣选方式选择要提交的修改。$ git add -p修补提交。$ git commit --amend添加剩余的代码修改，并提交。$ git add -u $ git commit如果遇到复杂情况，难以通过补丁块拣选（git add -p）的方式修改提交，也可以直接编辑文件，删除不希望此次提交的修改，再执行： ...继续阅读 (187)

SVN 本身提供了如下版本库整理工具：svnadmin dumpsvndumpfilter includesvndumpfilter excludesvnadmin load其中svnadmin dump将整个版本库或部分提交导出为一个导出文件；svndumpfilter基于配置项的路径（SVN 1.7的 svndumpfilter 还支持通配符路径）对导出文件进行过滤， 过滤结果保存为新的导出文件；svnadmin load将导出文件导入到另外的版本库中， 导入过程有两个选择——维持路径不变，或导入到某个路径之下。相对于Git提供的用于整理提交的git filter-branch命令，SVN的版本库整理工具能做的实在不多。 而且SVN的相关工具容错性太差，操作过程经常被中断，可谓步步惊心。最近遇到的一个案例，需要将两个 SVN 版本库（bar 和 baz）的全部历史导入到另外一个 SVN 版本库（foo）中。 并要求版本库 bar 和 baz 的目录结构统一采用 foo 中规定的目录结构。面对要导入的近 20GB 数据（绝大部分是Word、Excel、PDF文档）， 决定采用Git提供的工具集进行SVN版本库整理。整理过程和过程中开发的脚本记录如下。将 bar 和 baz 版本库转换为本地Git库以 bar 为例，将两个版本库（bar 和 baz）转换为本地的 Git 版本库，以 ...继续阅读 (19)

Git 项目（git.git）有着别具一格的测试框架，使用 shell 脚本开发测试用例， 写起测试用例来一点都感觉不到拖泥带水，就和在 shell 环境中手工测试一样。 最近在重构 Gistore 项目时复用了这一 Git 项目特有的测试框架，对 Gistore 进行测试。愿这一测试框架可以被更多的项目借鉴。git.git 的测试框架Git 项目主要采用了 C 语言，同时还包含了 Perl、Shell 等多种开发语言的项目。 Git 项目的测试并没有采用常见的类似 JUnit 测试框架，而是采用自创的测试框架， 由 Junio Hamano 在 2005 年用 shell 脚本封装而成。在这个框架下， 写测试用例和测试套件自然也是使用 shell 脚本语言，写起测试用例来就和手工在 shell 环境下针对命令行测试没什么两样，写测试用例的过程很是“享受”。还一个原因可能是 shell 脚本语言几乎融入了每一个 *nix 开发者的血液中。总之这个测试框架用起来非常顺手。在 Git 项目的t/目录下存在成百上千个以 "t<四位数字>-<测试套件名称>.sh" 格式命名的文件。每一个 Shell 脚本文件即是一个测试套件，其中包含多个测试用例。若打开这些 shell 脚本，会注意到每一个测试套件（t<四位数字>-<套件名>.sh）都包含相似的结构。# 引入测试套件函数库 . ./tes ...继续阅读 (24)

微博中关于《Git Community Book》（Git社区书）本地化的帖子，使我想起久未造访的Git官网， 却吃惊地发现Git官网已遭G\F\W认证。值此“两会”召开、古月三昷卸任之季，G\F\W居然再次做出如此这般非和谐之举， 不啻于继股市暴跌后又一记对“十年和谐”响亮的耳光。《墙不住的Git官网》这篇文章送给那些仍在攒钱买房，尚无闲钱购置境外主机以搭建VPN、SSH，也不会使用 goagent 的码农。Git官网的维护者是 GitHub 的 Scott Chacon，他也是Git社区书的主要维护者和《ProGit》的作者。新设计的Git官网不但重新设计了Git的Logo，还将《ProGit》这本书贡献到官网，取代Git社区书成为官网上的官方教程。 （毕竟一人维护两套书负担太重，而且不小心会被人误解为 Copy & Paste。）Git官网的源代码托管在GitHub，已由旧版网站地址更换到新的地址：https://github.com/github/gitscm-next/新网站基于 Rails 构建，默认使用 sqlite 本地数据库。其中 HTML 格式的 Git 手册、ProGit电子书的源代码并不在此版本库中， 而是要执行相应的 rake 任务，从Git版本库和 ProGit版本库中获取内容、编译并保存到 sqlite 数据库中。 下面介绍一下如何在本地搭建Git官网 ...继续阅读 (21)

在为深圳某客户提供研发管理平台实施和培训的项目中，应客户要求提供了两套问卷试题。背负考核任务去学习，团队转换配置管理工具的效果自然会更好吧。问卷A最早公布于我的博客，并由@非专业IT民工给出了答案和详尽的解释：http://loveky2012.blogspot.jp/2012/08/git-knowledge-test-answer.html（翻墙梯需自备）既然问卷A已经没有了神秘感，就把问卷B也拿出来。您可以通过克隆版本库：$ git clone git://github.com/gotgit/git-quiz.git或者直接访问网址：http://www.worldhello.net/git-quiz/看到完整的测试题。问卷B和问卷A的相似度非常高，就请保留一些神秘感吧，好让问卷B能够承担一些自测功能。公开问卷B的答案是毫无必要和没有技术含量的。BTW，问卷的设计是在北京到深圳的飞机上匆匆完成的，对我来说为错误答案而凑数是最花脑筋的，不严谨之处敬请谅解。 ...继续阅读 (28)

在 Google Group （需翻墙）上网友提了一个问题：“Topgit 本地特性分支删除后，如何清理远程版本库中相应分支？”这是一个非常好的问题，我也曾遇到，一直是以手工清除远程分支（及 Topgit 跟踪分支）的。$ git push origin :t/feature-branch $ git push origin :top-bases/t/feature-branch好吧，为什么不“懒惰”一点，把清理远程版本库对应分支的工作写在 Topgit 代码中呢？于是写了一个补丁， 见：https://github.com/ossxp-com/topgit/blob/master/debian/patches/t/delete-remote-branch.diff同步删除远程版本库的 Topgit 特性分支和跟踪分支只完成了硬币的一面，另外一面是当远程版本库的 Topgit 特性分支和跟踪分支被他人删除后，如何本地获知？直觉告诉我只要把tg-remote.sh代码中的git fetch命令换做git fetch --prune即可。 可是一试之下，大失所望，竟然将本地版本库所有refs/remotes/origin/top-bases/下的引用全部删除！ 难道这是git fetch --prune的 Bug？重新编译Git（去掉 -O2 增加 -ggdb 编译参数），以便用gdb ...继续阅读 (56)

在版本控制系统的选型上，是选择Git还是SVN？对于开源项目来说这不算问题。使用Git极大地提高了开发效率、扩大了开源项目的参与度、 增强了版本控制系统的安全性，选择Git早已是大势所趋。但对于企业用户来说这个决心不太好下。部分原因是出于对Git的误解，部分原因是尚不了解 Git到底能给项目管理带来什么好处。希望本文能对您项目的版本控制系统选型提供帮助。对SVN的迷信和对Git的误解误解1：SVN只能检出（checkout）一个版本（revision）的代码，而Git却可以脱库！这个误解是如此普遍，简直成了SVN在企业市场中封杀Git的尚方宝剑。其实稍微思考一下 这个谣言就很难传播。既然SVN能够读取授权访问的文件的每一个版本，那么就能够重组这些版本， 进而实现对版本库的完整复制。即SVN也可以脱库。SVN脱库的工具SVN本身就提供：svnsync。这个工具主要用于SVN的版本库镜像。 例如将版本库http://host.name/svn/repo脱库到本地的dump目录，命令如下：$ svnadmin create dump $ printf '#!/bin/sh\nexit 0\n' > dump/hooks/pre-revprop-change $ chmod a+x dump/hooks/pre-revprop-change $ svnsync init file://$( ...继续阅读 (22)

Git 1.7.10 对git merge提供了一个改进，而这个改进可能会带来兼容性问题， 会导致某些依赖git merge自动完成的工具受到影响。而 Topgit 就中招了。Junio 的一篇博客专门对这个问题做了描述。简单的说就是Git 1.7.10 起， 执行git merge时，成功的合并不会使用默认的（没有意义的）提交说明自动提交， 而是会打开一个编辑器等待用户输入提交说明。这个改动会使得调用git merge的工具在执行时被打断。Topgit 的tg update等命令即受此影响。这个GitHub上的提交即用于解决此问题：From: Jiang XinSubject: [PATCH] No stop to edit for the new merge behavior of git In Git 1.7.10, Merge will stop and wait for a merge commit log. This backward-incompatible improvement that will break topgit. To fix it, just export GIT_MERGE_AUTOEDIT=no. See: http://git-blame.blogspot.jp/2012/02/anticipating-git-1710.html Sig ...继续阅读 (15)

在深圳做Git培训和项目管理软件实施，这是一份Git培训的测验题，通过率不高。因为不合格的还要重考，答案就不公布了。单项选择题如果提示提交内容为空、不能提交，则最为合适的处理方式是：_____a) 执行git status查看状态，再执行git add命令选择要提交的文件，然后提交。b) 执行git commit --allow-empty，允许空提交。c) 执行git commit -a，提交所有改动。d) 执行git commit --amend进行修补提交。如果把项目中文件hello.c的内容破坏了，如何使其还原至原始版本？ _____a)git reset -- hello.cb)git checkout HEAD -- hello.cc)git revert hello.cd)git update hello.c修改的文档meeting.doc尚未提交，因为错误地执行了git reset --hard导致数据丢失。丢失的数据能找回么？ _____a) 不能。执行硬重置使工作区文件被覆盖，导致数据丢失无法找回。b) 能。可以通过git checkout HEAD@{1} -- meeting.doc找回。c) 不确定。如果在重置前执行了git add命令将meeting.doc加入了暂存区，则可以在对象库中处于悬空状态的文件中找到。d) 不能。因为未提交所以无法找回。仅将工 ...继续阅读 (23)

Git从版本1.7.5（2011年4月）即开始国际化/本地化（i18n/l10n）的准备工作，到版本1.7.8正式完成了Git国际化/本地化框架和基础设施的工作。 参见提交 5e9637c。针对部分语种的本地化工作已经开始，最早会在 Git 1.7.10 版本开始提供中文的本地化支持。Git中文本地化注意事项Git本地化（包括中文本地化）的协同方式不同于Git项目本身，不使用邮件列表进行提交评审，而是通过GitHub的协同工具来完成，这在Git邮件列表中有专门的讨论：Git官方邮件列表。最终确定的工作流程参见Git源码中的文件po/README。中文本地化工作流程中文本地化的协同版本库为：https://github.com/gotgit/git-po-zh_CN/，以下简称git-po-zh_CN。 如果您对翻译有修改或补充，请参照如下工作流程。使用 GitHub 的 Fork 功能从git-po-zh_CN派生项目。从您个人派生的版本库克隆。如：git clone git@github.com:/git-po-zh_CN.git cd git-po-zh_CN修改po/zh_CN.po文件，补充和完善翻译内容，并提交。edit po/zh_CN.po ... git add -u git commit将您的提交推送至GitHub（您的派生版本库）。git push使用G ...继续阅读 (31)

通配符版本库的删除操作在实际应用中也常常遇到，《Git权威指南》 P439 页的 ADC 相关内容需要扩展。更新如下：管理员在服务器特定目录下保存一些可执行脚本，当执行类似下面的命令时，会自动调用相应的可执行脚本。$ ssh git@server...在 Gitolite 源码的contrib/adc目录下维护了一些有用的管理员自定义命令，可以直接拿来使用。管理员为自定义命令创建目录。$ mkdir ~git/adc-bin将 ADC 脚本拷贝到该目录中。$ cp /path/to/gitolite/src/contrib/adc/* ~git/adc-bin/修改.gitolite.rc配置文件，设定$GL_ADC_PATH变量。$GL_ADC_PATH = "/home/git/adc-bin";注意：ADC 脚本可能会带来安全性问题，管理员在开发新的 ADC 脚本要尤为小心，还要注意 ADC 脚本名称不要和 Gitolite 内置的命令重名，否则会覆盖 Gitolite 相应的内置命令，导致 Gitolite 无法正常运行。常用的管理员自定义命令有：解锁版本库。版本库的创建者可以为版本库加锁和解锁。只有处于解锁状态的版本库才可以被删除。解锁版本库命令：$ ssh git@server unlock name/of/repo.git版本库加锁。版本库的创建者可以为版本库加锁和解 ...继续阅读 (27)

《Git权威指南》第一版，在介绍 Gitolite 通配符版本库的创建一节（即书 P429 页），关于创建者自定义授权的相关内容存在瑕疵，授权文件中缺乏对READERS和WRITERS的设置，在新的 Gitolite 中不能正常设置授权。本博客对相关内容进行更新。每个人创建自己的版本库授权文件如下：1 @administrators = jiangxin admin 2 3 repo users/CREATOR/[a-zA-Z].* 4 C = @all 5 RW+ = CREATOR 6 RW = WRITERS 7 R = READERS @administrators关于授权的说明：第4条指令，设置用户可以在自己的名字空间（/usrs//）下，自己创建版本库。例如下面就是用户dev1执行git push命令在Gitolite服务器上自己的名字空间下创建版本库。dev1$ git push git@server:users/dev1/repos1.git master第5条指令，设置版本库创建者对版本库具有完全权限。即用户dev1拥有对其自建的users/dev1/repos1.git拥有最高权限。第7条指令，让管理员组@administrators的用户对于users/下用户自 ...继续阅读 (17)

说明：Gitlite 2.1版本库对版本库镜像改动较大，几乎完全重写，导致《Git权威指南》P436-P437 两页内容过时。更新如下。Git 版本库控制系统往往并不需要设计特别的容灾备份，因为每一个Git用户就是一个备份。但是下面的情况，就很有必要考虑容灾了。Git 版本库的使用者很少（每个库可能只有一个用户）。版本库克隆只限制在办公区并且服务器也在办公区内（所有鸡蛋都在一个篮子里）。Git 版本库采用集中式的应用模型，需要建立双机热备（以便在故障出现时，实现快速的服务器切换）。可以在两台或多台安装了Gitolite服务的服务器之间实现版本库的镜像。数据镜像的最小单位为版本库，对于任意一个Git版本库可以选择在其中一个服务器上建立主版本库（只能有一个主版本库），在其他服务器上建立的为镜像库。镜像库只接受来自主版本库的数据同步而不接受来自用户的推送。启用钩子将 Gitolite 部署目录下钩子post-receive.mirrorpush重命名为post-receive，并执行gl-setup命令为所有 Gitolite 控制下的版本库安装必须的钩子脚本。Gitolite服务器命名首先要为每一台服务器架设Gitolite服务，并建议所有的服务器上Gitolite服务都架设在同一用户（如git）之下。如果Gitolite服务安装到不同的用户账号下，就必需通过文件~/.ssh/conf ...继续阅读 (24)

说明：正如Gitolite 官网所言，虽然从客户端发起安装很酷，也曾经是唯一的安装方式， 但是管理员维护两套不同公钥让技术支持不堪重负，最终在 Gitolite 2.1 版本取消了这种由客户端发起安装的安装方式， 这也让书中近三页纸（P415-P417）报废。本篇博客对 Gitolite 的安装过程做了更新，将在《Git权威指南》第二版中替换原有内容。安装Gitolite（2.1版本）对服务器的要求是：Git版本为1.6.6或以上。Unix或类Unix（Linux, MacOS等）操作系统。服务器开启SSH服务。和其他Unix上软件包一样Gitolite既可通过操作系统本身提供的二进制发布包方式安装，也可通过克隆Gitolite源码库从源代码安装Gitolite。注意：老版本的Gitolite提供了一种从客户端发起安装的模式，但该安装模式需要管理员维护两套不同公钥/私钥对（一个公钥用于无口令登录服务器以安装和更新软件，另外一个公钥用于克隆和推送 gitolite-admin 版本库），稍嫌复杂，在2.1之后的Gitolite取消了这种安装模式。安装之前Gitolite搭建的Git服务器是以SSH公钥认证为基础的，无论是普通Git用户还是Gitolite的管理员都通过公钥认证访问Gitolite服务器。在Gitolite的安装过程中需要提供管理员公钥，以便在Gitolite安装完毕后 ...继续阅读 (21)

猜一猜《Git权威指南》最早完成的是哪一章？$ git log master@{2010-10-02} --stat -3 commit e858fe15c8e94200ccdd8c30791a50e99d3f845c Author: Jiang XinDate: Thu Sep 30 20:12:52 2010 +0800 gitolite refex authz. src/zh/book/05-git-server/050-gitolite.rst | 233 ++++++++++++++++++++++++---- 1 files changed, 206 insertions(+), 27 deletions(-) commit ede6ce1aaf1c5ff5eb66ceeab5489252389c9f23 Author: Jiang XinDate: Wed Sep 29 19:01:22 2010 +0800 gitolite acl examples. src/zh/book/05-git-server/050-gitolite.rst | 79 +++++++++++++++++++++++----- src/zh/book/preface.rst | 2 + 2 fil ...继续阅读 (21)

今天完成了博客平台的迁移，将原来用 WordPress 维护的公司博客迁移到新的域名：http://www.worldhello.net。新博客平台的特点及优势用 Markdown 标记语言撰写博客。相比 HTML，Markdown 标记语言可以写出“所见即所得”的源文件，编辑更加简单方便。博客采用纯静态页面，提高了博客网站吞吐量。使用Jekyll将 Markdown 撰写的文档编译为博客。用 Git 做版本控制，版本库位于GitHub上。使用独立域名指向 GitHub 上的博客网站。如果查看一下新博客的独立域名，会发现其指向 GitHub。$ ping www.worldhello.net PING www.worldhello.net (207.97.227.245): 56 data bytes 64 bytes from 207.97.227.245: icmp_seq=0 ttl=49 time=447.121 ms ... $ ping gotgit.github.com PING gotgit.github.com (207.97.227.245): 56 data bytes 64 bytes from 207.97.227.245: icmp_seq=0 ttl=49 time=440.295 ms通过 JavaScript 加载Disq ...继续阅读 (23)