Git 提供了几种方式可以帮你快速查看提交中哪些文件被改变。

如果你每天使用 Git，应该会提交不少改动。如果你每天和其他人在一个项目中使用 Git，假设 每个人 每天的提交都是安全的，你会意识到 Git 日志会变得多么混乱，似乎永恒地滚动着变化，却没有任何迹象表明修改了什么。

那么，你该怎样查看指定提交中文件发生哪些变化？这比你想的容易。

查看提交中文件发生的变化

要想知道指定提交中哪些文件发生变化，可以使用 git log --raw 命令。这是发现一个提交影响了哪些文件的最快速、最方便的方法。git log 命令一般都没有被充分利用，主要是因为它有太多的格式化选项，许多用户在面对很多选择以及在一些情况下不明所以的文档时，会望而却步。

然而，Git 的日志机制非常灵活，--raw 选项提供了当前分支中的提交日志，以及更改的文件列表。

以下是标准的 git log 输出：

$ git log
commit fbbbe083aed75b24f2c77b1825ecab10def0953c (HEAD -> dev, origin/dev)
Author: tux <[email protected]>
Date:   Sun Nov 5 21:40:37 2020 +1300

    exit immediately from failed download

commit 094f9948cd995acfc331a6965032ea0d38e01f03 (origin/master, master)
Author: Tux <[email protected]>
Date:   Fri Aug 5 02:05:19 2020 +1200

    export makeopts from etc/example.conf

commit 76b7b46dc53ec13316abb49cc7b37914215acd47
Author: Tux <[email protected]>
Date:   Sun Jul 31 21:45:24 2020 +1200

    fix typo in help message

即使作者在提交消息中指定了哪些文件发生变化，日志也相当简洁。

以下是 git log --raw 输出：

$ git log --raw
commit fbbbe083aed75b24f2c77b1825ecab10def0953c (HEAD -> dev, origin/dev)
Author: tux <[email protected]>
Date:   Sun Nov 5 21:40:37 2020 +1300

    exit immediately from failed download

:100755 100755 cbcf1f3 4cac92f M        src/example.lua

commit 094f9948cd995acfc331a6965032ea0d38e01f03 (origin/master, master)
Author: Tux <[email protected]>
Date:   Fri Aug 5 02:05:19 2020 +1200

    export makeopts from etc/example.conf
   
:100755 100755 4c815c0 cbcf1f3 M     src/example.lua
:100755 100755 71653e1 8f5d5a6 M     src/example.spec
:100644 100644 9d21a6f e33caba R100  etc/example.conf  etc/example.conf-default

commit 76b7b46dc53ec13316abb49cc7b37914215acd47
Author: Tux <[email protected]>
Date:   Sun Jul 31 21:45:24 2020 +1200

    fix typo in help message

:100755 100755 e253aaf 4c815c0 M        src/example.lua

这会准确告诉你哪个文件被添加到提交中，哪些文件发生改变（A 是添加，M 是修改，R 是重命名，D 是删除）。

Git whatchanged

git whatchanged 命令是一个遗留命令，它的前身是日志功能。文档说用户不应该用该命令替代 git log --raw，并且暗示它实质上已经被废弃了。不过，我还是觉得它是一个很有用的捷径，可以得到同样的输出结果（尽管合并提交的内容不包括在内），如果它被删除的话，我打算为它创建一个别名。如果你只想查看已更改的文件，不想在日志中看到合并提交，可以尝试 git whatchanged 作为简单的助记符。

查看变化

你不仅可以看到哪些文件发生更改，还可以使用 git log 显示文件中发生了哪些变化。你的 Git 日志可以生成一个内联差异，用 --patch 选项可以逐行显示每个文件的所有更改：

commit 62a2daf8411eccbec0af69e4736a0fcf0a469ab1 (HEAD -> master)
Author: Tux <[email protected]>
Date:   Wed Mar 10 06:46:58 2021 +1300

    commit

diff --git a/hello.txt b/hello.txt
index 65a56c3..36a0a7d 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1,2 +1,2 @@
 Hello
-world
+opensource.com

在这个例子中，“world” 这行字从 hello.txt 中删掉，“opensource.com” 这行字则添加进去。

如果你需要在其他地方手动进行相同的修改，这些 补丁 patch 可以与常见的 Unix 命令一起使用，例如 diff 与 patch。补丁也是一个好方法，可以总结指定提交中引入新信息的重要部分内容。当你在冲刺阶段引入一个 bug 时，你会发现这里的内容就是非常有价值的概述。为了更快地找到错误的原因，你可以忽略文件中没有更改的部分，只检查新代码。

用简单命令得到复杂的结果

你不必理解引用、分支和提交哈希，就可以查看提交中更改了哪些文件。你的 Git 日志旨在向你报告 Git 的活动，如果你想以特定方式格式化它或者提取特定的信息，通常需要费力地浏览许多文档来组合出正确的命令。幸运的是，关于 Git 历史记录最常用的请求之一只需要一两个选项：--raw 与 --patch。如果你不记得 --raw，就想想“Git，什么改变了？”，然后输入 git whatchanged。

via: https://opensource.com/article/21/4/git-whatchanged

作者：Seth Kenlon 选题：lujun9972 译者：DCOLIVERSUN 校对：wxy

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

抵制在 Git 中添加一些会增加管理难度的东西的冲动；这里有替代方法。

有权访问源代码使对安全性的分析以及应用程序的安全成为可能。但是，如果没有人真正看过代码，问题就不会被发现，即使人们主动地看代码，通常也要看很多东西。幸运的是，GitHub 拥有一个活跃的安全团队，最近，他们 发现了已提交到多个 Git 仓库中的特洛伊木马病毒，甚至仓库的所有者也偷偷溜走了。尽管我们无法控制其他人如何管理自己的仓库，但我们可以从他们的错误中吸取教训。为此，本文回顾了将文件添加到自己的仓库中的一些最佳实践。

了解你的仓库

这对于安全的 Git 仓库来可以说是头号规则。作为项目维护者，无论是你自己创建的还是采用别人的，你的工作是了解自己仓库中的内容。你可能无法记住代码库中每一个文件，但是你需要了解你所管理的内容的基本组成部分。如果在几十个合并后出现一个游离的文件，你会很容易地发现它，因为你不知道它的用途，你需要检查它来刷新你的记忆。发生这种情况时，请查看该文件，并确保准确了解为什么它是必要的。

禁止二进制大文件

Git 是为文本而生的，无论是用纯文本编写的 C 或 Python 还是 Java 文本，亦或是 JSON、YAML、XML、Markdown、HTML 或类似的文本。Git 对于二进制文件不是很理想。

两者之间的区别是：

$ cat hello.txt
This is plain text.
It's readable by humans and machines alike.
Git knows how to version this.

$ git diff hello.txt
diff --git a/hello.txt b/hello.txt
index f227cc3..0d85b44 100644
--- a/hello.txt
+++ b/hello.txt
@@ -1,2 +1,3 @@
 This is plain text.
+It's readable by humans and machines alike.
 Git knows how to version this.

和

$ git diff pixel.png
diff --git a/pixel.png b/pixel.png
index 563235a..7aab7bc 100644
Binary files a/pixel.png and b/pixel.png differ

$ cat pixel.png
�PNG
▒
IHDR7n�$gAMA��
              �abKGD݊�tIME�

                          -2R��
IDA�c`�!�3%tEXtdate:create2020-06-11T11:45:04+12:00��r.%tEXtdate:modify2020-06-11T11:45:04+12:00��ʒIEND�B`�

二进制文件中的数据不能像纯文本一样被解析，因此，如果二进制文件发生任何更改，则必须重写整个内容。一个版本与另一个版本之间唯一的区别就是全部不同，这会快速增加仓库大小。

更糟糕的是，Git 仓库维护者无法合理地审计二进制数据。这违反了头号规则：应该对仓库的内容了如指掌。

除了常用的 POSIX 工具之外，你还可以使用 git diff 检测二进制文件。当你尝试使用 --numstat 选项来比较二进制文件时，Git 返回空结果：

$ git diff --numstat /dev/null pixel.png | tee
-     -   /dev/null => pixel.png
$ git diff --numstat /dev/null file.txt | tee
5788  0   /dev/null => list.txt

如果你正在考虑将二进制大文件（BLOB）提交到仓库，请停下来先思考一下。如果它是二进制文件，那它是由什么生成的。是否有充分的理由不在构建时生成它们，而是将它们提交到仓库？如果你认为提交二进制数据是有意义的，请确保在 README 文件或类似文件中指明二进制文件的位置、为什么是二进制文件的原因以及更新它们的协议是什么。必须谨慎对其更新，因为你每提交一个二进制大文件的变化，它的存储空间实际上都会加倍。

让第三方库留在第三方

第三方库也不例外。尽管它是开源的众多优点之一，你可以不受限制地重用和重新分发不是你编写的代码，但是有很多充分的理由不把第三方库存储在你自己的仓库中。首先，除非你自己检查了所有代码（以及将来的合并），否则你不能为第三方完全担保。其次，当你将第三方库复制到你的 Git 仓库中时，会将焦点从真正的上游源代码中分离出来。从技术上讲，对库有信心的人只对该库的主副本有把握，而不是对随机仓库的副本有把握。如果你需要锁定特定版本的库，请给开发者提供一个合理的项目所需的发布 URL，或者使用 Git 子模块。

抵制盲目的 git add

如果你的项目已编译，请抵制住使用 git add . 的冲动（其中 . 是当前目录或特定文件夹的路径），因为这是一种添加任何新东西的简单方法。如果你不是手动编译项目，而是使用 IDE 为你管理项目，这一点尤其重要。用 IDE 管理项目时，跟踪添加到仓库中的内容会非常困难，因此仅添加你实际编写的内容非常重要，而不是添加项目文件夹中出现的任何新对象。

如果你使用了 git add .，请在推送之前检查暂存区里的内容。如果在运行 make clean 或等效命令后，执行 git status 时在项目文件夹中看到一个陌生的对象，请找出它的来源，以及为什么仍然在项目的目录中。这是一种罕见的构建工件，不会在编译期间重新生成，因此在提交前请三思。

使用 Git ignore

许多为程序员打造的便利也非常杂乱。任何项目的典型项目目录，无论是编程的，还是艺术的或其他的，到处都是隐藏的文件、元数据和遗留的工件。你可以尝试忽略这些对象，但是 git status 中的提示越多，你错过某件事的可能性就越大。

你可以通过维护一个良好的 gitignore 文件来为你过滤掉这种噪音。因为这是使用 Git 的用户的共同要求，所以有一些入门级的 gitignore 文件。Github.com/github/gitignore 提供了几个专门创建的 gitignore 文件，你可以下载这些文件并将其放置到自己的项目中，Gitlab.com 在几年前就将gitignore 模板集成到了仓库创建工作流程中。使用这些模板来帮助你为项目创建适合的 gitignore 策略并遵守它。

查看合并请求

当你通过电子邮件收到一个合并/拉取请求或补丁文件时，不要只是为了确保它能正常工作而进行测试。你的工作是阅读进入代码库的新代码，并了解其是如何产生结果的。如果你不同意这个实现，或者更糟的是，你不理解这个实现，请向提交该实现的人发送消息，并要求其进行说明。质疑那些希望成为版本库永久成员的代码并不是一种社交失误，但如果你不知道你把什么合并到用户使用的代码中，那就是违反了你和用户之间的社交契约。

Git 责任

社区致力于开源软件良好的安全性。不要鼓励你的仓库中不良的 Git 实践，也不要忽视你克隆的仓库中的安全威胁。Git 功能强大，但它仍然只是一个计算机程序，因此要以人为本，确保每个人的安全。

via: https://opensource.com/article/20/7/git-repos-best-practices

作者：Seth Kenlon 选题：lujun9972 译者：stevenzdg988 校对：wxy

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

想学习 Git？看看这个最重要的术语和命令的快速总结。

如今，对于任何希望跟踪他们的变化的人来说，版本控制是一个重要的工具。它对程序员、系统管理员和 网站可靠性工程师 site reliability engineers （SRE）都特别有用。确保可以从错误中恢复到已知的良好状态是一个巨大的胜利，比以前给复制的文件添加 .old 后缀的策略更友好。

但学习 Git 这件事往往被告诉大家“投身开源”的好心同行们过度简化了。在你还不明白之前，就有人要你给一个从 上游 upstream 变基 rebase 的 拉取请求 pull request （PR）或 合并请求 merge request （MR），然后他们才能从你的 远程版本库 remote 合并 —— 而且一定会删除 合并提交 merge commits 。无论你想给开源项目做出什么好的贡献，当你看到这些你不认识的单词时，都会觉得难以融入。

• 下载 我们的 Git 速查表。

如果你有一两个月的时间和足够的好奇心，Git SCM 是你需要学习所有术语的权威来源。但如果你正在寻找来自实践的总结，请继续阅读。

提交就是提醒

对我来说，Git 最难理解的部分是 Git 最简单的概念：一个 提交 commit 就是一个内容的集合，包括一个关于描述的信息，以及之前的提交。没有固有的代码发布策略，甚至没有内置的明确建议。这个内容甚至不一定是代码 —— 可以是任何你想添加到版本库的东西。 提交消息 commit message 会对这些内容进行注释。

我喜欢把提交信息看作是给未来的自己的礼物：它可能会提到你编辑的文件，但更重要的是它提醒你修改这些文件的意图。添加更多关于你为什么编辑这些内容的信息，可以帮助任何使用你的版本库的人，即使那个人是你。

origin/master 在哪里？

要知道自己在 Git 项目中的位置，首先把它想成一棵树。所有 Git 项目都有一个根目录，类似于文件系统的根目录。所有的提交都是这个根目录下的分支。这样一来，分支只是一个提交的指针。按照惯例，master 是根目录下默认的分支名称。（LCTT 译注：世界变得快，原文发表于 2019 年，而现在有些地方开始用 main 替代这个名字。）

由于 Git 是一个分布式的版本控制系统，同一个代码库分布在多个地方，所以人们经常用 版本库 repository 这个词来表示同一个项目的所有副本。（LCTT 译注：“repository” 英文原意是仓库、存储库，在计算机环境中，常用于版本控制、软件分发等方面，有时候会统一译作“仓库”、“存储库”。但我们认为，应该根据不同语境采用更有指向性的译法。在 Git 等版本控制语境中，采用“版本库”；在软件分发方面，采用“软件库”；其它泛指或不确定的语境中，可采用“仓库”、“存储库”译法。）有 本地版本库 local repository ，这是你编辑代码的地方（稍后会有更多的介绍），还有 远程版本库 remote repository ，这是你完成后想把代码发送到的地方。远程版本库可以在任何地方，甚至在你的本地版本库所在的同一台计算机上，但它们通常托管在 GitLab 或 GitHub 等版本库服务上。

我在哪里？

虽然不是官方的卖点，但迷路也是 Git 仓库的“乐趣”之一。你可以通过这套可靠的命令来找到自己的方向：

• git branch —— 找到你所在的分支。
• git log —— 查看你正在进行的提交。
• git status —— 查看自上次提交以来你所做的编辑。
• git remote —— 查看你正在跟踪的远程仓库。

用这些命令来定位自己的方向，当你被卡住的时候，会让你有一种方向感。

我是否已将我的提交暂存或缓存起来？

你电脑上的代码俗称为你的 工作空间 workspace 。但不是很明显的是，当你在 Git 仓库中时，你还有两个（是的，两个！）其他位置： 索引 index 和 暂存 stash 。当你写了一些内容，然后添加时，你是把它添加到索引中，也就是准备提交的缓存内容。有的时候，你的索引中的文件还没有准备好提交，但你想查看另一个分支。这时，暂存就派上用场了。你可以使用 git stash 将索引了但尚未提交的文件存储到暂存区中。当你准备好取回文件时，运行 git stash pop 将更改带回索引中。

下面是一些你需要使用暂存区和缓存区的命令：

• git diff ...origin/master —— 显示最近的本地提交和远程的 origin 版本库的 master 分支之间的差异。
• git diff --cached —— 显示最近的本地提交与添加到本地索引的内容之间的任何差异。
• git stash —— 将索引的（已添加但未提交的）文件放在暂存区堆栈中。
• git stash list —— 显示暂存区堆栈中的变化。
• git stash pop —— 将最近的变化从暂存库中删除。

无头骑士

Git 里面有各种比喻。当我想到 HEAD 是哪里的时候，我就会想到火车线路。如果你最终处于 脱离的 HEAD detached HEAD 模式，就意味着你已经脱离了这个隐喻的轨道。

HEAD 是指向当前签出分支中最近一次提交的指针。默认的“签出checkout”是指当你创建一个 Git 仓库并进入到 master 分支的时候。每次创建或修改到另一个分支时，你都会切换到该分支行。如果你在当前分支的某处进行 git checkout <commit>，HEAD 就会移动到该提交。如果没有提交历史记录将你的当前提交连接到已签出的提交，那么你将处于脱离的 HEAD 状态。如果你找不到 HEAD 的位置，你可以随时用 git reset --hard origin/master 来删除修改，回到已知状态。警告：这将删除你上次推送到 master 后的任何改动。

你是上游还是下游？

你的项目的本地副本被认为是你的本地版本库，它可能有也可能没有远程版本库 —— 远程版本库的副本是用于协作或保存的。也可能还有一个 上游 upstream 版本库，在那里，项目的第三个副本由不同的贡献者托管和维护。

例如，假设我想为 Kubernetes 做贡献。我会首先将 kubernetes/kubernetes 项目 复刻 fork 到我的账户下 mbbroberg/kubernetes。然后我会将我的项目克隆到我的本地工作区。在这种情况下，我的本地克隆是我的本地仓库，mbbroberg/kubernetes 是我的远程仓库，kubernetes/kubernetes 是上游。

合并的隐喻

当你深入 Git 分支时，根系统的视觉效果就会和火车轨道的形象合二为一。分支通常被用作开发一个新功能的方式，最终你想把它 合并 merge 到主分支中。当这样做时，Git 会按顺序保留共同的提交历史，然后将你的分支的新提交追加到历史中。这个过程有一大堆的细节：是否 变基 rebase ，是否添加一个 合并提交 merge commit ，Brent Laster 在《如何在 Git 中重置、恢复和返回之前的状态》中会有更详细的探讨。

我想现在就去 Git

要掌握 Git 命令的世界，有大量的术语和需要探索的地方。我希望这篇关于日常使用术语的第一人称探索能帮助你适应这一切。如果你觉得自己被卡住了或者遇到了挫折，欢迎在 Twitter @mbbroberg 上联系我。

回顾

• 提交 Commit —— 将当前索引的内容保存在一个新的提交中，并附上用户描述更改的日志信息。
• 分支 Branch —— 指向一个提交的指针。
• master —— 第一个分支的默认名称。
• HEAD —— 指向当前分支上最近一次提交的指针。
• 合并 Merge —— 合并两个或多个提交的历史。
• 工作空间 Workspace —— Git 仓库本地副本的通俗名称。
• 工作树 Working tree —— 工作区中的当前分支；任何时候你都可以在 git status 的输出中看到这个。
• 缓存 Cache —— 用于临时存储未提交的变更的空间。
• 索引 Index —— 变更提交前存储其变化的缓存。
• 跟踪和未跟踪的文件 —— 没有被索引缓存的文件或尚未加入其中的文件。
• 暂存 Stash —— 另一个缓存，作为一个堆栈，在这里可以存储更改而不需要提交它们。
• origin —— 远程版本库的默认名称。
• 本地仓库 Local repository —— 也就是你在工作站上保存 Git 仓库副本的地方。
• 远程存储库 Remote repository —— Git 存储库的第二副本，你可以在这里推送变更以便协作或备份。
• 上游存储库 Upstream repository —— 你跟踪的远程存储库的通俗说法。
• 拉取请求 Pull request —— 这是 GitHub 的专用术语，用于让其他人知道你推送到仓库分支的变化。
• 合并请求 Merge request —— 这是 GitLab 的专用术语，用于让其他人知道你推送到仓库分支的变化。
• origin/master —— 远程版本库及其主要分支的默认名称。

后记：双关语是 Git 最好的部分之一，愿你喜欢。

via: https://opensource.com/article/19/2/git-terminology

作者：Matthew Broberg 选题：lujun9972 译者：wxy 校对：wxy

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

你对 Git 了解得越多，使用 Git 就会越容易。一起来回顾下年度最佳 Git 文章。

Git 是开源开发者工具箱中最基本的工具。这个强大的版本控制系统有很多复杂的功能。使用 Git 不需要了解它所有的功能，但是对 Git 了解得越多，使用 Git 就会越容易。

下面每篇文章都提供了一些奇技淫巧来提升和增强你的 Git 技能。

怎么解决 git 合并时的冲突

Brian Breniser 的这篇教程从 git merge 的定义以及解释什么是冲突开始。然后他详细解释了在合并时如果有冲突如何解决冲突。Breniser 还提了一些能学习更多关于解决冲突和其他 Git 功能的建议。

4 个不可或缺的 Git 脚本

Vince Power 分享了他最重要的 Git 脚本。这些脚本可以从 Git Extras 包中获得，该包提供了 60 多个 Git 增强脚本。Power 最爱的脚本有：在无需打开文本编辑器的情况下编辑 .git-ignore 的 git-ignore ；用于提供 Git 仓库的摘要的 git-info；用来处理 GitLab 的合并请求（MR）和 GitHub 的拉取请求（PR）的 git-pr；把 Git 的提交（commit）、标签（tag）和推送（push）合为一体的 git-release。

完美生活：git rebase -i

在 Dave Neary 的这篇文章中可以学习使用 git rebase -i 来修改你的 Git 提交历史。Neary 从解释 Git 是如何把提交历史记录到仓库中的以及 git commit 和 git rebase 的区别。之后，他又解释了如何使用 git rebase -i 让 Git 仓库的提交历史变得简洁。这个命令能让你把“修复书写错误”的提交合进其它提交里，把几个相似的小提交合并成一个大的提交。

Git Cola 让使用 Git 变得简单

Seth Kenlon 演示了如何使用 Git Cola。Git 是个命令行工具，这对于有些人来说是有学习门槛的。Git Cola 提供了一个图形界面，因此不习惯用命令行的用户也可以使用 Git。在此文中，Kenlon 展示了如何安装 Git Cola，并使用 Git Cola 的图形用户界面完成了很多 Git 提交任务。

6 个在团队中使用 Git 的最佳实践

从设计上讲，Git 是个协同工具，但是关于如何协同的很多细节是由团队自行决定的。Ravi Chandran 提了一些建议，团队应该采用这些建议更高效地使用 Git。Chandran 在文中列出的 6 个最佳实践是：“使约定正式化”，“正确地合并修改”，“经常变基你的功能分支”，“在合并之前把压扁你的提交”，“使用标签”，“让软件的可执行程序打印标签”。

改变我使用 Git 工作方式的七个技巧

Rajeev Bera 分享了 7 个 Git 技巧，这些技巧能提升 Git 的用户体验。文章探讨了 Git 的自动更正、提交计数、仓库优化、备份未追踪的文件、了解 .git 目录、在另一个分支查看文件以及在 Git 下搜索。

使用 tmux 和 Git 定制化我的 Linux 终端

Moshe Zadka 展示了他是如何使用 tmux 和 Git定制化他的 Linux 终端的。Zadka 的文章是个人工作流的优秀探索。他使用 GNOME 终端，用 tmux 和一些能让他快速查看 Git 仓库状态的功能来增强终端。他只需要用一个字母就可以提交文件或把提交推送到远程仓库。

使用 Lazygit 让复杂的 Git 任务简单化

Jesse Duffield 解释了如何使用Lazygit，一个能让使用 Git 变得简单的终端界面。Lazygit 的开发者 Duffield 详细阐述了如何使用这个界面来暂存文件、以交互方式变基、进行筛选、搜索提交以及创建一个 PR。

使用子模块和子树来管理 Git 项目

子模块和子树是两种在 Git 仓库中引入嵌套的子项目的方式。在使用子模块和子树来管理 Git 项目中，Manaswini Das 解释了两个选项的工作原理和区别。

不喜欢 diff？那么试试 Meld

Ben Nuttall 展示了如何使用 Meld 代替 diff来进行对比和合并修改。Meld 是图形化的 diff，输出更容易理解。Nuttall 演示了使用 diff 和 Meld 进行对比的区别。他还解释了 Meld 是如何识别 Git 项目的，这意味着在 Git 中一个文件被提交之后，可以用 Meld 来搜索修改。

你想学习关于 Git 的什么内容？请在评论去分享你的想法。

via: https://opensource.com/article/20/12/git

作者：Joshua Allen Holm 选题：lujun9972 译者：lxbwolf 校对：wxy

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

拥有一致的命名标准是保持本地和上游 Git 仓库保持一致的关键。

当本地 Git 仓库的命名与远程仓库不一致时，与远程仓库协作就会变得很混乱。

解决此问题的一个方法是标准化两个词的使用和含义：origin 指的是你个人的 example.com/<USER>/* 仓库，而 upstream 指的是你从 origin 仓库 复刻 fork 出来的 example.com 仓库。换句话说，upstream 指的是公开提交工作的上游仓库，而 origin 指的是你对上游仓库的本地复刻，例如，你从这里生成 拉取请求 pull request （PR）。

以 pbench 仓库为例，下面是一个逐步建立新的本地克隆的方法，其中 origin 和 upstream 的定义是一致的。

1、在大多数 Git 托管服务上，当你想在上面工作时，必须对它进行复刻。当你运行自己的 Git 服务器时，这并不是必要的，但对于一个公开的代码库来说，这是一个在贡献者之间传输差异的简单方法。

创建一个 Git 仓库的复刻。在这个例子中，假设你的复刻位于 example.com/<USER>/pbench。

2、接下来，你必须获得一个统一资源标识符 （URI），以便通过 SSH 进行 克隆 cloning 。在大多数 Git 托管服务上，比如 GitLab 或 GitHub，它在一个标有 “Clone” 或 “Clone over SSH” 的按钮或面板上，可以将克隆 URI 复制到剪贴板中。

3、在你的开发系统中，使用你复制的 URI 克隆仓库：

$ git clone [email protected]:<USER>/pbench.git

这将以默认名称 origin 来克隆 Git 仓库，作为你的 pbench 仓库复刻副本。

4、切换到刚才克隆的目录：

$ cd ~/pbench

5、下一步，获取源仓库的 SSH URI（你最初复刻的那个）。这可能和上面的方法一样。找到 “Clone” 按钮或面板，复制克隆地址。在软件开发中，这通常被称为“上游”，因为（理论上）这是大多数提交发生的地方，而你打算让这些提交流向下游的仓库。

6、将 URI 添加到你的本地仓库中。是的，将有两个不同的远程仓库分配给你的本地仓库副本：

$ git remote add upstream [email protected]:bigproject/pbench.git

7、现在你有两个命名远程仓库：origin 和 upstream。 你可以用 remote 子命令查看你的远程仓库：

$ git remote -v

现在，你的本地 master 分支正在跟踪 origin 的 master，这不一定是你想要的。你可能想跟踪这个分支的 upstream 版本，因为大多数开发都在上游进行。这个想法是，你要在从上游获得的内容的基础上添加更改。

8、将你的本地的 master 分支改成跟踪 upstream/master：

$ git fetch upstream
$ git branch --set-upstream-to=upstream/master master

你可以对任何你想要的分支这样做，而不仅仅是 master。例如，有些项目使用 dev 分支来处理所有不稳定的变化，而将 master 保留给已批准发布的代码。

9、一旦你设置了你的跟踪分支，一定要变基（rebase）你的 master 分支，使它与上游仓库的任何新变化保持一致：

$ git remote update
$ git checkout master
$ git rebase

这是一个保持 Git 仓库在不同复刻之间同步的好方法。如果你想自动完成这项工作，请阅读 Seth Kenlon 关于使用 Ansible 托管 Git 仓库的文章。

via: https://opensource.com/article/20/11/multiple-git-repositories

作者：Peter Portante 选题：lujun9972 译者：geekpi 校对：wxy

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

使用别名为你最常用或复杂的 Git 命令创建快捷方式。

这篇出色的文章《改变我使用 Git 工作方式的七个技巧》启发了我写下另一个对我在命令行上使用 Git 的经验有重大影响的 Git 特性：别名。

定义 Git 的别名来替代命令有两大好处。

• 它简化了有许多选项的长命令，使它们更短，更容易记住。
• 缩短了经常使用的命令，使你的工作更有效率。

如何定义和使用别名

要定义 Git 的别名，请使用 git config 命令，加上别名和要替换的命令。例如，要为 git push 创建别名 p：

$ git config --global alias.p 'push'

你可以通过将别名作为 git 的参数来使用别名，就像其他命令一样：

$ git p

要查看所有的别名，用 git config 列出你的配置：

$ git config --global -l
user.name=ricardo
[email protected]
alias.p=push

你也可以用你喜欢的 shell 来定义别名，比如 Bash 或 Zsh。不过，用 Git 定义别名有几个功能是用 shell 无法实现的。首先，它允许你在不同的 shell 中使用别名，而无需额外配置。此外，它还集成了 Git 的自动更正功能，所以当你输入错误的命令时，Git 可以建议你正确的别名。最后，Git 还会将别名保存在用户配置文件中，你可以通过复制一个文件将别名转移到其他机器上。

无论使用哪种方法，定义别名都能改善你使用 Git 的整体体验。更多关于定义 Git 别名的信息，请看《Git Book》。

8 个有用的 Git 别名

现在你知道如何创建和使用别名了，来看看一些有用的别名。

1、Git 状态

Git 命令行用户经常使用 status 命令来查看已更改或未跟踪的文件。默认情况下，这个命令提供了很多行的冗长输出，你可能不想要或不需要。你可以使用一个别名来处理这两个组件。定义别名 st 来缩短命令，并使用选项 -sb 来输出一个不那么啰嗦的状态和分支信息。

$ git config --global alias.st 'status -sb'

如果你在一个干净的分支上使用这个别名，你的输出就像这样：

$  git st
## master

在一个带有已更改和未跟踪文件的分支上使用它，会产生这样的输出：

$ git st
## master
 M test2
?? test3

2、Git 单行日志

创建一个别名，以单行方式显示你的提交，使输出更紧凑：

$ git config --global alias.ll 'log --oneline'

使用这个别名可以提供所有提交的简短列表：

$ git ll
33559c5 (HEAD -> master) Another commit
17646c1 test1

3、Git 的最近一次提交

这将显示你最近一次提交的详细信息。这是扩展了《Git Book》中 别名 一章的例子：

$ git config --global alias.last 'log -1 HEAD --stat'

用它来查看最后的提交：

$ git last
commit f3dddcbaabb928f84f45131ea5be88dcf0692783 (HEAD -> branch1)
Author: ricardo <[email protected]>
Date:   Tue Nov 3 00:19:52 2020 +0000

    Commit to branch1

 test2 | 1 +
 test3 | 0
 2 files changed, 1 insertion(+)

4、Git 提交

当你对 Git 仓库进行修改时，你会经常使用 git commit。使用 cm 别名使 git commit -m 命令更有效率：

$ git config --global alias.cm 'commit -m'

因为 Git 别名扩展了命令，所以你可以在执行过程中提供额外的参数：

$ git cm "A nice commit message"
[branch1 0baa729] A nice commit message
 1 file changed, 2 insertions(+)

5、Git 远程仓库

git remote -v 命令列出了所有配置的远程仓库。用别名 rv 将其缩短：

$ git config --global alias.rv 'remote -v'

6、Git 差异

git diff 命令可以显示不同提交的文件之间的差异，或者提交和工作树之间的差异。用 d 别名来简化它：

$ git config --global alias.d 'diff'

标准的 git diff 命令对小的改动很好用，但对于比较复杂的改动，外部工具如 vimdiff 就更有用。创建别名 dv 来使用 vimdiff 显示差异，并使用 y 参数跳过确认提示：

$ git config --global alias.dv 'difftool -t vimdiff -y'

使用这个别名来显示两个提交之间的 file1 差异：

$ git dv 33559c5 ca1494d file1

7、Git 配置列表

gl 别名可以更方便地列出所有用户配置：

$ git config --global alias.gl 'config --global -l'

现在你可以看到所有定义的别名（和其他配置选项）：

$ git gl
user.name=ricardo
[email protected]
alias.p=push
alias.st=status -sb
alias.ll=log --oneline
alias.last=log -1 HEAD --stat
alias.cm=commit -m
alias.rv=remote -v
alias.d=diff
alias.dv=difftool -t vimdiff -y
alias.gl=config --global -l
alias.se=!git rev-list --all | xargs git grep -F

8、搜索提交

Git 别名允许你定义更复杂的别名，比如执行外部 shell 命令，可以在别名前加上 ! 字符。你可以用它来执行自定义脚本或更复杂的命令，包括 shell 管道。

例如，定义 se 别名来搜索你的提交：

$ git config --global alias.se '!git rev-list --all | xargs git grep -F'

使用这个别名来搜索提交中的特定字符串：

$ git se test2
0baa729c1d683201d0500b0e2f9c408df8f9a366:file1:test2
ca1494dd06633f08519ec43b57e25c30b1c78b32:file1:test2

自动更正你的别名

使用 Git 别名的一个很酷的好处是它与自动更正功能的原生集成。如果你犯了错误，默认情况下，Git 会建议使用与你输入的命令相似的命令，包括别名。例如，如果你把 status 打成了 ts，而不是 st，Git 会推荐正确的别名：

$ git ts
git: 'ts' is not a git command. See 'git --help'.

The most similar command is
        st

如果你启用了自动更正功能，Git 会自动执行正确的命令：

$ git config --global help.autocorrect 20
$ git ts
WARNING: You called a Git command named 'ts', which does not exist.
Continuing in 2.0 seconds, assuming that you meant 'st'.
## branch1
?? test4

优化 Git 命令

Git 别名是一个很有用的功能，它可以优化常见的重复性命令的执行，从而提高你的效率。Git 允许你定义任意数量的别名，有些用户会定义很多别名。我更喜欢只为最常用的命令定义别名 —— 定义太多别名会让人难以记忆，而且可能需要查找才能使用。

更多关于别名的内容，包括其他有用的内容，请参见 Git 维基的别名页面。

via: https://opensource.com/article/20/11/git-aliases

作者：Ricardo Gerardi 选题：lujun9972 译者：wxy 校对：wxy

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