Fossil 是一个集版本控制系统、bug 追踪、维基、论坛以及文档解决方案于一体的系统。

每个开发者都知道，追踪代码的修改是至关重要的。有时候你会处于好奇或者教育的目的需要展示你的项目开始和进化的历史。有时候你想让其他的开发者参与到你的项目中，因此你需要一种值得信赖的能合并不同代码分支的方法。更极端一点，有时候你为了解决一个问题而修改的代码导致已有的功能不能正常使用。

Fossil 源码管理系统是由著名的 SQLite 数据库的作者开发的一个集版本控制系统、bug 追踪、维基、论坛以及文档解决方案于一体的系统。

安装 Fossil

Fossil 是一个独立的 C 程序，因此你可以从它的网站上下载后放在环境变量 PATH 中的任意位置。例如，假定 /usr/local/bin 已经在你的环境变量中（默认情况下是在的）：

$ wget https://fossil-scm.org/home/uv/fossil-linux-x64-X.Y.tar.gz
$ sudo tar xvf fossil-linux-x64-X.Y.tar.gz --directory /usr/local/bin

你也可以通过包管理器从软件仓库中找到 Fossil，或者直接从源码编译。

创建一个 Fossil 仓库

如果你已经有一个代码项目，想用 Fossil 来追踪，那么第一步就是创建一个 Fossil 仓库：

$ fossil init myproject.fossil
project-id: 010836ac6112fefb0b015702152d447c8c1d8604
server-id:  54d837e9dc938ba1caa56d31b99c35a4c9627f44
admin-user: klaatu (initial password is "14b605")

创建 Fossil 仓库的过程中会返回三行信息：一个唯一的项目 ID、一个唯一的服务器 ID 以及管理员 ID 和密码。项目 ID 和服务器 ID 是版本数字。管理员凭证表明你对这个仓库的所有权，当你把 Fossil 作为服务器让其他用户来访问时可以使用管理员权限。

Fossil 仓库工作流

在你使用 Fossil 仓库之前，你需要先为它的数据创建一个工作路径。你可以把这个过程类比为使用 Python 时创建一个虚拟环境或者解压一个只用来备份的 ZIP 文件。

创建一个工作目录并进入：

$ mkdir myprojectdir
$ cd myprojectdir

把你的 Fossil 打开到刚刚创建的目录：

$ fossil open ../myproject
project-name: <unnamed>
repository:   /home/klaatu/myprojectdir/../myproject
local-root:   /home/klaatu/myprojectdir/
config-db:    /home/klaatu/.fossil
project-code: 010836ac6112fefb0b015702152d447c8c1d8604
checkout:     9e6cd96dd675544c58a246520ad58cdd460d1559 2020-11-09 04:09:35 UTC
tags:         trunk
comment:      initial empty check-in (user: klaatu)
check-ins:    1

你可能注意到了，Fossil 在你的家目录下创建了一个名为 .fossil 的隐藏文件，用来追踪你的全局 Fossil 配置。这个配置不是只适用于你的一个项目的；这个文件只会在你第一次使用 Fossil 时生成。

添加文件

使用 add 和 commit 子命令来向你的仓库添加文件。例如，创建一个简单的 README 文件，把它添加到仓库：

$ echo "My first Fossil project" > README
$ fossil add README
ADDED  README
$ fossil commit -m 'My first commit'
New_Version: 2472a43acd11c93d08314e852dedfc6a476403695e44f47061607e4e90ad01aa

使用分支

Fossil 仓库开始时默认使用的主分支名为 trunk。当你想修改代码而又不影响主干代码时，你可以从 trunk 分支切走。创建新分支需要使用 branch 子命令，这个命令需要两个参数：一个新分支的名字，一个新分支的基分支名字。在本例中，只有一个分支 trunk，因此尝试创建一个名为 dev 的新分支：

$ fossil branch --help
Usage: fossil branch new BRANCH-NAME BASIS ?OPTIONS?
$ fossil branch new dev trunk
New branch: cb90e9c6f23a9c98e0c3656d7e18d320fa52e666700b12b5ebbc4674a0703695

你已经创建了一个新分支，但是你当前所在的分支仍然是 trunk：

$ fossil branch current
trunk

使用 checkout 命令切换到你的新分支 dev：

$ fossil checkout dev
dev

合并修改

假设你在 dev 分支中添加了一个新文件，完成了测试，现在想把它合并到 trunk。这个过程叫做合并。

首先，切回目标分支（本例中目标分支为 trunk）：

$ fossil checkout trunk
trunk
$ ls
README

这个分支中没有你的新文件（或者你对其他文件的修改），而那些内容是合并的过程需要的信息：

$ fossil merge dev
 "fossil undo" is available to undo changes to the working checkout.
$ ls
myfile.lua  README

查看 Fossil 时间线

使用 timeline 选项来查看仓库的历史。这个命令列出了你的仓库的所有活动的详细信息，包括用来表示每次修改的哈希值、每次提交时填写的信息以及提交者：

$ fossil timeline
=== 2020-11-09 ===
06:24:16 [5ef06e668b] added exciting new file (user: klaatu tags: dev)
06:11:19 [cb90e9c6f2] Create new branch named "dev" (user: klaatu tags: dev)
06:08:09 [a2bb73e4a3] *CURRENT* some additions were made (user: klaatu tags: trunk)
06:00:47 [2472a43acd] This is my first commit. (user: klaatu tags: trunk)
04:09:35 [9e6cd96dd6] initial empty check-in (user: klaatu tags: trunk)
+++ no more data (5) +++

公开你的 Fossil 仓库

因为 Fossil 有个内置的 web 界面，所以 Fossil 不像 GitLab 和 Gitea 那样需要主机服务。Fossil 就是它自己的主机服务，只要你把它放在一台机器上就行了。在你公开你的 Fossil 仓库之前，你还需要通过 web 用户界面（UI）来配置一些信息：

使用 ui 子命令启动一个本地的实例：

$ pwd
/home/klaatu/myprojectdir/
$ fossil ui

“Users” 和 “Settings” 是安全相关的，“Configuration” 是项目属性相关的（包括一个合适的标题）。web 界面不仅仅是一个方便的功能。 它是能在生产环境中使用并作为 Fossil 项目的宿主机来使用的。它还有一些其他的高级选项，比如用户管理（或者叫自我管理）、在同一个服务器上与其他的 Fossil 仓库进行单点登录（SSO）。

当配置完成后，关掉 web 界面并按下 Ctrl+C 来停止 UI 引擎。像提交代码一样提交你的 web 修改。

$ fossil commit -m 'web ui updates'
New_Version: 11fe7f2855a3246c303df00ec725d0fca526fa0b83fa67c95db92283e8273c60

现在你可以配置你的 Fossil 服务器了。

1. 把你的 Fossil 仓库（本例中是 myproject.fossil）复制到服务器，你只需要这一个文件。
2. 如果你的服务器没有安装 Fossil，就在你的服务器上安装 Fossil。在服务器上安装的过程跟在本地一样。
3. 在你的 cgi-bin 目录下（或它对应的目录，这取决于你的 HTTP 守护进程）创建一个名为 repo_myproject.cgi 的文件：

#!/usr/local/bin/fossil
repository: /home/klaatu/public_html/myproject.fossil

添加可执行权限：

$ chmod +x repo_myproject.cgi

你需要做的都已经做完了。现在可以通过互联网访问你的项目了。

你可以通过 CGI 脚本来访问 web UI，例如 https://example.com/cgi-bin/repo_myproject.cgi。

你也可以通过命令行来进行交互：

$ fossil clone https://[email protected]/cgi-bin/repo_myproject.cgi

在本地的克隆仓库中工作时，你需要使用 push 子命令把本地的修改推送到远程的仓库，使用 pull 子命令把远程的修改拉取到本地仓库：

$ fossil push https://[email protected]/cgi-bin/repo_myproject.cgi

使用 Fossil 作为独立的托管

Fossil 将大量的权力交到了你的手中（以及你的合作者的手中），让你不再依赖托管服务。本文只是简单的介绍了基本概念。你的代码项目还会用到很多有用的 Fossil 功能。尝试一下 Fossil。它不仅会改变你对版本控制的理解；它会让你不再考虑其他的版本控制系统。

via: https://opensource.com/article/20/11/fossil

作者：Klaatu 选题：lujun9972 译者：lxbwolf 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

了解 Mercurial 的基础知识，它是一个用 Python 写的分布式版本控制系统。

Mercurial 是一个用 Python 编写的分布式版本控制系统。因为它是用高级语言编写的，所以你可以用 Python 函数编写一个 Mercurial 扩展。

在官方文档中说明了几种安装 Mercurial 的方法。我最喜欢的一种方法不在里面：使用 pip。这是开发本地扩展的最合适方式！

目前，Mercurial 仅支持 Python 2.7，因此你需要创建一个 Python 2.7 虚拟环境：

python2 -m virtualenv mercurial-env
./mercurial-env/bin/pip install mercurial

为了让命令简短一些，以及满足人们对化学幽默的渴望，该命令称之为 hg。

$ source mercurial-env/bin/activate
(mercurial-env)$ mkdir test-dir
(mercurial-env)$ cd test-dir
(mercurial-env)$ hg init
(mercurial-env)$ hg status
(mercurial-env)$

由于还没有任何文件，因此状态为空。添加几个文件：

(mercurial-env)$ echo 1 > one
(mercurial-env)$ echo 2 > two
(mercurial-env)$ hg status
? one
? two
(mercurial-env)$ hg addremove
adding one
adding two
(mercurial-env)$ hg commit -m 'Adding stuff'
(mercurial-env)$ hg log
changeset: 0:1f1befb5d1e9
tag: tip
user: Moshe Zadka <[[email protected]][4]>
date: Fri Mar 29 12:42:43 2019 -0700
summary: Adding stuff

addremove 命令很有用：它将任何未被忽略的新文件添加到托管文件列表中，并移除任何已删除的文件。

如我所说，Mercurial 扩展用 Python 写成，它们只是常规的 Python 模块。

这是一个简短的 Mercurial 扩展示例：

from mercurial import registrar
from mercurial.i18n import _

cmdtable = {}
command = registrar.command(cmdtable)

@command('say-hello',
[('w', 'whom', '', _('Whom to greet'))])
def say_hello(ui, repo, `opts):
ui.write("hello ", opts['whom'], "\n")

简单的测试方法是将它手动加入虚拟环境中的文件中：

`$ vi ../mercurial-env/lib/python2.7/site-packages/hello_ext.py`

然后你需要启用扩展。你可以仅在当前仓库中启用它：

$ cat >> .hg/hgrc
[extensions]
hello_ext =

现在，问候有了：

(mercurial-env)$ hg say-hello --whom world
hello world

大多数扩展会做更多有用的东西，甚至可能与 Mercurial 有关。 repo 对象是 mercurial.hg.repository 的对象。

有关 Mercurial API 的更多信息，请参阅官方文档。并访问官方仓库获取更多示例和灵感。

via: https://opensource.com/article/19/4/getting-started-mercurial

作者：Moshe Zadka 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这篇文章介绍 差异文件 diff 和 补丁文件 patch ，以及它们如何在开源项目中使用的例子。

如果你曾有机会在一个使用分布式开发模型的大型代码库上工作过，你就应该听说过类似下面的话，“Sue 刚发过来一个 补丁 patch ”，“Rajiv 正在 签出 checking out 差异 diff ”, 可能这些词（补丁、差异文件）对你而言很陌生，而你确定很想搞懂他们到底指什么。开源软件对上述提到的名词有很大的贡献，作为大型项目从 Apache web 服务器到 Linux 内核的开发模型，“基于补丁文件的开发” 这一模式贯穿了上述项目的始终。实际上，你可能不知道 Apache 的名字就来自“一系列的代码补丁”（LCTT 译注：Apache 英文发音和补丁的英文 patch 相似)，它们被一一收集起来并针对原来的 NCSA HTTPd server source code 进行了修订。

你可能认为这只不过是些逸闻，但是一份早期的 Apache 网站的存档中 声称 Apache 的名字就是来自于最早的“补丁”集合；即“ 打了补丁的 APAtCHy ”服务器，简化为 Apache。

好了，言归正传，程序员嘴里说的“差异”和“补丁”到底是什么？

首先，在这篇文章里，我们可以认为这两个术语都指向同一个概念。“diff” 是 ”difference“ 的简写；Unix 下的同名工具程序 diff剖析了一个或多个文件之间的“差异”。下面我们会看到 diff 的例子:

一个“补丁”指的是文件之间一系列差异，这些差异能被 Unix 的 diff 程序应用在源代码树上。我们能使用 diff 工具来创建“差异”（或“补丁”），然后使用该工具将它们 “打” 在一个没有这个补丁的同样的源代码版本上。此外，（我又要开始跑题说些历史轶事了……），“补丁” 这个词真的指在计算机的早期使用打卡机的时候，用来覆盖在打孔纸带上来对软件进行修改的覆盖纸，那个时代打孔纸带就是在计算机处理器上运行的程序。下面来自 维基页面) 的这张图真切的描绘了最初的“打补丁”这个词的出处:

现在你对补丁和差异就了一个基本的概念，让我们来看看软件开发者是怎么使用这些工具的。如果你还没有使用过类似于 Git 或 subversion 这样的源代码版本控制工具的话，我将会一步步展示最流行的软件项目是怎么使用它们的。如果你将一个软件的生命周期看成是一条时间线的话，你就能看见这个软件的点滴变化，比如在何时源代码加上了一个功能，在何时源代码修复了一个功能缺陷。我们称这些改变的点为“ 提交 commit ”，“提交”这个词被当今最流行的源代码版本管理工具 Git 所使用，当你想检查在一个提交前后的代码变化的话，（或者在许多个提交之间的代码变化），你都可以使用工具来观察文件差异。

如果你同样在使用 Git 开发软件的话，你可以在你的本地开发环境做些希望交给别的开发者的提交，以添加到他们的源代码树中。为了给别的开发者你的提交，一个方法就是创建一个你本地文件的差异文件，然后将这个“补丁”发送给和你工作在同一个源代码树的别的开发者。别的开发者在“打”了你的补丁之后，就能看到在你的代码变树上的变化。

Linux、Git 和 GitHub

这种分享补丁的开发模型正是现今 Linux 内核社区如何处理内核修改提议而采用的模型。如果你有机会浏览任何一个主流的 Linux 内核邮件列表 —— 主要是 LKML，也包括 linux-containers、fs-devel、Netdev 等等，你能看到很多开发者会贴出他们想让其他内核开发者审核、测试或者合入 Linux 官方 Git 代码树某个位置的补丁。当然，讨论 Git 不在这篇文章范围之内（Git 是由 Linus Torvalds 开发的源代码控制系统，它支持分布式开发模型以及允许独立于主要代码仓库的补丁包，这些补丁包能被推送或拉取到不同的源代码树上，并遵守这些代码树各自的开发流程。）

在继续我们的话题之前，我们当然不能忽略和补丁和差异这个概念相关的最流行的服务：GitHub。从它的名字就能猜想出 GitHub 是基于 Git 的，而且它还围绕着 Git 对分布式开源代码开发模型提供了基于 Web 和 API 的工作流管理。（LCTT 译注：即 拉取请求 Pull Request ）。在 GitHub 上，分享补丁的方式不是像 Linux 内核社区那样通过邮件列表，而是通过创建一个 拉取请求 。当你提交你自己的源代码树的改动时，你能通过创建一个针对软件项目的共享仓库的“拉取请求”来分享你的代码改动（LCTT 译注：即核心开发者维护一个主仓库，开发者去“ 复刻 fork ”这个仓库，待各自的提交后再创建针对这个主仓库的拉取请求，所有的拉取请求由主仓库的核心开发者批准后才能合入主代码库。）GitHub 被当今很多活跃的开源社区所采用，如 Kubernetes、Docker、容器网络接口 (CNI)、Istio 等等。在 GitHub 的世界里，用户会倾向于使用基于 Web 页面的方式来审核一个拉取请求里的补丁或差异，你也可以直接访问原始的补丁并在命令行上直接使用它们。

该说点干货了

我们前面已经讲了在流行的开源社区里是怎么应用补丁和差异的，现在看看一些例子。

第一个例子包括一个源代码树的两个不同副本，其中一个有代码改动，我们想用 diff 来看看这些改动是什么。这个例子里，我们想看的是“ 合并格式 unified ”的补丁，这是现在软件开发世界里最通用的格式。如果想知道更详细参数的用法以及如何生成差异文件，请参考 diff 手册。原始的代码在 sources-orig 目录，而改动后的代码在 sources-fixed 目录。如果要在你的命令行上用“合并格式”来展示补丁，请运行如下命令。（LCTT 译注：参数 -N 代表如果比较的文件不存在，则认为是个空文件， -a 代表将所有文件都作为文本文件对待，-u 代表使用合并格式并输出上下文，-r 代表递归比较目录）

$ diff -Naur sources-orig/ sources-fixed/

……下面是 diff 命令的输出：

diff -Naur sources-orig/officespace/interest.go sources-fixed/officespace/interest.go
--- sources-orig/officespace/interest.go        2018-08-10 16:39:11.000000000 -0400
+++ sources-fixed/officespace/interest.go       2018-08-10 16:39:40.000000000 -0400
@@ -11,15 +11,13 @@
   InterestRate float64
 }

+// compute the rounded interest for a transaction
 func computeInterest(acct *Account, t Transaction) float64 {

   interest := t.Amount * t.InterestRate
   roundedInterest := math.Floor(interest*100) / 100.0
   remainingInterest := interest - roundedInterest

-  // a little extra..
-  remainingInterest *= 1000
-
   // Save the remaining interest into an account we control:
   acct.Balance = acct.Balance + remainingInterest

最开始几行 diff 命令的输出可以这样解释：三个 --- 显示了原来文件的名字；任何在原文件（LCTT 译注：不是源文件）里存在而在新文件里不存在的行将会用前缀 -，用来表示这些行被从源代码里“减去”了。而 +++ 表示的则相反：在新文件里被加上的行会被放上前缀 +，表示这是在新文件里被“加上”的行。补丁文件中的每一个补丁“块”（用 @@ 作为前缀的的部分）都有上下文的行号，这能帮助补丁工具（或其它处理器）知道在代码的哪里应用这个补丁块。你能看到我们已经修改了“Office Space”这部电影里提到的那个函数（移除了三行并加上了一行代码注释），电影里那个有点贪心的工程师可是偷偷的在计算利息的函数里加了点“料”哦。（LCTT译注：剧情详情请见电影 https://movie.douban.com/subject/1296424/）

如果你想找人来测试你的代码改动，你可以将差异保存到一个补丁里：

$ diff -Naur sources-orig/ sources-fixed/ >myfixes.patch

现在你有补丁 myfixes.patch 了，你能把它分享给别的开发者，他们可以将这个补丁打在他们自己的源代码树上从而得到和你一样的代码并测试他们。如果一个开发者的当前工作目录就是他的源代码树的根的话，他可以用下面的命令来打补丁：

$ patch -p1 < ../myfixes.patch
patching file officespace/interest.go

现在这个开发者的源代码树已经打好补丁并准备好构建和测试文件的修改了。那么如果这个开发者在打补丁之前已经改动过了怎么办？只要这些改动没有直接冲突（LCTT 译注：比如改在同一行上），补丁工具就能自动的合并代码的改动。例如下面的interest.go 文件，它有其它几处改动，然后它想打上 myfixes.patch 这个补丁：

$ patch -p1 < ../myfixes.patch
patching file officespace/interest.go
Hunk #1 succeeded at 26 (offset 15 lines).

在这个例子中，补丁警告说代码改动并不在文件原来的地方而是偏移了 15 行。如果你文件改动的很厉害，补丁可能干脆说找不到要应用的地方，还好补丁程序提供了提供了打开“模糊”匹配的选项（这个选项在文档里有预置的警告信息，对其讲解已经超出了本文的范围）。

如果你使用 Git 或者 GitHub 的话，你可能不会直接使用补丁或差异。Git 已经内置了这些功能，你能使用这些功能和共享一个源代码树的其他开发者交互，拉取或合并代码。Git 一个比较相近的功能是可以使用 git diff 来对你的本地代码树生成全局差异，又或者对你的任意两次”引用“（可能是一个代表提交的数字，或一个标记或分支的名字，等等）做全局补丁。你甚至能简单的用管道将 git diff 的输出到一个文件里（这个文件必须严格符合将要被使用它的程序的输入要求），然后将这个文件交给一个并不使用 Git 的开发者应用到他的代码上。当然，GitHub 把这些功能放到了 Web 上，你能直接在 Web 页面上查看一个拉取请求的文件变动。在 Web 上你能看到所展示的合并差异，GitHub 还允许你将这些代码改动下载为原始的补丁文件。

总结

好了，你已经学到了”差异“和”补丁“是什么，以及在 Unix/Linux 上怎么使用命令行工具和它们交互。除非你还在像 Linux 内核开发这样的项目中工作而使用完全基于补丁文件的开发方式，你应该会主要通过你的源代码控制系统（如 Git）来使用补丁。但熟悉像 GitHub 这样的高级别工具的技术背景和技术底层对你的工作也是大有裨益的。谁知道会不会有一天你需要和一个来自 Linux 世界邮件列表的补丁包打交道呢？

via: https://opensource.com/article/18/8/diffs-patches

作者：Phil Estes 选题：lujun9972 译者：David Chen 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这 13 个 Git 技巧将使你的版本控制技能 +1、+1、+1……

Git 是一个分布式版本控制系统，它已经成为开源世界中源代码控制的默认工具，在 4 月 7 日这天，它 13 岁了。使用 Git 令人沮丧的事情之一是你需要知道更多才能有效地使用 Git。但这也可能是使用 Git 比较美妙的一件事，因为没有什么比发现一个新技巧来简化或提高你的工作流的效率更令人快乐了。

为了纪念 Git 的 13 岁生日，这里有 13 条技巧和诀窍来让你的 Git 经验更加有用和强大。从你可能忽略的一些基本知识开始，并扩展到一些真正的高级用户技巧！

1、 你的 ~/.gitconfig 文件

当你第一次尝试使用 git 命令向仓库提交一个更改时，你可能会收到这样的欢迎信息：

*** Please tell me who you are.

Run

  git config --global user.email "[email protected]"

  git config --global user.name "Your Name"

to set your account's default identity.

你可能没有意识到正是这些命令在修改 ~/.gitconfig 的内容，这是 Git 存储全局配置选项的地方。你可以通过 ~/.gitconfig 文件来做大量的事，包括定义别名、永久性打开（或关闭）特定命令选项，以及修改 Git 工作方式（例如，git diff 使用哪个 diff 算法，或者默认使用什么类型的合并策略）。你甚至可以根据仓库的路径有条件地包含其他配置文件！所有细节请参阅 man git-config。

2、 你仓库中的 .git/config 文件

在之前的技巧中，你可能想知道 git config 命令中 --global 标志是干什么的。它告诉 Git 更新 ~/.gitconfig 中的“全局”配置。当然，有全局配置也意味着会有本地配置，显然，如果你省略 --global 标志，git config 将改为更新仓库特有的配置，该配置存储在 .git/config 中。

在 .git/config 文件中设置的选项将覆盖 ~/.gitconfig 文件中的所有设置。因此，例如，如果你需要为特定仓库使用不同的电子邮件地址，则可以运行 git config user.email "[email protected]"。然后，该仓库中的任何提交都将使用你单独配置的电子邮件地址。如果你在开源项目中工作，而且希望它们显示自己的电子邮件地址，同时仍然使用自己工作邮箱作为主 Git 配置，这非常有用。

几乎任何你可以在 ~/.gitconfig 中设置的东西，你也可以在 .git/config 中进行设置，以使其作用于特定的仓库。在下面的技巧中，当我提到将某些内容添加到 ~/.gitconfig 时，只需记住你也可以在特定仓库的 .git/config 中添加来设置那个选项。

3、 别名

别名是你可以在 ~/.gitconfig 中做的另一件事。它的工作原理就像命令行中的 shell —— 它们设定一个新的命令名称，可以调用一个或多个其他命令，通常使用一组特定的选项或标志。它们对于那些你经常使用的又长又复杂的命令来说非常有效。

你可以使用 git config 命令来定义别名 —— 例如，运行 git config --global --add alias.st status 将使运行 git st 与运行 git status 做同样的事情 —— 但是我在定义别名时发现，直接编辑 ~/.gitconfig 文件通常更容易。

如果你选择使用这种方法，你会发现 ~/.gitconfig 文件是一个 INI 文件。INI 是一种带有特定段落的键值对文件格式。当添加一个别名时，你将改变 [alias] 段落。例如，定义上面相同的 git st 别名时，添加如下到文件：

[alias]
st = status

（如果已经有 [alias] 段落，只需将第二行添加到现有部分。）

4、 shell 命令中的别名

别名不仅仅限于运行其他 Git 子命令 —— 你还可以定义运行其他 shell 命令的别名。这是一个用来处理一个反复发生的、罕见和复杂的任务的很好方式：一旦你确定了如何完成它，就可以在别名下保存该命令。例如，我有一些 复刻 fork 的开源项目的仓库，并进行了一些本地修改。我想跟上项目正在进行的开发工作，并保存我本地的变化。为了实现这个目标，我需要定期将来自上游仓库的更改合并到我复刻的项目中 —— 我通过使用我称之为 upstream-merge 的别名来完成。它是这样定义的：

upstream-merge = !"git fetch origin -v && git fetch upstream -v && git merge upstream/master && git push"

别名定义开头的 ! 告诉 Git 通过 shell 运行这个命令。这个例子涉及到运行一些 git 命令，但是以这种方式定义的别名可以运行任何 shell 命令。

（注意，如果你想复制我的 upstream-merge 别名，你需要确保你有一个名为 upstream 的 Git 远程仓库，指向你已经分配的上游仓库，你可以通过运行 git remote add upstream <URL to repo> 来添加一个。）

5、 可视化提交图

如果你在一个有很多分支活动的项目上开发，有时可能很难掌握所有正在发生的工作以及它们之间的相关性。各种图形用户界面工具可让你获取不同分支的图片并在所谓的“提交图表”中提交。例如，以下是我使用 GitLab 提交图表查看器可视化的我的一个仓库的一部分：

如果你是一个专注于命令行的用户或者发现分支切换工具让人分心，那么可以从命令行获得类似的提交视图。这就是 git log 命令的 --graph 参数出现的地方：

以下命令可视化相同仓库可达到相同效果：

git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative

--graph 选项将图添加到日志的左侧，--abbrev-commit 缩短提交的 SHA 值，--date=relative 以相对方式表示日期，以及 --pretty 来处理所有其他自定义格式。我有个 git lg 别名用于这个功能，它是我最常用的 10 个命令之一。

6、 更优雅的强制推送

有时，你越是想避开越避不开，你会发现你需要运行 git push --force 来覆盖仓库远程副本上的历史记录。你可能得到了一些反馈，需要你进行交互式 变基 rebase ，或者你可能已经搞砸了，并希望隐藏“罪证”。

当其他人在仓库的远程副本的同一分支上进行更改时，会发生强制推送的危险。当你强制推送已重写的历史记录时，这些提交将会丢失。这就是 git push --force-with-lease 出现的原因 -- 如果远程分支已经更新，它不会允许你强制推送，这确保你不会丢掉别人的工作。

7、 git add -N

你是否使用过 git commit -a 在一次行动中提交所有未完成的修改，但在你推送完提交后才发现 git commit -a 忽略了新添加的文件？你可以使用 git add -N (想想 “notify”) 来解决这个问题，告诉 Git 在第一次实际提交它们之前，你希望在提交中包含新增文件。

8、 git add -p

使用 Git 时的最佳做法是确保每次提交都只包含一个逻辑修改 —— 无论这是修复错误还是添加新功能。然而，有时当你在工作时，你的仓库中的修改最终应该使用多个提交。你怎样才能设法把事情分开，使每个提交只包含适当的修改呢？git add --patch 来拯救你了！

这个标志会让 git add 命令查看你工作副本中的所有变化，并为每个变化询问你是否想要将它提交、跳过，或者推迟决定（你可以在运行该命令后选择 ? 来查看其他更强大的选项）。git add -p 是生成结构良好的提交的绝佳工具。

9、 git checkout -p

与 git add -p 类似，git checkout 命令也接受 --patch 或 -p 选项，这会使其在本地工作副本中显示每个“大块”的改动，并允许丢弃它 —— 简单来说就是将本地工作副本恢复到更改之前的状态。

这真的很棒。例如，当你追踪一个 bug 时引入了一堆调试日志语句，修正了这个 bug 之后，你可以先使用 git checkout -p 移除所有新的调试日志，然后 git add -p 来添加 bug 修复。没有比组合一个优雅的、结构良好的提交更令人满意！

10、 变基时执行命令

有些项目有一个规则，即存储库中的每个提交都必须处于可工作状态 —— 也就是说，在每次提交时，应该可以编译该代码，或者应该运行测试套件而不会失败。 当你在分支上工作时，这并不困难，但是如果你最终因为某种原因需要 变基 rebase 时，那么需要逐步完成每个变基的提交以确保你没有意外地引入一个中断，而这个过程是乏味的。

幸运的是，git rebase 已经覆盖了 -x 或 --exec 选项。git rebase -x <cmd> 将在每个提交在变基中被应用后运行该命令。因此，举个例子，如果你有一个项目，其中使用 npm run tests 运行你的测试套件，git rebase -x npm run tests 将在变基期间每次提交之后运行测试套件。这使你可以查看测试套件是否在任何变基的提交中失败，以便你可以确认测试套件在每次提交时仍能通过。

11、 基于时间的修订引用

很多 Git 子命令都接受一个修订参数来决定命令作用于仓库的哪个部分，可以是某次特定的提交的 SHA1 值，一个分支的名称，甚至是一个符号性的名称如 HEAD（代表当前检出分支最后一次的提交），除了这些简单的形式以外，你还可以附加一个指定的日期或时间作为参数，表示“这个时间的引用”。

这个功能在某些时候会变得十分有用。当你处理最新出现的 bug，自言自语道：“这个功能昨天还是好好的，到底又改了些什么”，不用盯着满屏的 git log 的输出试图弄清楚什么时候更改了提交，你只需运行 git diff HEAD@{yesterday}，看看从昨天以来的所有修改。这也适用于更长的时间段（例如 git diff HEAD@{'2 months ago'}），以及一个确切的日期（例如 git diff HEAD@{'2010-01-01 12:00:00'}）。

你也可以将这些基于日期的修订参数与使用修订参数的任何 Git 子命令一起使用。在 gitrevisions 手册页中有关于具体使用哪种格式的详细信息。

12、 全知的 reflog

你是不是试过在变基时干掉过某次提交，然后发现你需要保留那个提交中一些东西？你可能觉得这些信息已经永远找不回来了，只能重新创建。但是如果你在本地工作副本中提交了，提交就会被添加到引用日志（reflog）中 ，你仍然可以访问到。

运行 git reflog 将在本地工作副本中显示当前分支的所有活动的列表，并为你提供每个提交的 SHA1 值。一旦发现你变基时放弃的那个提交，你可以运行 git checkout <SHA1> 跳转到该提交，复制任何你需要的信息，然后再运行 git checkout HEAD 返回到分支最近的提交去。

13、 自己清理

哎呦！ 事实证明，我的基本数学技能不如我的 Git 技能。 Git 最初是在 2005 年发布的，这意味着它今年会变成 13 岁，而不是 12 岁（LCTT 译注：本文原来是以 12 岁生日为题的）。为了弥补这个错误，这里有可以让我们变成十三岁的第 13 条技巧。

如果你使用基于分支的工作流，随着在一个长期项目上的工作，除非你在每个分支合并时清理干净，否则你最终会得到一大堆分支。这使得你难于找到想要的分支，分支的森林会让你无从找起。甚至更糟糕的是，如果你有大量活跃的分支，确定一个分支是否被合并（可以被安全删除）或仍然没有被合并而应该留下会非常繁琐。幸运的是，Git 可以帮到你：只需要运行 git branch --merged 就可以得到已经被合并到你的当前分支的分支列表，或者 git branch --no-merged 找出被合并到其它分支的分支。默认情况下这会列出你本地工作副本的分支，但是如果你在命令行包括 --remote 或 -r 参数，它也会列出仅存于远程仓库的已合并分支。

重要提示：如果你计划使用 git branch --merged 的输出来清理那些已合并的分支，你要小心它的输出也包括了当前分支（毕竟，这个当前的分支就被合并到当前分支！）。确保你在任何销毁动作之前排除了该分支（如果你忘记了，参见第 12 条技巧来学习 reflog 怎样帮你把分支找回来，希望有用……）。

以上是全部内容

希望这些技巧中至少有一个能够教给你一些关于 Git 的新东西，Git 是一个有 13 年历史的项目，并且在持续创新和增加新功能中。你最喜欢的 Git 技巧是什么？

via: https://opensource.com/article/18/4/git-tips

作者：John SJ Anderson 选题：lujun9972 译者：MjSeven 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

对 Git 仓库的维护通常是为了减少仓库的大小。如果你从另外一个版本控制系统导入了一个仓库，你可能需要在导入后清除掉不必要的文件。本文着重于从一个 Git 仓库中删除大文件，并且包含下列主题：

• 理解从 Git 的历史记录中删除文件
• 使用 BFG 重写历史记录
• 可选，使用 git filter-branch 重写历史记录
• 垃圾回收

请格外小心.....

本文中的步骤和工具使用的高级技术涉及破坏性操作。确保您在开始之前仔细读过并备份了你的仓库，创建一个备份最容易的方式是使用 --mirror 标志对你的仓库克隆，然后对整个克隆的文件进行打包压缩。有了这个备份，如果在维护期间意外损坏了您的仓库的关键元素，那么你可以通过备份的仓库来恢复。

请记住，仓库维护对仓库的用户可能会是毁灭性的。与你的团队或者仓库的关注者进行沟通会是一个不错的主意。确保每个人都已经检查了他们的代码，并且同意在仓库维护期间停止开发。

理解从 Git 的历史记录中删除文件

回想一下，克隆仓库会克隆整个历史记录——包括每个源代码文件的所有版本。如果一个用户提交了一个较大的文件，比如一个 JAR，则随后的每次克隆都会包含这个文件。即使用户最终在后面的某次提交中删除了这个文件，但是这个文件仍然存在于这个仓库的历史记录中。要想完全的从你的仓库中删除这个文件，你必须：

• 从你的项目的当前的文件树中删除该文件;
• 从仓库的历史记录中删除文件——重写 Git 历史记录，从包含该文件的所有的提交中删除这个文件;
• 删除指向旧的提交历史记录的所有 reflog 历史记录;
• 重新整理仓库，使用 git gc 对现在没有使用的数据进行垃圾回收。

Git 的 “gc”（垃圾回收）将通过你的任何一个分支或者标签来删除仓库中所有的实际没用的或者以某种方式引用的数据。为了使其发挥作用，我们需要重写包含不需要的文件的所有 Git 仓库历史记录，仓库将不再引用它—— git gc 将会丢弃所有没用的数据。

重写存储库历史是一个棘手的事情，因为每个提交都依赖它的父提交，所以任何一个很小的改变都会改变它的每一个随后的提交的提交 ID。有两个自动化的工具可以做到这：

1. BFG Repo Cleaner 快速、简单且易于使用，需要 Java 6 或者更高版本的运行环境。
2. git filter-branch 功能强大、配置麻烦，用于大于仓库时速度较慢，是核心 Git 套件的一部分。

切记，当你重写历史记录后，无论你是使用 BFG 还是使用 filter-branch，你都需要删除指向旧的历史记录的 reflog 条目，最后运行垃圾回收器来删除旧的数据。

使用 BFG 重写历史记录

BFG 是为将像大文件或者密码这些不想要的数据从 Git 仓库中删除而专门设计的，所以它有一一个简单的标志用来删除那些大的历史文件（不在当前的提交里面）：--strip-blobs-bigger-than

$ java -jar bfg.jar --strip-blobs-than 100M

大小超过 100MB 的任何文件（不包含在你最近的提交中的文件——因为 BFG 默认会保护你的最新提交的内容）将会从你的 Git 仓库的历史记录中删除。如果你想用名字来指明具体的文件，你也可以这样做：

$ java -jar bfg.jar --delete-files *.mp4

BFG 的速度要比 git filter-branch 快 10-1000 倍，而且通常更容易使用——查看完整的使用说明和示例获取更多细节。

或者，使用 git filter-branch 来重写历史记录

filter-branch 命令可以对 Git 仓库的历史记录重写，就像 BFG 一样，但是过程更慢和更手动化。如果你不知道这些大文件在哪里，那么你第一步就需要找到它们：

手动查看你 Git 仓库中的大文件

Antony Stubbs 写了一个可以很好地完成这个功能的 BASH 脚本。该脚本可以检查你的包文件的内容并列出大文件。在你开始删除文件之前，请执行以下操作获取并安装此脚本：

1、 下载脚本到你的本地的系统。

2、 将它放在一个可以访问你的 Git 仓库的易于找到的位置。

3、 让脚本成为可执行文件：

$ chmod 777 git_find_big.sh

4、 克隆仓库到你本地系统。

5、 改变当前目录到你的仓库根目录。

6、 手动运行 Git 垃圾回收器：

git gc --auto

7、 找出 .git 文件夹的大小

$ du -hs .git/objects
45M .git/objects

注意文件大小，以便随后参考。

8、 运行 git_find_big.sh 脚本来列出你的仓库中的大文件。

$ git_find_big.sh 
All sizes are in kB's. The pack column is the size of the object, compressed, inside the pack file.
size  pack  SHA                                       location
592   580   e3117f48bc305dd1f5ae0df3419a0ce2d9617336  media/img/emojis.jar
550   169   b594a7f59ba7ba9daebb20447a87ea4357874f43  media/js/aui/aui-dependencies.jar
518   514   22f7f9a84905aaec019dae9ea1279a9450277130  media/images/screenshots/issue-tracker-wiki.jar
337   92    1fd8ac97c9fecf74ba6246eacef8288e89b4bff5  media/js/lib/bundle.js
240   239   e0c26d9959bd583e5ef32b6206fc8abe5fea8624  media/img/featuretour/heroshot.png

大文件都是 JAR 文件，包的大小列是最相关的。aui-dependencies.jar 被压缩到 169kb，但是 emojis.jar 只压缩到 500kb。emojis.jar 就是一个待删除的对象。

运行 filter-branch

你可以给这个命令传递一个用于重写 Git 索引的过滤器。例如，一个过滤器可以可以将每个检索的提交删除。这个用法如下：

git filter-branch --index-filter 'git rm --cached --ignore-unmatch  _pathname_ ' commitHASH

--index-filter 选项可以修改仓库的索引，--cached 选项从索引中而不是磁盘来删除文件。这样会更快，因为你不需要在运行这个过滤器前检查每个修订版本。git rm 中的 ignore-unmatch 选项可以防止在尝试移走不存在的文件 pathname 的时候命令失败。通过指定一个提交 HASH 值，你可以从每个以这个 HASH 值开始的提交中删除pathname。要从开始处删除，你可以省略这个参数或者指定为 HEAD。

如果你的大文件在不同的分支，你将需要通过名字来删除每个文件。如果大文件都在一个单独的分支，你可以直接删除这个分支本身。

选项 1：通过文件名删除文件

使用下面的步骤来删除大文件：

1、 使用下面的命令来删除你找到的第一个大文件：

git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD

2、 重复步骤 1 找到剩下的每个大文件。

3、 在你的仓库里更新引用。 filter-branch 会为你原先的引用创建一个 refs/original/ 下的备份。一旦你确信已经删除了正确的文件，你可以运行下面的命令来删除备份文件，同时可以让垃圾回收器回收大的对象：

git filter-branch --index-filter 'git rm --cached --ignore-unmatch filename' HEAD

选项 2：直接删除分支

如果你所有的大文件都在一个单独的分支上，你可以直接删除这个分支。删除这个分支会自动删除所有的引用。

1、 删除分支。

$ git branch -D PROJ567bugfix

2、 从后面的分支中删除所有的 reflog 引用。

对不用的数据垃圾回收

1、 删除从现在到后面的所有 reflog 引用（除非你明确地只在一个分支上操作）。

$ git reflog expire --expire=now --all

2、 通过运行垃圾回收器和删除旧的对象重新打包仓库。

$ git gc --prune=now

3、 把你所有的修改推送回仓库。

$ git push --all --force

4、 确保你所有的标签也是当前最新的:

$ git push --tags --force

via: https://confluence.atlassian.com/bitbucket/maintaining-a-git-repository-321848291.html

作者：atlassian.com 译者：zhousiyu325 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在互联网成为一个巨大的、世界性的现象之前，开发团队常常被限制在一个小的物理空间内。如果公司没有资金支持的话，与世界另一方的人合作是一个非常昂贵或几乎不可能的梦想。

幸运的是，情况不再是这样了。互联网诞生了基于网络的解决方案，允许公司组成合作团体，包括彼此相距数千英里的人。

自从 2008 年首次推出以来，Bitbucket 已成为使用 Mercurial 或 Git 版本控制系统（VCS）的开发人员团队中越来越受欢迎的选择。

它既提供免费帐户，带有不限数量的私人存储库（每个账户最多 5 个用户），也提供多种付费计划，允许每个帐户有更多用户。此外，标记为“公开”的仓库对可以编辑或读取其内容的人数没有限制。

注册 Bitbucket

要使用 Bitbucket，你需要建立一个免费帐户。要这样做，请进入 https://bitbucket.org/， 然后单击 免费开始 Get started for free 按钮。

首先，你需要输入有效的电子邮件地址，然后点击继续。 你的电子邮件帐户将被验证，如果一切正常，你将被提示输入所需的密码。完成后，再次点击 继续，然后检查你的电子邮件收件箱，以确认你的帐户是否已创建：

Bitbucket 注册

验证电子邮件地址后，系统会要求你确定用户名。 然后将创建你的帐户，你将会进入 Bitbucket 面板，在那里开始创建团队、项目和仓库：

Bitbucket 面板

如你所见，你可以在几分钟内注册 Bitbucket。Atlassian 的人简化了这个过程，以便你可以把你的时间真正用在 Bitbucket 上 - 我们下面会进一步讲。

使用 Bitbucket

让我们浏览下注册 Bitbucket 之后必须要做的事情。它们都在顶部菜单中：

探索 Bitbucket 功能

1). 创建一个团队，通过允许多个 Bitbucket 用户共享一个账号计划的方式鼓励协作。

这将允许他们轻松管理团队拥有的仓库。要创建团队，请输入团队名称，并确保团队标识不存在。接下来，输入你要添加到群组的人员的电子邮件地址，并指明是否要将其设为管理员。最后，单击创建：

Bitbucket – 创建一个团队

2) 创建或导入一个仓库

如果你已经使用基于 Git 的解决方案，你可以轻松地将你的仓库导入 Bitbucket。否则，你可以从头创建一个。让我们看看在每种情况下你需要做什么。

要创建新的仓库，请单击 仓库 Repositories 菜单中的 创建仓库 Create repository 选项。为新仓库和要分组到的项目选择一个名称。接下来，指明是否要将其设置为 private 并指定类型（Git 或 Mercurial）。最后，单击创建仓库：

Bitbucket – 创建一个新仓库

要导入已有仓库，请从仓库下拉菜单中选择 导入 Import 仓库。要开始导入，请指定源，输入 URL 和所需的登录凭据（如果需要）。

最后，选择新的仓库设置，然后单击导入仓库。忽略有关在指定 URL 处找不到仓库的警告，因为它是虚拟的，仅用于演示目的：

Bitbucket – 导入已有代码

就是这样，很简单吧。

在 Bitbucket 中使用仓库

创建一个新仓库或者导入一个仓库后，它会在面板上展示出来。这时就能执行一些常规操作，如克隆、创建分支、pull request、提交修改、添加 README 文件等等：

Bitbucket – 仓库概览

如果想了解如何用仓库工作，或者想要提升你的 git 技能，可以参考 Bitbucket 官方文档。

总结

如你所见，不管你是版本管理的新手还是老手，Bitbucket 都能使管理变得更简单。如果你对本文有任何疑问或评论，请不要犹豫让我们知道。我们期待听到你的声音！

作者简介：

我是 Ravi Saive，TecMint 的原创作者。一个喜爱在互联网上分享技巧和提示的计算机 geek 和 Linux 老手。我的大多数服务运行在 Linux 开源平台上。请在 Twitter、Facebook、Google+ 上关注我。

via: http://www.tecmint.com/bitbucket-for-version-control/

作者：Ravi Saive 译者：geekpi 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出