日志标签 Git

安装了 etckeeper，用于维护 /etc 下配置文件的变更。实际上 /etc 目录本身已经是一个 git 库了
如果在 gistore 任务建立前，/etc 目录已经 git 化，则不能有效的对 /etc 进行备份
某个备份数据的目录，被人为的 git 化。这可能是在 hacking 时遗留的 git 库
我在改动服务器的某些数据（如界面模板等），经常将目录 git 化，然后再修改/比较/提交

如果不能有效的对 git化的备份目录进行备份，肯定会收到惩罚。

在最早的实现中，只是在备份之后的后处理（post_check）查找以 git 子模组方式添加的目录，并打出相应的警告信息。如何能够自动进行处理，一直排在工作队列中，昨天晚上开始了修改。

检查子模组

首先要找出哪些目录是以子模组方式添加的。最开始想到了从状态中找出 AM 标识的子模组，进行修改，但是存在问题：1. 添加没有变更的git化的目录，不会显示为 AM（添加且含修改），而显示为 A（添加）。2. 不能有效的发现 gistore 版本库中已经提交数据中以 git 子模组方式添加的目录。

于是采用分析 git submodules status 命令的输出，确定子模组。不过这个命令需要多次迭代执行（遇到无 .submodules匹配报错退出），才能找到所有的子模组。

重新以普通目录和文件方式添加子模组

首先删除已经提交的按照子模组方式保存的目录，重新添加不能直接添加子模组目录，否则仍会按照子模组方式添加。采用的方法是：

删除已经按照子模组方式添加的目录
git –git-dir=repo.git rm –cached sub/module …
在子模组目录下创建一个临时文件，并添加该临时文件
git –git-dir=repo.git –work-tree=run-time add sub/module/<TMPFILE>
对子模组目录执行添加操作
git –git-dir=repo.git –work-tree=run-time add sub/module
别忘了删除临时文件
git –git-dir=repo.git –work-tree=run-time rm sub/module/<TMPFILE>
迭代执行，直到没有子模组发现为止

Gistore 版本升级为 0.2.3，在服务器上重新安装和执行，将原来子模组方式添加的目录重新纳入备份中，放心了。

Gistore 应用：备份博客数据

我们在公司服务器上创建了一个名为 wordpress 的任务，备份 wordpress 数据库导出文件，wordpress 配置文件，wordpress 插件目录，wordpress 上传图片及附件。
将 wordpress 任务的 git 库，加入 git 服务器中，并设置权限
每个有权限的公司员工，都可以使用 git 命令克隆/同步公司服务器上的 wordpress 版本库，将博客数据保存下来

Gistore, Git, 备份

Gistore（基于 git 的数据备份软件）升级至 0.2.x

7月29日

由蒋鑫发表在 Git

没有评论

在 10年1月份的一篇 Gistore 发布声明的博客中，我介绍了我们自己开发的一个用户数据备份的小工具 Gistore。

是什么原因让我们开发备份工具呢？这是因为：

我们公司的数据备份的需要
客户数据备份需要更好用的软件
rdiff-backup 和 flexbackup 的备份方案不够好

实际上 rdiff-backup 用做数据备份，已经足够好了，你可以从我们公司的维基中看到 rdiff-backup 的使用方法：

《存储可靠性、数据备份和恢复》

但是 rdiff-backup 的解决方案的问题是：

命令难记，包括我自己在数据恢复的时候还要一遍一遍的查阅文档
之所以命令难记，实际上是因为备份工具本身的使用率很低，只有在灾难恢复时候会用到，所以命令不熟悉是一定的。
数据的异地镜像比较复杂，需要引入其它工具

为什么不用 Git 开发一款工具呢？

Git 的命令天天在用，实在是太熟悉了
Git 的数据同步太方便了，在同步过程能够实时查看进度

此次 Gistore 升级，解决了半年多的使用过程中积累问题，并且增加了易用性。

阅读全部内容 »

Gistore, Git, 备份

Git 服务器软件 gitosis 的改进

7月20日

由蒋鑫发表在 Git

没有评论

群英汇内部的 Git 服务器使用 gitosis 软件架设，能够实现针对版本库的授权，以及基于公钥的安全的无口令的版本库访问。

在 Gitosis 的使用过程中，我们根据需要对其进行了改进，以满足我们对授权和版本库管理上的需求：

增加了管理员角色，只有管理员才能够创建版本库
- 原来的实现只有 readonly 和 writable 两种权限，其中 writable 可以创建版本库。
- 我们权限分为三级：read/write/admin。拥有管理员(admin)权限，可以创建版本库，并自动具有读(read)写(write)权限
- 拥有写(write)权限也包含读(read)的权限
- 如果没有设置权限，禁止范围版本库
版本库匹配支持通配符，这样在授权的时候，可以用通配符为某个目录下的所有代码库授权
- 原有的实现，在配置文件中必须写入完整的版本库名称（路径）
- 当我们增加了管理员的概念后，增加通配符，就可以为特定的命名空间进行授权，而无须因为某个管理员要建库，还要修改授权文件
- 有了通配符后，读写权限的设置也更为简单。
- 通配符支持？，* 和 **。问号匹配一个字符，* 匹配任意字符（路径/字符除外），两个星号匹配包括路径分割符在内所有字符
增加了版本库路径映射的可用性。版本库路径映射在代码库重构中非常有用
- 增加了正则表达式匹配路径和替换映射
- 在权限检查的路径命中之后也检查路径映射，可以减轻错误配置的可能性
创建版本库只有写操作才进行，读操作不创建版本库
- 原来的实现支持即时创建版本库，在读取一个不存在的版本库时自动创建
- 读操作创建库，这会导致很多因为版本库克隆时路径输入错误导致错误建库
- 我们更改后，只允许在写版本库时并且具有 admin 权限才初始化新的代码库
版本库名称中允许出现中文（UTF-8）
- 基本上版本库命名都用英文字符，不过有个客户提出来支持中文版本库，我们就添加了这个支持

下面，拿一个配置文件来说明：

阅读全部内容 »

Git, Gitosis, 版本控制

topgit 分支的图形化显示

6月18日

由蒋鑫发表在 Git

3条评论

使用 Git + topgit 做版本控制，当 topgit分支（功能分支）非常多并且相互依赖比较复杂时，非常需要有一个直观的图形化的分支依赖图。

联想到我们使用 git 经常用到的 git glog 命令输出，如果 topgit 分支图能够有类似的显示就太好了：

| | * t/unittest
| |/
| *---.   t/message_localize
| |\ \ \
| * | | | t/auth_log_for_fail2ban
|/ / / /
| * | | t/factor_invite
|/ / /
| * | t/factor_ldap
|/ /
| * t/include_macro_for_templates
| * t/multi_language
|/
* master

正在冥思苦想如何实现时，忽然发现 topgit 的 tg-summary 中原来已经有图形输出的实现，是借用 graphviz 工具进行图形化输出…