【git使用】聊聊那些git使用中的那些牛逼的参数，会用就是资深专家

🕗 发布于 2024-10-09 23:06 git elasticsearch 大数据

引子

我一直希望命令行工具能够体现其各种参数被使用的受欢迎程度的数据，例如：

1- “基本上没人用这个”
2- “80% 的人都在用这个，可以看一下”
3- “这个有 6 个可能的值，但人们在实践中只真正使用这两个”

因此我在 Mastodon 上询问了人们最喜欢的 git 配置选项：

你最喜欢设置的 git config的参数是什么？目前我只有和git config push.autosetupremote true，git config init.defaultBranch main， 对于~/.gitconfig 我很好奇其他人设置了什么

像往常一样，我得到了大量出色的答案，并了解了许多我从未听说过的常见的 git 配置参数。

我将列出这些参数，从（非常粗略地）最受欢迎的选项开始。以下是具体的列表：

1- 仅 pull.ff 或者 pull.rebase true
2- merge.conflictstyle zdiff3
3- rebase.autosquash true
4- rebase.autostash true
5- push.default 简单，push.default 当前
6- init.defaultBranch 主要
7- 提交详细 true
8- rerere.enabled true
9- 帮助.自动更正 10
10- core.pager 增量
11- 差异算法直方图
12- core.excludes文件 ~/.gitignore
13- includeIf：为个人和工作分别设置 git 配置
14- fsckobjects：避免数据损坏
15- 子模块内容
16- 以及更多
17- 如何设置这些
我写这篇文章后所做的配置更改

所有参数可以在在man git-config或本页中查到。

pull.ff only或者pull.rebase true

这两个是最受欢迎的。它们都有类似的目标：避免在git pull上游分支出现分歧的分支上运行时意外创建合并提交。

1- pull.rebase true相当于你每次执行git pull 的时候执行了git pull --rebase
2- pull.ff only相当于你每次执行git pull的时候执行了git pull --ff-only

我很确定同时设置它们两个是没有意义的，因为–ff-only 会让–rebase不生效。

我个人不使用其中任何一个，因为我更喜欢每次决定如何处理这种情况，现在当你的分支与上游分支分叉之后，git 的默认行为就是抛出一个错误并询问你该怎么做（非常类似于所做的git pull --ff-only）。

merge.conflictstyle zdiff3

让merge的冲突更易读：merge.conflictstyle zdiff3并且merge.conflictstyle diff3 这两个参数都比较好用。

现在比较一致的看法是“diff3 很棒，而 zdiff3（较新）甚至更好！”。

那么，怎么去实用 diff3？默认情况下，在 git 中，合并冲突如下所示：

<<<<<<< HEAD
def parse(input):
    return input.split("\n")
=======
def parse(text):
    return text.split("\n\n")
>>>>>>> somebranch

我应该决定是选择input.split("\n")还是text.split("\n\n")更好。但是怎么做呢？如果我不记得\n或是否\n\n正确怎么办？输入 diff3！

以下是设置了merge.conflictstyle diff3 参数后，相同的合并冲突的显示情况：

<<<<<<< HEAD
def parse(input):
    return input.split("\n")
||||||| b9447fc
def parse(input):

    return input.split("\n\n")
=======

def parse(text):
    return text.split("\n\n")
>>>>>>> somebranch

这有额外的信息：现在代码的原始版本在中间！所以我们可以看到：

1- 一方\n\n改为\n
2- 另一边改名input为text

因此，推测正确的合并冲突解决方案是return text.split("\n")，因为它结合了双方的变化。

我没有用过 zdiff3，但很多人似乎认为它更好。博客文章《使用 zdiff3 解决更好的 Git 冲突》对此进行了更详细的讨论。

rebase.autosquash true

Autosquash 对我来说也是一个新功能。目的是让修改旧提交变得更容易。

工作原理如下：

1- 你有一个提交，想将它与 3 个之前的提交合并，比如add parsing code
2- 您使用 提交它`git commit --fixup OLD_COMMIT_ID`，这将为新提交提供提交消息`fix up! add parsing code`
3- 现在，当你执行 `git rebase --autosquash main`，它会自动将所有fixup提交与其目标结合起来。

rebase.autosquash true意味着--autosquash总是自动传递给 git rebase。

rebase.autostash true

git stash自动运行，执行的时机是在git rebase 之前和之后it stash pop。它基本上传递–autostash 给 git rebase。

就我个人而言，我有点害怕这一点，因为它可能会导致rebase后出现merge冲突，但我想这种情况并不经常出现，这是一个常用的配置项。

push.default simple，，push.default currentpush.autoSetupRemote true

这些push 参数意味着会在 git push后自动将当前分支推送到同名的远程分支。
··

1- push.default simple是 Git 中的默认设置。仅当你的分支已和远程分支 tracking时才有效
2- push.default current 类似，但它总是将本地分支推送到具有相同名称的远程分支。
3- push.autoSetupRemote true 有点不同——当你第一次推送分支时，它会自动设置 tracking

我想对比push.default current 我会更喜欢push.autoSetupRemote true，因为 push.autoSetupRemote true还允许你从匹配的远程分支中pull（尽管您确实需要先推送以设置跟踪）。push.default current只允许推送。

我认为使用push.autoSetupRemote true 和push.default current 时唯一需要注意的是，你需要确信自己绝不会意外地创建与不相关的远程分支同名的本地分支。许多人都有分支命名约定（如xxx/my-branch），这使得这种冲突不太可能发生，或者协同办公很少，分支名称冲突可能不会发生。

init.defaultBranch main

创建新 repo 时，创建一个main分支而不是一个master分支。

commit.verbose true

这个参数可以让你提交消息的文本编辑器中添加整个提交差异，以帮助你记住正在做的事情。

rerere.enabled true

这将使 rerere（“重新使用重新解决”），它会尽可能记录 git rebase 和自动为解决冲突期间如何解决合并冲突。

help.autocorrect 10

默认情况下，git 的自动更正功能会尝试检查拼写错误（如git ocmmit），但实际上不会运行更正后的命令。

如果希望它自动执行，可以设置 help.autocorrect 为1（0.1 秒后运行）、10（1 秒后运行）、immediate（立即运行）或prompt（提示后运行）

core.pager delta

pager参数是 git 用来显示git diff、git log、git show等分页输出的。人们将其设置为：

1- delta（带有语法高亮功能的精美差异查看工具）
2- less -x5,9（设置制表位，我猜如果有很多带有制表符的文件，这会有所帮助？）
3- less -F -X（不确定这个，-F如果所有内容都适合一个屏幕，似乎会禁用pager参数，但我的 git 似乎已经这样做了）
4- cat（完全禁用分页）

我曾经使用过它delta，但后来我把它关掉了，因为我不知怎么弄乱了终端的配色方案，而且不知道该如何修复。

我相信 delta 还建议你 interactive.diffFilter delta --color-only在运行时设置语法高亮代码当你在执行 git add -p。

diff.algorithm histogram

Git 默认的 diff 算法通常不能很好地处理重新排序的函数。例如，看看这个 diff：

-.header {
+.footer {
     margin: 0;
 }

-.footer {
+.header {
     margin: 0;
+    color: green;
 }

我觉得这很令人困惑。但是有了diff.algorithm histogram，差异看起来就像下面这样，我觉得更清楚：

-.header {
-    margin: 0;
-}
-
 .footer {
     margin: 0;
 }

+.header {
+    margin: 0;
+    color: green;
+}

有些人也使用patience，但histogram似乎更受欢迎。何时使用每种 Git Diff 算法对此有更多介绍。

core.excludesfile：global .gitignore

core.excludeFiles = ~/.gitignore 允许你设置一个适用于所有仓库的全局 gitignore 文件，用于诸如.idea或.DS_Store 你永远不想提交到任何代码库的内容。它默认为

~/.config/git/ignore。

includeIf：为个人空间和工作空间分别设置 git 参数

很多人说他们用这个来为个人和工作仓库配置不同的电子邮件地址。你可以像这样设置：

[includeIf "gitdir:~/code/<work>/"]
path = "~/code/<work>/.gitconfig"

url.“git@github.com:”.insteadOf ‘https://github.com/’

我经常会意外地clone 代码库的 HTTP 版本而不是 SSH 版本，然后必须手动进入~/.git/config并编辑远程 URL。这似乎是一个不错的解决方法：它将 https://github.com在远程中替换为git@github.com:。

~/.gitconfig由于它有点拗口，所以它看起来是这样的：

[url "git@github.com:"]
insteadOf = "https://github.com/"

一个人说他们使用它pushInsteadOf来只做替换， git push因为他们不想在拉取公共存储库时解密他们的 SSH 密钥。

其他几个人提到了insteadOf = “gh:” 参数以便他们可以执行 git remote add gh:jvns/mysite会打更少的字。

fsckobjects：避免数据损坏

有几个人提到了这一点。有人解释道：“积极检测数据损坏。虽然很少发生，但曾拯救过我的整个团队”。

用下面几个参数去设置

transfer.fsckobjects = true
fetch.fsckobjects = true
receive.fsckObjects = true

submodule stuff

这个参数我不了解，但有几个人说他们有用过，并且很有用：

status.submoduleSummary true
diff.submodule log
submodule.recurse true

我不会尝试解释这些，但是@unlambda 在 Mastodon 上提供了解释。

如何设置这些参数

我通常使用来设置 git 配置选项git config --global NAME VALUE，例如git config --global diff.algorithm histogram。我通常会全局设置所有选项，避免在不同的仓库导致行为不一致问题。

如果我想删除一个选项，我会~/.gitconfig手动编辑，它们看起来像这样：

[diff]
algorithm = histogram

我自己的git 配置更改

我的 git 配置非常简单，我已经有了：

init.defaultBranch main
push.autoSetupRemote true
merge.tool meld
diff.colorMoved default（实际上由于某种原因它对我来说根本不起作用，我自己未验证充分）

我在写完这篇博文后添加了以下 3 条：

diff.algorithm histogram
branch.sort -committerdate
merge.conflictstyle zdiff3

rebase.autosquash如果精心制作带有多次提交的拉取请求现在是我生活中更重要的一部分，我可能也会这样做。

我已经学会谨慎设置新的参数——我需要很长时间才能适应新参数带来的影响，如果我一次改变太多东西，我就会感到困惑。branch.sort -committerdate是我已经在使用的东西（通过别名），而且我很确信，diff.algorithm histogram当我重新排序函数时，这将使我的差异更容易阅读。

全文结束！

我总是惊讶于只需询问很多人他们喜欢什么，然后列出最常提到的内容，就像我几年前整理的这个较新的命令行工具列表一样，很有用。拥有一个包含 20 或 30 个选项的列表比梳理所有 600 个左右的 git 配置选项列表要高效得多

总结这些参数有时候让你是困惑的，因为 git 的默认选项实际上多年来已经改变了很多，所以人们偶尔会设置 8 年前很重要但今天却是默认的选项。此外，人们使用的几个demo的参数已被删除并替换为其他版本。

全文完。

原文地址：https://blog.csdn.net/songguangfan/article/details/142753316

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！

上一篇：【MYSQL】MYSQL约束-----非空约束（not null）和唯一约束（unique）
下一篇：PCL SHOT352描述子

【linux】进程状态与优先级
🔥个人主页Quitecoder🔥linux笔记仓。
阅读更多2024-10-18
一款快速搭建AI知识库的系统，快速建立AI知识库、帮助中心、FAQs、SOPs、说明书、企业博客（附源码）
一款快速搭建AI知识库的系统，拥有强大的功能，包括快速精准的知识检索、灵活定制的文档系统以及AI智-能搜索。
阅读更多2024-10-18
开发中众多框架的个人理解,Unity设计模式，MVC,MVVM框架
在软件开发中，架构模式是设计和组织代码的重要方法。本文将详细介绍三种流行的架构模式：ECS（Entity-Component-System）、MVC（Model-View-Controller）和MV
阅读更多2024-10-18
【vivado】vivado联合modelsim仿真
vivado联合modelsim仿真配置方法
阅读更多2024-10-18
基于深度学习的设备异常检测与预测性维护
基于深度学习的设备异常检测与预测性维护利用智能算法帮助工业企业提升设备的可靠性，降低停机时间和维护成本。随着深度学习技术的不断发展，其在工业自动化中的应用潜力将进一步得到挖掘。
阅读更多2024-10-18
linux grep 问题： Binary file (standard input) matches
在 Linux 中使用grep命令搜索文件时，如果遇到二进制文件（如可执行文件、图片、压缩文件等），grep默认会输出一条警告信息，比如 “Binary file (standard input) m
阅读更多2024-10-18
思迅商云8四级分类
-请确认在系统未正式使用前执行，否则商品类别可能存在关联性问题，正常情况下商品类别是3级2位，超过3级类别，只支持每级1位编码。--以下语句是将商云8转换成6级1位编码。--修改为6级类别，每位编码1
阅读更多2024-10-18
十月编程语言排行榜~
编程语言排行榜分析及未来展望！
阅读更多2024-10-18
【Java 并发编程】阻塞队列与仿真餐厅
生产者和消费者彼此之间不直接通讯，而通过阻塞队列来进行通讯，所以生产者生产完数据之后不用等待消费者处理，直接扔给阻塞队列，消费者不找生产者要数据，而是直接从阻塞队列里取，阻塞队列就相当于一个缓冲区，平
阅读更多2024-10-18
嵌入式开发选硬件还是软件？
然而，单纯的数字硬件工作，如原理图绘制、PCB设计等，，这类工作主要涉及熟悉各种接口和芯片使用，通常在1-3年内就能基本掌握，后续发展可能面临瓶颈，相对来说成长空间较小，也更容易被替代。硬件项目的开发
阅读更多2024-10-18