自定义Git配置
配置工具
Git自带一个配置管理工具：git config
NAME
git-config - Get and set repository or global options
SYNOPSIS
git config [<file-option>] [type] [--show-origin] [-z|--null] name [value [value_regex]]
git config [<file-option>] [type] --add name value
git config [<file-option>] [type] --replace-all name value [value_regex]
git config [<file-option>] [type] [--show-origin] [-z|--null] --get name [value_regex]
git config [<file-option>] [type] [--show-origin] [-z|--null] --get-all name [value_regex]
git config [<file-option>] [type] [--show-origin] [-z|--null] [--name-only] --get-regexp name_regex [value_regex]
git config [<file-option>] [type] [-z|--null] --get-urlmatch name URL
git config [<file-option>] --unset name [value_regex]
git config [<file-option>] --unset-all name [value_regex]
git config [<file-option>] --rename-section old_name new_name
git config [<file-option>] --remove-section name
git config [<file-option>] [--show-origin] [-z|--null] [--name-only] -l | --list
git config [<file-option>] --get-color name [default]
git config [<file-option>] --get-colorbool name [stdout-is-tty]
git config [<file-option>] -e | --edit
常用的命令：
# 加 --global 选项表示针对全局配置，不加只针对当前仓库
git config user.name johnsmith # 用户名
git config user.email [email protected] # 邮件
git config --list # 查看配置
配置文件
Git的配置文件一般存储在以下三个位置：
-
/etc/gitconfig文件：系统上每一个用户的配置使用
git config --system [options]来配置。 -
~/.gitconfig或~/.config/git/config文件：当前用户的配置使用
git config --global [options]来配置。 -
.git/config文件：当前仓库的配置。使用
git config --local [options]或git config [options]来配置。
以上三个级别每一个级别会覆盖上一个级别的配置，除了使用配置工具配置外，还可以直接创建或者打开文件配置。
Git的配置文件有四种类型：
gitconfig文件
Git基础配置，包括比较工具，配色，提交信息，以及一些别名等，可以通过man git-config查看所有配置选项。
gitignore文件
Git提交时忽略的文件以及目录，全局建议放文件系统生成的一些文件，例如.DS_Store和Thumbs.db等。
格式规范
- 所有空行或者以
#开头的行都会被Git忽略 - 可以使用标准的glob模式匹配
- 匹配模式可以以
/开头防止递归 - 匹配模式可以以
/结尾指定目录 - 在模式前加
!取反，忽略指定模式以外的文件或目录
# no .a files
*.a
# but do track lib.a, even though you're ignoring .a files above
!lib.a
# only ignore the TODO file in the current directory, not subdir/TODO
/TODO
# ignore all files in the build/ directory
build/
# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt
# ignore all .pdf files in the doc/ directory
doc/**/*.pdf
更多特定语言的示例详见 github/gitignore，也有一些非常不错的在线工具自动生成通用的.gitignore文件，如：https://www.gitignore.io/ 具体还需要参照自己的项目。
gitmessage文件
Git提交文件模板，对规范团队提交信息非常有用。混乱的提交信息会增加团队的交流成本，尤其当项目非常大，协作开发成员非常多的时候这一点体现更加明显，所以很多大规模的开源软件都会定制自己的规范让开发者去遵守。
gitattributes文件
针对特定的路径配置某些设置项，这样Git就只对特定的子目录或子文件集运用它们，包括单独定义不同的比较，提交或合并策略等，比如有的文件表面上是文本文件，但实质上应该当作二进制文件处理。例如xcode项目中的.pbxproj文件，它通常是一个记录项目构建配置等信息的JSON数据集，没有必要被当作文本文件，于是我们可以在.gitattributes文件中设置如下：
*.pbxproj binary
现在Git在show或者diff操作中不会打印这类文件的变化了。
除此之外还可以定义一些特殊文件的比较工具，比如图片，可以指定名为exif的策略提取EXIF信息进行比较。
*.png diff=exif
在.gitconfig配置文件中设置exif：
git config diff.exif.textconv exiftool
示例配置
以下是我自己经常使用的三个配置文件，供大家参考，后续更新在 tarrex/dotfiles 。
gitconfig文件
#
# This is the config file, and
# a '#' or ';' character indicates
# a comment
#
; core variables
[core]
fileMode = false
editor = vim
pager = less -FRX
excludesFile = ~/.gitignore
[diff]
renames = true
tool = vimdiff
[difftool]
prompt = false
[merge]
# ff = only
# conflictstyle = diff3
[commit]
gpgSign = false
[push]
default = simple
followTags = false
[status]
showUntrackedFiles = all
[transfer]
fsckobjects = false
[gist]
private = yes
[user]
name = johnsmith
email = [email protected]
[github]
user = johnsmith
[alias]
st = status -sb
prune = fetch --prune
undo = reset --soft HEAD^
stash-all = stash save --include-untracked
[color]
diff = auto
status = auto
branch = auto
interactive = auto
[color "branch"]
current = yellow
local = green
remote = cyan
upstream = magenta
plain = red
[color "diff"]
context = cyan
meta = yellow
frag = magenta
old = red
new = green
commit = white
whitespace = red reverse
[color "status"]
added = green
changed = yellow
untracked = red
[rerere]
enabled = 1
autoupdate = 1
[filter "lfs"]
process = git-lfs filter-process
required = true
clean = git-lfs clean -- %f
smudge = git-lfs smudge -- %f
gitignore文件
*.DS_Store
Thumbs.db
*.o
*.out
*.py[cod]
*.class
gitmessage提交模板
# ---------- Header --------
# <type>(<scope>): <subject>
# # Allowed <type> values:
# * feat (new feature for the user, not a new feature for build script)
# * fix (bug fix for the user, not a fix to a build script)
# * docs (changes to the documentation)
# * style (formatting, missing semi colons, etc; no production code change)
# * refactor (refactoring production code, eg. renaming a variable)
# * test (adding missing tests, refactoring tests; no production code change)
# * chore (updating grunt tasks etc; no production code change)
# # Example <scope> values:
# init runner watcher config web-server proxy etc.
# # 50-character subject line
#
# ---------- Body ----------
# 72-character wrapped longer description. This should answer:
# * Why is this change necessary?
# * How does it address the issue?
# * What side effects does this change have?
#
# ---------- Footer --------
# # Referencing issues:
# Example:
# Closes #123, #245
# # Breaking changes:
# must start with 'BREAKING CHANGE:'
# Example:
# BREAKING CHANGE: this is a big change.
# Before:
# ...
# After:
# ...
# HowToMigrate:
# ...
# # Revert:
# revert: <commit header>
# Example:
# revert: test(test): add function test