Chapters ▾
2nd Edition
-
A1. 附录 A: 在其它环境中使用 Git
- A1.1 图形界面
- A1.2 Visual Studio 中的 Git
- A1.3 Visual Studio Code 中的 Git
- A1.4 IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine 中的 Git
- A1.5 Sublime Text 中的 Git
- A1.6 Bash 中的 Git
- A1.7 Zsh 中的 Git
- A1.8 Git 在 PowerShell 中使用 Git
- A1.9 总结
-
A2. 附录 B: 在你的应用中嵌入 Git
- A2.1 命令行 Git 方式
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. 附录 C: Git 命令
A2.1 附录 B: 在你的应用中嵌入 Git - 命令行 Git 方式
如果你的应用程序的目标用户是开发者,那么在其中集成源码控制功能会让他们从中受益。 甚至对于文档编辑器等并非面向程序员的应用,也可以从版本控制系统中受益,Git 的工作模式在多种场景下表现得都非常出色。
如果你想将 Git 整合进你的应用程序,那么通常有两种可行的选择:启动 shell 来调用 Git 的命令行程序,或者将 Git 库嵌入到你的应用中。
命令行 Git 方式
一种方式就是启动一个 shell 进程并在里面使用 Git 的命令行工具来完成任务。 这种方式看起来很循规蹈矩,但是它的优点也因此而来,就是支持所有的 Git 的特性。 它也碰巧相当简单,因为几乎所有运行时环境都有一个相对简单的方式来调用一个带有命令行参数的进程。 然而,这种方式也有一些固有的缺点。
首先就是所有的输出都是纯文本格式。 这意味着你将被迫解析 Git 的有时会改变的输出格式,以随时了解它工作的进度和结果。更糟糕的是,这可能是毫无效率并且容易出错的。
另外一个就是令人捉急的错误修复能力。 如果一个版本库被莫名其妙地损毁,或者用户使用了一个奇奇怪怪的配置, Git 只会简单地拒绝进行一些操作。
还有一个就是进程的管理。 Git 会要求你在一个独立的进程中维护一个 shell 环境,这可能会无谓地增加复杂性。 试图协调许许多多的类似的进程(尤其是在某些情况下,当不同的进程在访问相同的版本库时)是对你的能力的极大挑战。