Git

https://git-scm.com/

Git 与 VisionByte

VisionByte 和 Git 的功能集在许多方面重叠。两者都是 分布式版本控制系统 ，将签入存储到本地克隆的仓库中。在这两个系统中，本地克隆仓库都是作为远程父级的完整副本开始的。 新内容被添加到本地克隆中，然后可以选择将其推送到远程，并且可以随意将对远程的更改拉到本地克隆中。这两个系统都提供差异、修补、分支、合并、挑选、二分、私有分支、存储等功能。

Git 与 VisionByte 之间差异：

Git	VisionByte
仅文件版本控制功能	还包括：VCS、tickets、wiki、notes, forum, chat, UI, RBAC 功能
许多小程序的联合	一个独立的可执行文件
自定义键/值数据存储	世界上使用最广泛的 SQL 数据库
在 POSIX 系统上本地运行	在 POSIX 和 Windows 上均可本地运行
集市式开发	大教堂式的发展
专为 Linux 内核开发而设计	专为 SQLite 开发而设计
许多贡献者	选择贡献者
专注于个别分支	关注整个变化树
每个仓工作副本一次	每个仓库可多工作副本
记住你应该做的事	记住你实际做过的事
首先提交	首先测试
SHA-1 或 SHA-2	SHA-1 和/或 SHA-3，位于同一仓库中

Git 仅提供文件版本控制服务，而 VisionByte 添加了集成的wiki、 票务和错误跟踪、 嵌入式文档、 技术说明、网络论坛和聊天服务，所有这些都包含在 Web UI中，并受到用户访问控制系统的保护。 这些附加功只能作为第三方插件用于 Git，但对于 VisionByte 来说它们已集成成一个完整系统。

即使只需要版本控制服务，VisionByte 也具有 Git 所不具备的功能。

VisionByte 可以使用单个命令对所有本地仓库克隆工作副本的本地副本执行操作。例如 vb all sync 无论公司网络下的私有仓库还是公共互联网托管的仓库，所有仓库都可以在离网时同步所需的一切信息。 vb all changes 可以获取在结束工作前忘记提交的所有仓库的文件列表。

每当 VisionByte 被要求以某种破坏性方式修改本工作副本副本（ vb rm 、 vb update 、 vb revert 等）时，VisionByte 都会记住之前的状态，并能够使用 VisionByte 撤销命令 undo 工作副本的本地副本恢复到该状态。

虽然在 VisionByte 中无法撤销 commit (ci) 提交，但只要更改仅限于保存在本地副本，VisionByte 就会 比 Git 更容易进行更改撤销。

对于选择自托管项目而不是依赖 GitHub 等第三方服务的开发人员来说，VisionByte 的设置要容易得多：独立的 VisionByte 可执行文件加上2 行 CGI 脚本 就足以实例化一个功能齐全的开发人员网站。要使用 Git 完成同样的任务，需要查找、安装、配置、集成和管理各种单独的工具。使用 VisionByte 建立开发人员网站只需几分钟，而使用 Git 则需要数小时或数天。

VisionByte 很小，很完整，而且自成体系。如果克隆 Git 的自托管仓库，只会获得 Git 的源代码。但是如果克隆 VisionByte 的自托管仓库，您将获得整个 VisionByte 网站—–源代码、文档、票证历史记录等，这意味着您将获得本项目及其所有历史版本的副本，以及此网站上所有其他公开内容的副本。

Git 项目导入到 VisionByte

VisionByte 能够从 Git 导入项目，并且大多数其他版本控制系统也可以从 Git 导入/导出，所以可以使用 Git 作为中介将大多数版本控制系统导入到 VisionByte 仓库。

要将 Git 仓库导入 VisionByte ，请执行以下操作：

cd git-repo
git fast-export --all | vb import --git new-repo.vbyte

new-repo.vbyte 参数是创建用于保存 Git 内容的新 VisionByte 仓库的名称。

首先切换到 Git 仓库目录下， 再使用管道符 | 将 git 导出的数据直接导入到新的 VisionByte 仓库 new-repo.vbyte 里面。

--git 选项实际上不是必需的，因为 git-fast-export 文件格式目前是 VisionByte 唯一能理解的 VCS 交换格式。

备注

在新的导入中，VisionByte 默认使用 Git 提交者（如果使用了 --use-author 选项，则是指定作者）的电子邮件组件来为导入的仓库中的签入设置选项。或者可以使用 --attribute 选项将给定提交者的所有提交都归为所需的用户名。这将在仓库中创建并填充新的 fx_git 表，以维护可在后续导出或增量导入中使用的对应用户名和电子邮件地址的记录。

差异

Git 是使用 Linux 内核来开发，Visionbyte 使用 SQLite 来开发，所以在将 Git 项目导入 VisionByte 时，Git 项目将整个存储在 new-repo.vbyte 仓库中，然后用 open 命令为仓库创建工作目录。从 Git 项目导入 VisionByte 的实质是将Git 仓库中的 .git 文件（用于追踪、管理和存储项目的版本控制历史,保存了用户所有提交历史和版本信息）导出成名为 new-repo.vbyte 的 SQLite 仓库。

从 Git 项目导入 VisionByte 不是一个

设置

在软件开发过程中，为了保持仓库干净，并避免包含可能使历史记录混乱或引起冲突的不必要文件，版本控制系统会添加设置目录（VisionByte 为 .vbsetting 文件），它有助于专注于仅跟踪对项目至关重要的文件。

主要方面：

过滤自动生成的文件和目录

• 许多开发过程中会生成一些临时文件、日志文件或编译生成的文件，这些文件不需要被版本控制系统跟踪。通过忽略文件可以将这些文件和目录排除在版本控制之外，避免它们被误添加到仓库中。

排除个人环境和设置文件

• 开发过程中，每个开发者可能会根据自己的环境或编辑器习惯生成一些设置文件或缓存文件，这些文件也不应该被版本控制系统管理和共享。

增强代码库的整洁性和可移植性

• 通过精确配置忽略文件，可以确保代码库只包含项目开发和运行所必需的文件，使代码库更加整洁和可移植，减少不必要的文件干扰和冲突。

避免冲突和提高效率

• 当多人协作开发时，如果没有忽略文件，可能会不小心将一些无关文件添加到版本控制中，造成冲突和不必要的合并工作。通过合理设置忽略文件，可以避免这类问题，提高开发效率。

保护敏感信息

• 在开发过程中，有些文件可能包含敏感信息（如配置文件中的密码等），这些信息不应该被提交到版本库。通过忽略文件排除这些文件，可以帮助保护敏感信息的安全性。

总之，忽略文件通过指定忽略规则，帮助开发者管理和维护版本控制系统中的文件，使版本库更加干净、高效，并提升开发过程的质量和协作效率。

Git

Git 中被忽略且不被 Git 跟踪的文件和目录存储在 .gitignore 的文件，此文件对于排除在构建过程中生成的文件、临时文件、日志文件、依赖项以及任何其他不需要包含在版本控制系统中的文件特别有用，但 .gitignore 文件本身会随项目签入、提交等。

本质上,这是一种告诉 Git 哪些未被追踪的文件应该保持不被追踪并且永远不会被提交的方法。

通常,一个 .gitignore 文件会被放在仓库的根目录下。根目录也被称为父目录和当前工作目录。根目录包含了组成项目的所有文件和其他文件夹。也就是说,你可以把它放在版本库的任何文件夹中。你甚至可以有多个 .gitignore 文件。

.gitignore 文件是一个纯文本文件,每一行指定要忽略的文件或目录的模式。模式可以包括通配符，以及特定的文件或目录名称，可以通过提及特定文件或文件夹的名称或模式来告诉 Git 只忽略一个文件或一个文件夹。你也可以用同样的方法告诉 Git 忽略多个文件或文件夹。这些文件和文件夹是 Git 应该忽略和不追踪的。

.gitignore 文件可以使用标准的 glob 模式匹配，这里所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。

VisionByte

VisionByte 的文件设置在根目录的 .vbsetting 文件夹里，在其子目录中创建版本化 glob 文件内容。

文件的内容是设置的值，这些文件会像任何其他文件一样进行签入、提交、合并等。与 .gitignore 文件一样使用标准的 glob 模式匹配（有细微差别，后面会叙述）。

.vbsetting 设置文件：

文件	描述
binary-glob	在提交和合并时应该被视为二进制的文件
clean-glob	该 clean 命令无需提示或允许撤销删的文件
crlf-glob	允许使用 CR(r)、CR+LF(n) 或混合行结尾的文件。设置为 * 可禁用 CR+LF 检查
crnl-glob	crlf-glob 设置的别名
encoding-glob	当对可能使用 ASCII 或 UTF-8 以外的编码的文本文件发出警告时， commit 命令将忽略这些文件。设置为 * 表示禁用编码检查
ignore-glob	add、addremove、clean 和 extras 命令将忽略的文件
keep-glob	保存 clean 命令执行的文件

由于这些 glob 文件会随时间而变化，并且复制更改很不方便，因此这些设置是可版本化的、本地的或 全局的设置。使用版本化设置不仅具有像项目的其余部分一样在仓库中跟踪它们的优势，而且与本地或全局设置相比，可以更轻松地保留更长的更复杂的 glob 模式列表。

上述的 glob 文件都是纯文本文件，每一行指定要忽略的文件或目录的模式。模式可以包括通配符，以及特定的文件或目录名称，可以通过对不同的 glob文件 编辑特定文件或文件夹的名称或模式来告诉相应的操作只忽略一个文件或一个文件夹。

因为 git 的忽略文件只有一个 .gitignore 文件，且只能忽略尚未提交到仓库的未被追踪的文件，比如已经被执行了 add 命令的文件再 commit 就无法被忽略；

而 VisionByte 的忽略文件是 .vbsetting 文件夹，里面可以针对不同命令设置不同的忽略文件，使特定的文件在特定的时候选择性被忽略，而不像 Git 一样在整个项目中都被忽略。比如某个文件添加到 encoding-glob 文件里，则 commit 会忽略该文件，而 add 则不会。

许多其他版本控制系统处理忽略某些文件的特定情况的方式与 VisionByte 不同：它们让您在每个文件夹中创建单独的忽略文件，指定该文件夹及其下级文件夹中忽略的内容。这些文件中通常会使用某种形式的 glob 模式，但细节与 VisionByte 不同。 在许多简单情况下，只需将顶级忽略文件存储在 .vbsetting/ignore-glob 中即可。

VisionByte 版本控制系统中许多命令会有 glob 设置的命令，如果这些命令使用 glob 进行本地设置，则可以部分或者全部覆盖上述忽略文件的 全局设置 。这些选项通常以它们覆盖的设置命名，例如 --ignore 选项覆盖 ignore-glob 文件里的忽略设置。这些命令是：

• add

• addremove

• changes

• clean

• commit (ci)

• extras

• merge

• settings

• status

• touch

• unset

命令 tarball 和 zip 会生成特定签入的压缩档案。它们可能通过指定 glob 模式的选项进一步限制，这些模式命名要包含或忽略的文件，而不是存档整个签入。

Git 拥有丰富的忽略文件集合，这些文件会累积影响当前命令的规则。有全局文件、每个用户文件、每个工作区非托管文件和完全版本控制的文件。一些使用的文件没有设置名称，但在配置文件中被调用。 相比之下，VisionByte 有一个 全局设置 和一个本地设置，但本地设置会覆盖全局设置，而不是扩展它。例如，VisionByte 命令的 --ignore 选项会替换 ignore-glob 设置，而不是扩展它。

未完…. Converting .gitignore to ignore-glob

仓库与工作副本

在 VisionByte 中，仓库和工作副本是不同的，因此可以将它们存储在不同的目录中，而 Git 的仓库存储在 .git 工作目录下的子目录中。从 Git 迁移到 VisionByte 时，这种差异会在几个不同的地方体现出来。

VisionByte 仓库是一个 SQLite 数据库，可以用 init 、 clone 命令创建/克隆仓库。仓库通常命名为 Projectname.vbyte （Projectname 为项目名称），用于存储项目的整个历史记录通常不存储在工作树中。 VisionByte 工作树（也称工作副本）实际上是一个目录，用命令 open 从仓库文件中提取 _VBYTE_ 文件（如果是克隆的文件，还会提取出项目的工作目录），其中包含当前正在处理的项目的快照。

Git 中的 checkout 命令用于在不同的分支之间切换或从特定的提交或分支恢复文件，VisionByte 也有 checkout 命令，用于将本地仓库内的更改签出到工作目录上，但另一个 update 命令与它相似，它们主要有以下几个区别：

• 使用 checkout 时，如果工作副本中有未提交的更改文件，则会中止签出，添加 --force 选项可以强制签出，但会覆盖当工作目录中已更改的文件，而 update 命令工作副本会将上游更改与本地更改合并。由于 VisionByte 倾向于遵循 CVS 命令设计，并且 CVS 推广了更新时合并的工作流程，所有 VisionByte 的更新行为更有效。

• update 会触发自动同步尝试，先从远程仓库提取更改拉取到本地仓库，再从本地仓库签出合并到工作目录中。checkout (co) 没有自动同步模式，它只会将本地仓库签出到工作目录。

• vb update 中有几个功能 vb checkout 中并不存在，详细功能可以参考 update 命令。

• 相反， vb checkout –keep 可以更新清单文件，而 vb update 命令不存在该功能，但这是一种很少需要的操作，因此在 VisionByte 系统里面 update 命令比 checkout (co) 命令更实用。

总而言之，这是两个独立的命令；彼此都不是别名。它们有很多重叠，因此在某些情况下可以互换使用，但 update 功能更强大，用途更广泛。

Git 中的 checkout 命令用于切换分支时提倡就地切换的工作模式，而 VisionByte 强烈鼓励就地更新的工作方式：

git checkout some-branch

#提倡使用 update 而不是 checkout
vb update some-branch

update 和 pull

VisionByte 中与 git pull 功能一样的命令是 vb update 而不是 vb pull。

这是因为 VisionByte 倾向于遵循 CVS 命令设计：cvs update 从中央 CVS 仓库中提取更改并将其合并到本地工作目录中，vb update 在自动同步模式开启的情况下就是这种工作模式，先从远程仓库提取更改拉取到本地仓库，再自工作副本合并到本地目录。 vb pull 命令只是 vb push 命令的反命令，它们与 vb sync 只能将本地仓库与远程仓库进行推送拉取，这些命令中没有更新本地工作目录的功能。

从 Git 角度来看， vb update 有两个目的：

• 如果没有可选 VERSION 参数，它会将工作副本更新为当前分支的最新版本。

• 给定一个 VERSION 参数，它会更新到指定的版本。如果这是分支的名称，它会像 git checkout 一样更新到该分支的最新版本。

关闭签出

vb close 命令断开工作副本与本地仓库分离，该命令是非破坏性地反转 vb open。与 Git 最接近的命令 git worktree remove ，但它是破坏性的，不可逆的。

当没有提供 --force 强制选项时，该命令不会删除托管文件，也不会让关闭未提交受版本控制的文件更改的签出。

当 VisionByte 在签出目录的根目录的 .fslckput 文件中存储了某些其他宝贵的签出数据时，该 vb close 命令也会拒绝运行。

.fslckput 文件是一个 SQLite 数据库，存储当前工作目录的数据，跟踪本地状态，例签出的版本、该工作目录的存储内容、撤消缓冲区、每工作副本设置等等。隐藏缓冲区和撤消缓冲区被认为是宝贵的未提交更改，因此必须强制 VisionByte 在关闭签出时丢弃这些缓冲区。

关闭签出目录是一种罕见的操作。一种情况是即将删除该目录，因此您希望 VisionByte 断开与仓库连接，以便执行 vb all 之类的命令。

工作树

VisionByte 系统与 Git 一样，允许一个仓库有多个工作树。这意味着可以同工作副本多个分支或者版本，每个分支都在其自己的单独工作目录中。 Git 每个工作树中的代码和修改与其他工作树相互独立，但在 VisionByte 中，不同工作树实际上是同一个仓库的不同工作目录，当你在一个工作树中对仓库进行修改时， 这些修改会反映在仓库的对象数据库中，从而影响到其他所有工作树以及主仓库。

Git 不同工作树修改提交后执行 commit，其余工作树不会同步。

Git 添加工作树 ：

git worktree add FILENAME branch-name

VisionByte 添加工作树 ：

vb open FILENAME branch-name

FILENAME 为仓库名，branch-name 为分支名，可省略。

VisionByte 工作树修改后执行 commit 会立即和其他工作树同步。

关于工作树删除两者有明显区别：

git worktree remove

一旦 Git 命令确定没有未提交的更改，它就会删除所工作副本的文件，将工作目录清空。

vb close

vb close 命令只会断开与仓库连接，不会对工作目录有其他操作，并且断开后的数据库可以再次执行 open 目录将仓库与对应工作目录相连接，但需要注意的是：如果关闭连接后对工作目录进行了更改，再次打开连接时因为仓库信息与目录信息不一致，系统提示用户选择是否用仓库的信息覆盖更改的内容。

init

为了说明 VisionByte 将仓库与工作目录分离在实践中造成的差异，Git 使用 init 命令是创建一个 .git 新仓库，可以直接在 .git 所在目录下对工作树进行操作：

git init
git add *
git commit -m ' '

而 VisionByte 使用 init 是创建后缀为 .vbyte 的 SQLite 仓库，然后使用 open 命令为仓库创建一个工作副本（工作目录）并且可以存储在指定 FILEMNAME 文件里，然后进入工作副本，对项目进行操作：

vb init FILENAME.vbyte
vb open FILENAME.vbyte --workdir FILENAME
vb add *
vb commit -m " "

每个工作目录都存在 :code:` _VBYTE_` 本地检出仓库, 用于存储 VisionByte 的配置信息和元数据，不需要直接操作或修改 _VBYTE_ 文件，它由 VisionByte 系统自动管理，包括版本历史、分支信息、用户权限等等。

备注

与 Git 不同， commit (ci) 可以缩写为 ci ,以兼容 CVS、Subversion 等。

时间线就是日志

Git 数据模型比较弱，用户经常需要使用命令 git log 线性挖掘提交历史记录，从而得到 O(n) 性能。

VisionByte 使用 vb timeline 显示项目历史提交记录，它从单个磁盘文件读取，而不是像 Git 那样按顺序访问可能的许多文件，因此操作系统的缓冲区缓存可以带来更好的性能。

与 Git 日志不同，VisionByte 的时间线默认显示所有分支信息，这有助于更好理解项目，也可以使用 vb timeline -b branch-name 显示指定分支时间线，在 Web 时间线页面也可以单击分支名显示该分支时间线。

不自动提交

Git 系统里面除了 commit 命令外，rebase 、 cherrypick 命令也会向存储库生成新的提交，并且这些命令不需要提示甚至请求提交信息。

但是 VisionByte 除了 commit 命令，没有其他命令具有提交功能，这样使仓库的每一个提交用户都是确定知道的，避免了错误的自动提交影响工作。

没有暂存区

VisionByte 没有 Git 中暂存区的概念。当执行 vb commit 时，默认情况下，签出

创建分支

VisionByte 提倡先编辑项目，在提交时创建新分支：

vb commit --branch new-branch

如果在提交时创建成功，在本地工作副本会自动切换到该分支上，本次工作副本修改的内容也会保存在该分支上，后续也不需要再次执行 vb commit --branch new-branch 命令。

若想切回父分支 trunk ，执行下列操作：

vb update trunk

VisionByte 也可以像 Git 一样，先创建分支再编辑项目，然后提交：

#创建新分支
vb branch new new-branch
#切换分支
vb update new-branch
#提交
vb commit ...

但是这样操作步骤比较多，如果不切换分支，后续的提交也会是该分支的后代。

同步设置

VisionByte 不支持 sync、push、pull 命令对单个分支进行操作。VisionByte 执行同步命令时会自动同步所有分支内容。

比如： Git 里将本地的 master 分支推送到 origin 主机的 master 分支：

git push origin master

在 VisionByte 里面实现：

vb push

VisionByte 不需要告知推送什么或推送到哪里去，它会自动同步所有内容到上一次为其提供的远程服务器的 URL， 它会推送所有分支，不仅仅是主分支。

自动同步

VisionByte 的自动同步功能通常会启用，但 Git 中没有对应的功能。如果您希望 VisionByte 与 Git 类似，可以将其关闭：

vb settings autosync off

autosync 使得 VisionByte 即有集中式版本控制系统的大部分优势，同时保留了分布式版本控制的优点。

自动同步开启时，commit 命令会将提交到本地仓库的所有更改立即发送到远程父仓库。但这仅在对远程仓库具有写入权限时才有效。

自动同步关闭时，适合于分布在不同地理位置的团队，因为不依赖于物理上的远程服务器，可以更容易地进行跨地域协作。 只要计算机可以连接到远程仓库，自己工作就会与同事的工作保持同步。必要时，可以脱离网络并在与远程同步的最后一个版本上继续工作。

因为 VisionByte 模型中的克隆几乎没有区别，不像在 Git 中，克隆经常很快地彼此分离，备份优势也适用于相反的情况:

如果远程服务器崩溃了，拥有该仓库克隆的服务器之一可以将其恢复，每个人都可以通过将本地仓库重新指向新的远程服务器来恢复工作。如果发生故障的远程服务器稍后恢复，它可以与新的中央版本同步，然后可能再次接管作为主要事实来源。

重置仓库

假设现在有一个远程服务器，有两名成员在禁止同步的情况下，遇到下列情况：

1.Alice 将她的工作目录提交到本地克隆的仓库，并以与 Git 一样的方式将更改推送到远程服务器；

2.Bob 也进行了同样的操作；

3.Alice 使用 vb pull 命令将 Bob 的更改拉取下来，看到了 Bob 对共享工作分支的更改非常不满意。

上述操作 Bob 会在步骤2中收到警告，远程仓库有了最新的更改，必须使用 pull 将更改拉取下来才能进行提交操作。 Alice 认为 Bob 的更改是错误的，应该删除掉，但是 Bob 已经将更改推送到远程服务器，并且 VisionByte 的提交是持久的，无法撤回，所有成员在提交时必须要先拉取 Bob 的提交。

Bob 可以进行以下操作：

vb amend --branch MISTAKE --hide --close -m "mea culpa" tip

vb update trunk

vb push

与 Git 不同， amend 命令不会修改之前提交的工程。Bob 的第一个命令不会删除任何内容，--branch MISTAKE 将当前分支命名为 MISTAKE （也可以命令为其他名字），-m "mea culpa" 修改注释， --hide --close 隐藏从本次签入开始的分支并且关闭此次 leaf , 告诉 VisionByte 通过在本地仓库中插入一些上述的新记录来隐藏时间线视图中的错误，以更改客户端今后解释其在那里找到的数据的方式。

Bob的第二个命令将他的工作目录切换回该分支上的前一个提交。这里举例用的是 trunk 分支。

Bob 的第三条命令将更改推送到远程服务器，以通知其他人员他的修改。

进行这些操作之后，Alice 随后可以执行 vb update trunk 同步更改信息，以便将工作副本的父提交返回到上一个版本，以免她下一次尝试提交时落在这个错误分支之上。

Bob 将该分支标记为关闭这一事实将阻止该分支通过，这让 Alice 知道她需要做什么来补救这种情况，但这仅仅说明了为什么。如果 Alice 自己进行修改，工作流程会更好：

vb amend --branch MISTAKE --hide --close -m "shunt Bob’s erroneous commit off" tip

vb update trunk

vb push

然后她可以写一份票证列出 Bob 的各种缺点，然后开始工作。这种异步工作流程解决了问题，无需与 Bob 进行明确协调。当他看到票证时，他可以 vb update trunk，默认情况下，这将触发自动同步，拉下 Alice 的修订并让他回到她的开发轨道上。

主分支 “trunk”

在 VisionByte 中，主分支的默认名称为 trunk ，对应 Git 中的 master ， GitHub 中的 main 分支。

由于 vb git export 命令必须与 Git 和 GitHub 一起使用，因此 VisionByte 使用 Git 的传统默认设置而不是 GitHub 的新默认设置：如果没有提供要求，则 VisionByte 仓库的 trunk 分支在镜像到 GitHub 上时将成为 master 。

未版本化文件

vb status 命令会显示工作副本的文件中已被编辑，并计划在下次提交时添加或删除文件。 与 git status 不同， vb status 命令不会显示本工作副本文件中未受管理的文件。 但其 vb extras 命令会显示工作树中不属于当工作副本的所有文件的列表，可以清晰显示在项目开发过程中新添加的文件。

没有暂存区