202503012021 双语 How Core Git Developers Configure Git

Origin: How Core Git Developers Configure Git Author: Scott Chacon

How Core Git Developers Configure Git

Git 的核心开发者会怎么样配置他们的 Git？

What git config settings should be defaults by now? Here are some settings that even the core developers change.

如今哪些 git 设置应该保持默认设置？这是一些甚至核心开发者自己都会改变的设置。

git

A few weeks ago I wrote about Git’s help.autocorrect setting and the strange tale of the origin of it’s deciseconds value.

几周前我写了有关于 Git help.autocorrect 的设置，以及一个不为世人所知的关于该设置其默认值的故事。

It got me to thinking about other git config settings that most people likely don’t know about and which should probably be defaulted differently.

这让我考虑一些其他的 git 设置，大多数人似乎都不知道且应该修改的默认设置。

In this post, I’ll go through some of the perhaps obscure Git config settings that I have personally globally enabled and go into them to explain what they do and why they should probably be the default settings.

本文我将会介绍一些或许令人陌生而我个人通常都会启用的 Git 设置，并且更进一步地解释这些配置做了什么以及为什么他们应该作为所有人的默认设置。

Also, it turns out that I learned most of these from the people who actually work on the core Git codebase every day.

还有，这也体现了我从那些真正在核心git仓库中工作的贡献者学到的大部分知识。

TLDR 太长不看/摘要

First, though, some of you may not particularly care about the wonderful and sordid history of the rerere values or whatever. You may just be thinking “just give me the settings so I can blindly throw them into my ~/.gitconfig file.”

首先，呃，有人可能并不特别关心那精彩、sordid的关于 rerere 值的历史或者其他什么东西。你或许只是在想“直接给我设置代码然后我给它们扔进 ~/.gitconfig 文件里不就完了”

Well, fair enough. Here is the fun stuff:

好吧，那确实。这就是那些我认为必备的配置：

# clearly makes git better 显然会让 git 更好用
 
[column]
        ui = auto
[branch]
        sort = -committerdate
[tag]
        sort = version:refname
[init]
        defaultBranch = main
[diff]
        algorithm = histogram
        colorMoved = plain
        mnemonicPrefix = true
        renames = true
[push]
        default = simple
        autoSetupRemote = true
        followTags = true
[fetch]
        prune = true
        pruneTags = true
        all = true
 
# why the hell not? 为什么不整呢？
 
[help]
        autocorrect = prompt
[commit]
        verbose = true
[rerere]
        enabled = true
        autoupdate = true
[core]
        excludesfile = ~/.gitignore
[rebase]
        autoSquash = true
        autoStash = true
        updateRefs = true
 
# a matter of taste (uncomment if you dare) 看你的口味了
 
[core]
        # fsmonitor = true
        # untrackedCache = true
[merge]
        # (just 'diff3' if git version < 2.3)
        # conflictstyle = zdiff3 
[pull]
        # rebase = true

Copypasta, my friends.

CV 去吧，我亲爱的 CV 工程师。

How do Git core devs configure their Gits?

Git 核心开发者是如何配置他们的 Git的?

Before I dig into these one by one, there is an interesting question about if even the core Git developers think that some of these default values should be changed.

在我深入一个一个讲解配置之前，有一个有趣的问题是，甚至Git的核心开发者都认为一些默认的配置需要修改。

This came up not too long ago on the Git mailing list, and honestly, a few of these settings I personally learned from this thread called “Spring Cleaning” where Felipe Contreras challenged the Git core team to remove all their built up config options and aliases and see what it’s like to use Git stock, out of the box.

这就引出了没太久之前在 Git 邮件列表中，老实说，一些我个人从这个帖子了解到的称作 “Spring Cleaning”的邮件，Felipe Contreras 问 Git 核心开发团队敢不敢去清除所有他们自己弄出来的配置选项和别名，然后看看初始的 Git 用起来是啥样的。

He challenged the list to pay attention to what settings they really wanted to change and share the top settings changes that seemed the most important with the list.

这让他们去关注哪些设置是特别需要去改的，并分享出来一个最需要更改的设置排名。

The results were very interesting, a rather concise list of 9 config settings and 3 aliases that the experiment participants more or less agreed should arguably be new defaults. Let’s just take a look at the proposed config setting changes.

这个挑战的结果很有趣，一个相当简洁的列表，包含 9 个配置和 3 个别名，再多和再少都不能令所有参赛者满意。来简单看一眼这个设置列表：

merge.conflictstyle = zdiff3
rebase.autosquash = true
rebase.autostash = true 
commit.verbose = true
diff.colorMoved = true
diff.algorithm = histogram
grep.patternType = perl
feature.experimental = true
branch.sort = committerdate

Now, none of these have become the new defaults in the 3 or 4 years since this experiment, but it’s interesting that a lot of the Git developers themselves have a hard time using Git without several of these turned on.

如今，没有一个这上面的配置变成新的默认预设，哪怕自那场试验以来已经过了3到4年，不过有趣的是相当多 Git 开发者他们自己都经历过一个没有使用这些配置的艰难使用时期。

Even more interesting is that most of you probably don’t know what any of these do.

更有趣的是，大部分人可能一点都不知道这些配置有什么用。

So, let’s dig into them. What do these do and why should you almost certainly blindly trust me and go ahead and enable them?

好嘞，让我们深入到这些配置之中。它们都起了什么作用以及为什么你几乎一定要无条件地相信我并去开始启用它们？

I’m going to group these settings into three ca89tegories:

我会把这些设置分为以下三组来讲解；

• Clearly Makes Git Better
• Why the Hell Not?
• A Matter of Taste

Let’s get started.

开始开始！

Clearly Makes Git Better

谁不装谁傻子

This first group of settings clearly makes Git better by default. There are generally zero downsides to enabling any of them.

第一组是那些显而易见会令 Git 更好用的设置，和默认相比。开启它们不会有任何坏处。

Listing branches

列出分支

I noted this in a previous blog post here about Git Tips under “Branch Stuff” but as this was also in the Spring Cleaning list, I think everyone agrees that listing out Git branches should probably not be alpha-ordered by default.

我在上一个博客中有写关于在 “分支的玩意” 中的 Git Tips，不过这个也在 Spring Cleaning 设置列表中，我可以认为每个人都会同意，Git 分支的展示排序大概不应该是默认为字典序。

The two settings which help improve this are branch.sort and column.ui. The first of which sorts the list by the most recent commit date (so probably more interesting at the top) rather than by alpha order. The second will put the branch names in a column format so you can see more per screen.

branch.sort 和 column.ui 这俩配置可以改善这点。第一个配置可以将分支列表以最新提交日期排序（因此更有趣的大概会排更前）而不是字典序。第二个配置会把分支列表以一个表格形式展示所以你可以在一屏中浏览更多内容。

git config --global column.ui auto
git config --global branch.sort -committerdate

The column.ui setting also affects the output of other listing commands (clean, status, tag), but generally I think it’s better than the default.

column.ui 设置也会影响其他会默认以列表展示的信息（如 clean，status，tag），不过通常情况下我觉得这样的展示形式比默认的好。

You can also sort by other things than committer date, but I think it’s pretty clearly the most useful one.

你也可以根据其他东西排序而不只是提交日期，不过我觉得提交日期排序很明显是最有用的一个。

Listing tags

列出标签

Speaking of listing things, it’s also pretty ridiculous that this isn’t the default for listing tags, since it’s what nearly everyone actually wants.

说到列出东西，相当不可理喻的是这居然不是列出标签的默认配置，哪怕这几乎是每个人都需要的。

Normally, if you list tags by alpha order, you’ll get something like this:

通常来说，如果你以字典序列出所有标签，输出大概长这样：

$ git tag
nightly/0.5.100
nightly/0.5.1000
nightly/0.5.1001
nightly/0.5.101
nightly/0.5.1010

Nobody wants 0.5.101 to come after 0.5.1000, but that’s alpha order. You can fix this by setting this:

谁会想要 0.5.101 在 0.5.1000 后面？就因为是字典序吗？你可以通过这个设置来解决这个问题：

git config --global tag.sort version:refname

Which will generally do what you expect, treating dotted version numbers as a series of integer values for sorting purposes. Trust me, just enable this.

它通常会像你希望的那样起作用，让小数点组成的版本号以一个数字值的形式来进行排序。别管了，直接开就行，没坏处的。

Default branch

默认分支

This one may be a little more controversial, since it can be argued to be somewhat political, but there should be a default branch name in Git where it doesn’t complain every time you init a new repo.

这点可能会有些争议，甚至其可以被争论到什么什么政治，不过在 Git 中还是应该有一个默认的分支名，Git 并没有对此有解释，当你每次初始化一个新的仓库时。

git config --global init.defaultBranch main

Personally, I don’t have a problem with master and most of my repositories use that since that used to be the default, but I’m also fine with main, so whatever it is you want to use, just go ahead and set it.

就我而言，我不会觉得以 master 为默认分支有什么问题，自从这个为默认设置后我大部分仓库都是 master 为初识分支，但我也觉得 main 作为默认分支挺好，所以不论你想用哪个，直接去用然后设置就行。

Mostly what I find stupid is that now Git is annoying about this rather than just updating the default value. I wish Git had some taste here, but they don’t, so you should just set it to something you find reasonable. But whatever.

很大程度上我发现很蠢的地方是，现在的 Git 在这点上很令人恼火而不是直接去更新为默认值。要是 Git 能在这个地方有点品位就好了，可惜没有。你可以设置它为你觉得合理的名字，随你。

Better diff

更好的差异对比

There is actually a whole blog post that could be written about git diff algorithms, but the short story is that by default Git will use an old, fast, pretty reliable diff algorithm called “myers diff”.

关于 git diff 的算法完全可以用一整个文章的篇幅来讲，但长话短说，Git 的默认算法是一个老的、速度快、相当可靠的差异对比算法 “myers diff”。

To give you a sense of what ‘old’ means, it was first published in a paper in 1986, so it’s almost 40 years old now. If you’re as old as I am, perhaps I can give you some childhood perspective as to what that means. The movies ‘The Three Amigos’, ‘An American Tail’ and the first ‘Highlander’ came out in theaters that year.

你可能不太清楚到底有多 ‘老’，它起初被发布在一个 1986 年的论文中，所以至今几乎有 40 年了。如果你跟我一样老，我可以举一些童年印象来解释。 ‘The Three Amigos’, ‘An American Tail’ 和首部 ‘Highlander’就是在那一年发布的。

In any case, some advances have been made since then (with some tradeoffs too) and it may surprise you to know that Git actually ships with 4 built in diff algorithms it can use: myers, minimal, patience and histogram.

不管如何，自那个算法发布后，差异比对算法已经有了很多发展（也有一些取舍），而可能让你惊讶的是 Git 实际上默认内置了 4 个能用的差异比对算法：myers，minimal，patience 和 histogram。

Almost certainly what you want to be using is the histogram algorithm (an incremental improvement on ‘patience’), rather than the default of ‘myers’. You can globally change it like this:

在这些之中，你想用的几乎肯定是 histogram 算法（在“耐心”上渐进提升），而不是默认的 ‘myers’。你可以像这样设置全局配置来更改：

git config --global diff.algorithm histogram

Here is an example of simple code movement diffed in myers vs histogram, to give a short taste of how it can be a bit smarter:

这有一个简单的代码移动案例，浅试一下来说明 histogram 是如何比 myers 更加智能的：

Let’s say we move a css class below a similar one, change it a little, and then run git diff with the default myers algorithm. We may get something like this:

假如我们移动一个 css 类在一个相似的类下面，稍作修改，然后跑一个使用默认 myers 算法的 git diff，大概会得到这个结果：

Ok, a little confusing. Here is what histogram would give us in the same scenario:

彳亍，有点困惑了。这是在同样的情景下 histogram 算法会给我们的结果：

It’s a bit more clear here what’s actually happened.

这就让实际发生了啥看起来更加清晰了。

As recently as last year, Elijah (of our Git Merge fame) suggested that
histogram or patience might make better defaults, in addition to Felipe’s Spring Cleaning suggestion of the same thing, but in reality it’s unlikely to get through the gauntlet anytime soon.

最近，就上一年，Elijah（我们的 Git Merge Fame）表示 histogram 或者 patience 或许比默认的效果更好，另外 Flipe 的 Spring Cleaning 也提了一样的建议，但实际上似乎并没有实际设置为默认在之后的时间。

That’s a big one, but there are also a few more smaller tweaks you can make to git diff:

上面是主要的部分，不过也有一些你能做的关于 git diff 的小优化：

git config --global diff.colorMoved plain
git config --global diff.mnemonicPrefix true
git config --global diff.renames true

The colorMoved was also in the Spring Cleaning suggestion list, so it also should probably be a default change.

colorMoved 也是在 Spring Cleaning 的建议列表中，所以也是大概率应该作为一个默认设置。

Here is an example of the previous code movement with the colorMoved turned on:

这是之前那个代码移动样例，开启 colorMoved 后的效果：

You can see actually the difference between the moved code and the added line. With colorMoved it will show code movement in different colors then added and removed lines.

你可以明显看到代码中移动的行和新增的行的区别。colorMoved 会以颜色来区分移动、新增和删除的行。

The diff.renames option will detect if a file has been renamed, which is generally good (if slightly more expensive) and diff.mnemonicPrefix will replace the a/ and b/ in your diff header output with where the diff is coming from, so i/ (index), w/ (working directory) or c/ commit.

diff.renames 配置项会检测是否有文件被重命名，通常来说很不错（如果说稍微点耗性能）而 diff.mnemonicPrefix 可以在你的差异头部输出关于差异来源的部分，替代 /a 和 b/，改用 i/（index），w/（工作目录） 或者 c/ 提交。

So if I diff a change in my index to my working directory I get this as my diff header instead:

所以如果我差异比对一个更改在 index 到我的工作目录，会用这样的显示结果代替：

❯ git diff
diff --git i/apps/web/page.js w/apps/web/page.js
index 7568be2ef..b9e9a00d7 100644
--- i/apps/web/page.js
+++ w/apps/web/page.js

A little difficult to see in this example perhaps, but you can tell which side is from the index and which is from the working directory by the leading path names. It’s really subtle, but I like it.

可能在这个样例中不太能看得出来，不过哪边来自暂存区，哪边来自工作目录通过最开始的前缀你就可以分辨出来。这是个很微妙的细节，不过我喜欢。

Better pushing

更好的推送

One of the things that has continued to confuse and frustrate me since the very early days of Git is setting up tracking branches properly. When I push, where does it push, or does it push at all?

有一件事一直让我感到困惑和沮丧，自从相当早期时候 Git 设定跟踪分支这个东西。当我推送的时候，它会推送到哪里？或者它会全部推送吗？

There are three updated push settings that I think make for a much nicer default experience. The first (push.default simple) has been the new default since Git 2.0, but the others still need to be set explicitly.

有三个 push 的设置更新我觉得实现了一个更棒的默认体验。第一个是 push.default simple ，自从 Git 2.0 以及成为了默认设置，但是剩下的两个依然要单独设置。

git config --global push.default simple # (default since 2.0)
git config --global push.autoSetupRemote true
git config --global push.followTags true

This has always been a bit of a pain in Git. The new simple default is built more or less for centralized workflows and by default pushes the current branch to the same name on the remote. I think this is a pretty sensible default.

在 Git 中总会有一些痛点。新的 simple 默认设置是实现了或多或少的集中式工作流，默认推送当前分支到同名的远程分支上。我觉得这作为默认设置很合理。

However, if that branch does not exist and there is no tracking branch setup, you’ll still get this error:

然而，如果那个远程分支不存在而目前分支又没有设置跟踪分支，你仍然会遇到报错：

$ git push
fatal: The current branch my-branch-name has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin my-branch-name

I have to imagine that you have all seen this roughly one million times.

我甚至能猜你得有一百万次 看到这个报错。

If you set push.autoSetupRemote to true, then you won’t get this error anymore. If the upstream is not set, it will automatically set it. I cannot tell you how much I love this setting.

如果你设置 push.autoSetupRemote 为 true，之后你就再也不会碰见这个错误了。如果上游分支没有设置，它会自动创建一个。我都说不出来我有多喜欢这个设置。

Finally, the push.followTags setting will push all tags that you have locally that aren’t on the server, every time you push anything. I’ve been bitten by this a few times - if you ever create tags locally, set this up so you don’t have to worry about other people not seeing them.

最后是关于 push.followTags，它会推送所有你本地有而远程仓库中没有的标签，在无论任何时候你推送的时候都会这么做。我已经被这个折腾了好几次，除非你从不在本地创建标签，把这个配置上后你就不用再担心其他人看不到这些标签。

Better fetching

更好的拉取

It can be argued that it’s nice to keep some historical local copies of branches and tags that used to be on the server but are not any longer, but I don’t really buy that.

这会有点争议，是关于之前在远程仓库中使用但后来不再用了的分支和标签，是否要保持一份本地的历史性拷贝的问题，不过我对这并不买账。

Personally, I think the default behavior of Git should be to make your remote references as close to what is on the remote as possible. Prune stuff that’s gone, etc.

就我而言，我觉得 Git 默认行为应该把你的远程引用和在远程仓库中的部分尽可能接近。批量清理无用的更好之类的。

So, I think these fetch settings should be the default:

所以我觉得得配置这些拉取操作设置为默认：

git config --global fetch.prune true
git config --global fetch.pruneTags true
git config --global fetch.all true

Really all that this does is make sure we delete origin/blah if blah is deleted on the server, and also do it automatically for all the remotes that we have configured. Seems pretty reasonable to me.

实际上所有这些实现了确保我们删除本地的 origin/blash 时，如果 blah 在远程分支中也有，Git 会自动为所有配置的远程仓库中删除该分支。对我来说似乎很合理。

Why the Hell Not?

为啥不整呢？

This next batch of settings are generally harmless and occasionally helpful.

下一组设置通常来说是无害而且有时会很有用。

I’m not sure I would necessarily change the defaults, but I also don’t think it would hurt anyone and in many cases would be more helpful, so I’m including them in my list.

我不太确定改掉这些默认是否是必要的，不过我也不觉得这会有啥危害，而且在某些时候会很有用，所以我在推荐列表中包含了它们。

Autocorrect prompting

自动纠正提示

As I explained in great length in my previous post, there is a rather nice feature in Git where if your fingers trip up while typing a command, it will guess what you meant and try to run it.

正如我在上一个巨长的博客中解释到，在 Git 中有一个相当棒的特性，当你在输入一个命令时手指打结出错，它会猜测你的意图然后尝试去纠正并运行。

The default is to not do this at all. What I rather prefer is to guess and prompt you.

默认设置下 Git 一点都不会这么做。我更喜欢猜测然后提示你正确的指令。

git config --global help.autocorrect prompt

If you want to read about this setting, it’s reasoning and it’s history ad nauseam, I have just the post for you.

如果你想了解更多关于这个设置的内容，这儿有个合理，冗长的给你看的文章。

Commit with diffs

带着差异提交

This was also one of the suggestions in the Spring Cleaning list, I think mostly because it just adds more information to the context you can reference when you write your commit message in your editor.

这也在 Srping Cleang 推荐的设置列表中，我很大程度上认为是因为它仅仅给提交上下文加了更多你可以引用的信息，当你在编辑器中写你的提交信息时。

By default, a git commit will give you a message that looks something like this:

默认情况下，git commit 会给你一个长得像这样的提交信息：

Where there is just a list of files that were changed. If you set commit.verbose to be true, it will put the whole diff output in there for you to reference as you write your message.

这只是一个更改过的文件的列表。如果你设置 commit.verbose 为 true，会让整个 diff 的输出放在这，用于让你在写提交信息时候引用。

git config --global commit.verbose true

Here’s what it looks like now when you go to commit:

这是当你去提交时候会显示的东西：

All of this will be removed from the commit message (everything under the hilarious -- >8 -- “scissors” line), but it can give you much more context in writing your message.

所有差异结果都会在你提交信息时候被移除（即所有在 ---- 分割线下方的内容），不过这样可以在你写提交信息的时候显示更多的上下文。

Reuse recorded resolutions

复用记录过的解决方案

This setting is only useful if you’re doing rebases with conflicts over and over again. It’s not the most common situation, but there is not really an issue if it’s turned on and never used.

这个设置只会在你一次又一次地带着冲突进行变基的时候会有用。这并不是最普遍的情况，不过把它们开着不用也并非一个问题。

git config --global rerere.enabled true
git config --global rerere.autoupdate true

The enabled option will make sure it records the before and after states of rebase conflicts and the autoupdate will automatically re-apply the resolutions if it sees them again. I wrote about this at some length over here, so I won’t bore you with the recap any further.

enabled 选项会确保 Git 会记录变基冲突的之前和之后的状态，而 autoupdate 会自动复用之前的解决方案，如果在遇到类似的情况。我在这个文章中写了一些介绍，OK我不会再烦你了。

Global ignore file

全局忽略文件

This is pretty dumb, but as there is a ~/.gitconfig file with global values, it would be cool if there were a ~/.gitignore file with global values. This setting accomplishes that:

这看起来挺蠢，不过正如有一个全局设置文件 ~/.gitconfig，再有一个全局忽略文件 ~/.gitignore 也很酷。可以通过这个命令应用：

git config --global core.excludesfile ~/.gitignore

In reality, this is sort of unnecessary, since Git will already look for global ignore values in the following two places: ~/git/ignore and ~/.config/git/ignore but since those are a little obscure, I feel like it’s nice to have this more guessable path.

实际上，这有点没必要，因为 Git 已经会查看全局忽略值在接下里这两个地方：~/git/ignore 和 ~/.config/git/ignore 不过由于它们藏得有点隐蔽，我觉得用上述更容易猜的路径会更棒。

Slightly nicer rebase

稍微好点的变基

This section mostly has to do with the use case where you’re fixing up and squashing your commits. If you don’t know what that is, please check out our previous blog post on autosquashing.

这个部分主要是那些你不得不做的实例，即你正在修复和压缩你的提交的时候。如果你不知道是啥，请查看一下我们上一个博客。（说好的不烦我呢）

However, if you are squashing and rebasing a lot (or even occasionally), these settings could help and certainly won’t hurt things.

然而，如果你是压缩和变基了很多东西（或甚至偶然之中），这些设置可以起到帮助且确实不会有什么危害。

git config --global rebase.autoSquash true
git config --global rebase.autoStash true
git config --global rebase.updateRefs true

The updateRefs setting should almost certainly be a default, honestly. It just takes stacked refs in a branch and makes sure they’re also moved when a branch is rebased.

updateRefs 设置几乎应该确实作为默认设置，老实说。它只是获取在分支中堆叠着的引用，并确保他们在分支变基时候也跟着移动过去。

If you want to learn a tiny bit more about how to use fixup, autosquash and updateRefs, it’s probably easiest to watch a few minutes of a talk where I go over it here:

如果你想多学一点关于如何使用 fixup、autosquash 和 updateRefs，或许更简单的方式是去看一个我贴这的几分钟讲解视频：

A Matter of Taste

看你的喜好

The next group is based on your personal taste, but most people don’t know they exist and a lot of people may find them useful. They are commented out in my TLDR settings.

下一组配置是看你个人的喜好，不过大部分人并不知道有这些配置，而且很多人会发现这些很有用。这些是在我 TLDR 中被注释掉的配置。

Better merge conflicts

更好的合并冲突

So, while this is brought up in the Spring Cleaning thread as something that might want to be the new default, I’m not sure that all of you would agree.

好，然而这个在 Spring Cleaning 讨论中是被当做一些可能会像作为新默认设置被提出来，我并不确定你们所有人都会同意这样。

When you have a merge conflict in Git, instead of inserting the conflict markers from left and right, you can ask it to insert what the base of it looked like too. Sometimes this can be really useful, but some people can find it pretty annoying.

当你在 Git 中有一个合并冲突，与其从左到右插入冲突标记，你也可以说插入是基于那些提交的信息也会不错。有时候这会很有用，但也有人觉得这很烦人。

git config --global merge.conflictstyle zdiff3

There have been discussions on the Git mailing list to make this the default and actually GitButler uses the diff3 strategy when dealing with merge conflict markers and to be totally honest, not all of us love it.

这已经在 Git 邮箱列表中讨论关于它作为默认设置，实际上 GitButler 在进行冲突标记时就使用 diff3 策略，老实说，并不是我们所有人都喜欢这个方案。

Here is an example of a simple merge conflict marker you might get in a file when doing a merge or rebase:

这有个合并冲突标记样例，当你在进行合并或变基时或许会遇到类似的：

With the merge.conflictStyle zdiff3 setting, it would look like this:

使用 merge.conflictStyle zdiff3 设置时，看起来是这样的：

Essentially, in addition to the <<<<<< and >>>>>> sections that show you how you changed the block and how the other person changed it, it adds a ||||||| block that shows you what the block looked like before either of you changed it.

本质上，加入 <<<<< 和 >>>>> 部分来展示你要如何修改的部分，以及其他人怎样修改的，加入 ||||| 部分来展示在你们任何一个人修改之前是什么样子的。

That extra context (what that section looked like before either side modified it) can sometimes be super useful, but often it’s just more data and somewhat confusing.

这额外的内容（该部分在双方修改之前是什么样的）在某些时候是非常有用，不过更多时候它就只是多了点数据而且或许令人困惑。

Really, it’s up to you if you prefer more data there.

实际上，这取决于你，如果你更喜欢在这展示更详细的数据。

⚠️ Git has nearly always had diff3 as a strategy. I’m recommending zdiff3 here, which stands for “zealous diff3” and is slightly better, but only available since Git 2.35 (Jan 2022). If you have an older Git version, just remove the “z”.

Git 已经几乎总是有 diff3 作为策略。我在这里推荐 zdiff3，其是 “zealous diff3” 的标准版且会稍微更好点，不过只在 Git 2.35（2022年一月）之后的版本会有。如果你使用一个更老的 Git 版本，只需要去掉 z 就行。

Better pulling

更好的拉取

The merge versus rebase debate is of course one that may never be agreed upon, but most of us have a preference. However, you may not know that you can set the git pull default so that it will only do one or the other. No need for git pull --rebase, you can make it the default:

当然，合并和变基的争辩可能永远不会达成一致，但我们大多数人都有自己的偏好。然而，你可能不知道你能设置 git pull 的默认行为，从而它只会做其中一个或另一个。不再需要用 git pull --rebase，你可以设置其为默认：

git config --global pull.rebase true

This is a personal decision, but as I’ve migrated to the rebase only camp recently, it is in fact in my config.

这是一个因人而异的选择，不过由于我最近转移到了 rebase 阵营，所以它实际上在我的配置中。

Run the fsmonitor processes

运行 fsmonitor 进程

Again, this is really only a thing for larger repositories, and maybe you don’t want filesystem monitors running all over the place, but it can make things like git status much faster if you have big working directories.

同样，这真的只是一个关于更大的仓库的东西，而你可能不会想要一个文件系统监视器跑在各种地方，不过它可以让一些东西比如 git status 更快，当你有一个很大的工作区时。

Maybe it shouldn’t be a default, but it’s not very bad and can make a big difference. Maybe git clone should ask you if you want to set it or not. Whatever, it’s an option for you.

或许这不应该作为预设，不够这也不是特别坏到能有很大的区别。或许 git clone 应该询问你是否想设置它。总之，这取决于你的选择。

git config --global core.fsmonitor true
git config --global core.untrackedCache true

This will run a filesystem monitor (per repository) that notices file changes and updates a cache so that git status doesn’t have to crawl every file and see if anything changed via a thousand mtime stat calls, it can just look at a simple log of file changes.

这会运行一个文件系统监视器（每个仓库都有），会关注文件更改然后更新缓存，从而让 git status 并不必爬取每个文件，也不需要通过一千个 mtime stat 调用来查看是否有任何变化，它只需要查看一个简单的文件变化日志。

⚠️

Be aware that this will run a single process per repository that you are active in, which can be a lot. They mostly don’t do much as they’re event based, so it shouldn’t affect memory or CPU noticeably, even with hundreds of them, but it’s something to keep in mind. You can also leave out the --global and just enable it for your larger repos.

注意这会对每一个你激活的仓库都启动一个单独的进程，这可能有点多。它们大部分并不会做太多因为是基于事件的，所以应该不会显著影响内存或CPU，哪怕有几百个，不过这点确实是需要知道的。你也可以去掉 --global 参数来让其仅仅在你最大的仓库中启用。

Final thoughts

最后的想法

Hopefully this has been a useful reference and maybe you learned some new Git config things, some of which should almost certainly already be the defaults, which isn’t even a controversial option in the Git mailing list community.

希望这是一个有用的参考，也许你学到了一些新的 Git 配置知识，其中某些几乎可以肯定已经成为默认配置，它们甚至在 Git 邮件列表社区中都不是一个有争议的选项。

There are lots of other ways to pimp your Git ride (aliases, cool external pager and diff tools, things like that) but I thought it would be best to just stick to globally useful and relatively simple vanilla Git settings.

还有很多其他方法可以让你的 Git 之旅变得更好（别名、很酷的第三方 pager 和 diff 工具，诸如此类），但我认为最好只坚持使用全局有用quest相对简单的原版 Git 设置。

Hope you enjoyed this and see you next time!

希望你喜欢这个，下次见！

总结

在我配置 Mac 笔记本的时候抄了一个up主的作业，其中也有关于命令行的配置，大伙可以看看，很干货：15年经验老程序员教你从0开始配Mac_哔哩哔哩_bilibili。（不过怎么笔记突然要进知识星球才能看了，之前还可以的）。