初学者文档

Git 教程：第 1 部分，第 2 部分。

Git 用户手册。 大约 20 个命令的日常 Git。 Git 工作流程。

高级文档

Git 魔法，有多种翻译版本。

Pro Git。关于 Git 的书籍。可在亚马逊购买或下载 PDF、mobi 或 ePub 格式。它有多种语言的翻译版本。从 GArik 下载俄语翻译版本。

Git Wiki.

Git Buch（德语）。

离线文档

Git 具有内置帮助：运行 git help $TOPIC。例如，运行 git help git 或 git help help。

下载和安装

Unix 用户：使用您的包管理器下载和安装。

Microsoft Windows：下载 git-for-windows。

MacOS X：使用随 XCode 安装的 Git，或从 MacPorts 或 git-osx-installer 下载，或使用 Homebrew 安装 Git：brew install git。

git-cola (仓库) 是一个用 Python 编写的、基于 GPL 许可的 Git GUI。适用于 Linux、Windows 和 MacOS X。

TortoiseGit 是一个基于 TortoiseSVN 的 Windows Shell Git 接口；开源。

初始配置

这段简单的代码经常出现在文档中，但它很重要，所以在这里重复一下。Git 在每个提交中都存储作者和提交者的姓名/电子邮件，因此请配置您的真实姓名和首选电子邮件

$ git config --global user.name "User Name"
$ git config --global user.email user.name@example.org

更新本地和远程跟踪分支

要更新远程跟踪分支而不更新本地分支，请运行 git remote update [$REMOTE...]。例如

$ git remote update
$ git remote update origin

$ git fetch $REMOTE $BRANCH

$ git fetch $REMOTE $BRANCH:$BRANCH

$ git pull $REMOTE $BRANCH

$ git fetch $REMOTE $BRANCH
$ git merge FETCH_HEAD

$ git fetch origin v1:v1  # Update v1
$ git pull --rebase origin master  # Update the current branch master
                                   # using rebase instead of merge
$ git merge v1

$ git checkout v1
$ git pull --rebase origin v1
$ git checkout master
$ git pull --rebase origin master
$ git merge v1

$ git pull origin

$ git pull

$ git push origin v1 master

$ git push origin v1:v1 master:master

$ git push origin

$ git push

$ git config push.default simple

$ git config push.default matching

$ git fetch origin tag $TAG1 tag $TAG2...

$ git fetch origin tag 1.4.2
$ git fetch origin v1:v1 tag 2.1.7

$ git push origin tag 1.4.2
$ git push origin v1 master tag 2.1.7

$ git push --tags origin

git checkout：恢复文件的內容

git checkout例如，可以用来将文件的内容恢复到某个提交的内容。例如：

git checkout HEAD~ README

该命令将 README 文件的内容恢复到当前分支的倒数第二个提交。默认情况下，提交 ID 只是 HEAD；即 git checkout README 将 README 恢复到最新的提交。

（不要使用git checkout查看提交中文件的内容，请使用git cat-file -p；例如git cat-file -p HEAD~:path/to/README）。

git reset：删除（未推送的）提交

git reset移动当前分支的头部。头部可以移动到指向任何提交，但它通常用于从分支顶部删除一个或几个（最好是未推送的）提交——也就是说，向后移动分支以撤消几个（未推送的）提交。

git reset 有三种操作模式——软重置、硬重置和混合重置。默认模式是混合重置。ProGit清楚地解释了它们之间的区别。裸仓库没有索引或工作树，因此在裸仓库中只允许软重置。

git reflog：引用日志

使用git reset删除提交或移动分支的头部听起来很危险，确实如此。但是有一种方法可以撤消：另一个重置回原始提交。Git 不会立即删除提交；未引用的提交（在 Git 术语中称为“悬空提交”）会在数据库中保留一段时间（默认是两周），因此您可以重置回它或创建一个指向原始提交的新分支。

对于每次移动分支的头部——使用git commit、git checkout、git fetch、git pull、git rebase、git reset等等——Git 会存储一个引用日志（简称 reflog）。对于每次移动，Git 都会存储头部的先前位置。命令git reflog可用于查看（和操作）日志。

除了每个分支的头部移动之外，Git 还会存储 HEAD 的移动——一个符号引用，它（通常）命名当前分支。HEAD 会随着git checkout $BRANCH而改变。

默认情况下，git reflog显示 HEAD 的移动，即该命令等效于git reflog HEAD。要显示分支头部的移动，请使用命令git reflog $BRANCH。

因此，要撤消git reset，请在git reflog中查找原始提交，使用git show或git log验证它，然后运行git reset $COMMIT_ID。Git 会将分支头部的移动存储在 reflog 中，因此您可以稍后再次撤消该撤消操作。

在更复杂的情况下，您可能希望在重置分支的头部时同时移动一些提交。将它们 cherry-pick 到新分支。例如，如果您想将分支master重置回原始提交，但保留当前分支中创建的两个提交，请执行以下操作：

$ git branch save-master  # create a new branch saving master
$ git reflog  # find the original place of master
$ git reset $COMMIT_ID
$ git cherry-pick save-master~ save-master
$ git branch -D save-master  # remove temporary branch

git revert：回退提交

git revert会反转一个或多个提交，也就是说，它会创建一个或多个新的提交来反转给定提交的影响。这是撤消已发布提交的唯一方法（git commit --amend、git rebase和git reset以非快进的方式更改分支，因此它们仅应用于未推送的提交）。

反转合并提交存在一个问题。git revert可以撤消合并提交创建的代码，但它无法撤消合并的事实。请参阅讨论如何反转有问题的合并。

无法撤销的一件事

无论您撤消什么，有一件事是无法撤消的——覆盖未提交的更改。未提交的更改不属于 Git，因此 Git 无法帮助保留它们。

大多数情况下，当您要执行覆盖未提交更改的命令时，Git 会警告您。Git 不允许您使用git checkout切换分支。当您要使用非干净的工作树进行变基时，它会阻止您。它拒绝在未提交的文件上拉取新的提交。

但是，有一些命令确实会执行此操作——覆盖工作树中的文件。像git checkout $PATHs或git reset --hard这样的命令会静默覆盖文件，包括您的未提交更改。

考虑到这一点，您可以理解“尽早提交，经常提交”的立场。尽可能频繁地提交。在编辑器或 IDE 中的每次保存时都提交。您可以在推送之前编辑您的提交——编辑提交消息、更改提交、重新排序、合并、拆分、删除。但请将您的更改保存到 Git 数据库中，要么提交更改，要么至少使用git stash将它们暂存起来。

行尾

Git具有内置机制来处理不同换行符样式平台之间的行尾。要允许git进行CRLF转换，请使用.gitattributes为文件分配text属性。对于必须具有特定行尾的文件，请分配eol属性。对于二进制文件，属性自然为binary。

例如：

$ cat .gitattributes
*.py text
*.txt text
*.png binary
/readme.txt eol=CRLF

要检查git对文件使用哪些属性，请使用git check-attr命令。例如

$ git check-attr -a -- \*.py

有用资源

GitAlias（repository）是一个大型的别名集合。仔细选择常用命令的别名可以节省大量按键操作！

GitIgnore和https://github.com/github/gitignore是各种IDE和编程语言的.gitignore文件的集合。Python也包括在内！

pre-commit（repositories）是一个用于管理和维护多语言提交前钩子的框架。该框架是用Python编写的，并为许多编程语言提供了许多插件。

暂存区

暂存区又名索引又名缓存是git的一个区别特征。暂存区是git在提交补丁之前收集补丁的地方。收集补丁和提交阶段的分离提供了git的一个非常有用的功能：您可以在提交之前审查收集的补丁，甚至编辑它们 - 删除一些块，添加新的块并再次审查。

要将文件添加到索引中，请使用git add。在提交之前收集补丁意味着您需要为每次更改执行此操作，而不仅仅是添加新（未跟踪）文件。为了简化提交，如果您只想提交所有内容而不进行审查，请运行git commit --all（或仅-a） - 该命令将所有更改的跟踪文件添加到索引中，然后提交。要提交文件，无论索引中收集的补丁如何，请运行git commit [--only|-o] -- $FILE...。

要将补丁块添加到索引中，请使用git add --patch（或仅-p）。要从索引中删除收集的文件，请使用git reset HEAD -- $FILE...要添加/检查/删除收集的块，请使用git add --interactive（-i）。

要查看索引和上次提交（即收集的补丁）之间的差异，请使用git diff --cached。要查看工作树和索引（即未收集的补丁）之间的差异，请仅使用git diff。要查看工作树和上次提交（即收集的和未收集的补丁）之间的差异，请运行git diff HEAD。

请参阅Git Wiki中的WhatIsTheIndex和IndexCommandQuickref。

根目录

Git在运行任何命令之前切换到根目录（存在.git子目录的项目的顶级目录）。但是，Git会记住切换前当前的目录。某些程序会考虑当前目录。例如，git status显示更改和未知文件的路径，相对于当前目录；git grep在当前目录下搜索；git apply仅应用补丁中触及当前目录下文件的那些块。

但是大多数命令都从根目录运行并忽略当前目录。例如，假设您有两个工作树，一个用于分支v1，另一个用于master。如果您想从第二个工作树内的子目录合并v1，则必须像在顶级目录中一样编写命令。例如，让我们采用两个工作树project-v1和project

$ cd project/subdirectory
$ git fetch ../project-v1 v1:v1
$ git merge v1

请注意git fetch ../project-v1 v1:v1中的路径是../project-v1而不是../../project-v1，尽管我们在子目录而不是根目录中运行命令。

ReReRe

Rerere是一种有助于解决重复合并冲突的机制。重复合并冲突最常见的原因是主题分支合并到主线，然后合并提交被移除；这通常用于测试主题分支并训练rerere；合并提交被移除以获得干净的线性历史记录，并仅使用一个最后的合并提交来完成主题分支。

Rerere通过记住成功提交之前和之后的树的状态来工作。这样，如果冲突出现在相同的文件中，rerere可以自动解决冲突。

Rerere可以使用git rerere命令手动使用，但最常自动使用。在工作树中使用以下命令启用rerere

$ git config rerere.enabled true
$ git config rerere.autoupdate true

您不需要全局启用rerere - 您不希望在裸存储库或单分支存储库中使用rerere；您只需要在经常执行合并并解决合并冲突的存储库中使用rerere。

请参阅《The Book》中的Rerere。

数据库维护

Git对象数据库和.git下的其他文件/目录需要定期维护和清理。例如，提交编辑会留下未引用的对象（在git术语中称为悬空对象），这些对象应进行修剪，以避免在DB中收集垃圾。命令git gc用于维护。Git会自动运行git gc --auto作为某些命令的一部分，以进行快速维护。建议用户不时运行git gc --aggressive；git help gc建议每隔几百个变更集运行一次；对于更密集的项目，应该每周运行一次，对于活动较少的项目，则频率更低（每两周或每月一次）。

git gc --aggressive不仅删除悬空对象，还将对象数据库重新打包成索引并优化包；它还打包符号引用（分支和标签）。另一种方法是运行git repack。

Linus Torvalds关于git gc --aggressive“愚蠢”的消息广为人知。现在可以安全地忽略该消息。它很旧且已过时，git gc --aggressive自那时起有了很大的改进。

对于那些仍然更喜欢git repack而不是git gc --aggressive的用户，建议的参数是git repack -a -d -f --depth=20 --window=250。请参阅此详细实验，了解这些参数效果的说明。

定期运行 git fsck [--strict] 以验证数据库的完整性。 git fsck 可能会生成一系列悬空对象列表；这并非错误，只是一个执行定期维护的提醒。

命令行选项和参数

git help cli 建议不要组合使用短选项/标志。大多数情况下组合使用是可行的：git commit -av 可以完美运行，但在某些情况下则不行。例如，git log -p -5 不能组合成 git log -p5。

有些选项带有参数，有些甚至有默认参数。在这种情况下，此类选项的参数必须以粘性方式拼写：-Oarg，而不是 -O arg，因为对于具有默认参数的选项，后者表示“对选项 -O 使用默认值，并将 arg 传递给选项解析器”。例如，git grep 具有一个选项 -O，它将找到的文件名列表传递给一个程序；-O 的默认程序是分页器（通常是 less），但您可以使用自己的编辑器。

$ git grep -Ovim  # but not -O vim

顺便说一句，如果 Git 被指示使用 less 作为分页器（即，如果 Git 中根本没有配置分页器，则默认使用 less，或者如果它从 GIT_PAGER 或 PAGER 环境变量中获取 less，或者如果它使用 git config [--global] core.pager less 配置，或者在命令 git grep -Oless 中使用 less），git grep 会将 +/$pattern 选项传递给 less，这非常方便。不幸的是，如果分页器不是完全 less，即使它带有参数的 less（例如 git config [--global] core.pager less -FRSXgimq），git grep 也不会传递模式；幸运的是，git grep -Oless 始终会传递模式。

bash/zsh 自动补全

即使对于那些乐于使用命令行的用户来说，手动输入 git rebase --interactive --preserve-merges HEAD~5 也有些困难，而这就是 Shell 自动补全发挥作用的地方。Bash/zsh 带有可编程的自动补全功能，通常会自动安装和启用，因此，如果您安装了 bash/zsh 和 Git，那么您很有可能已经完成了 - 只需在命令行中使用它即可。

如果您没有安装必要的组件，请安装并启用 bash_completion 包。如果您想将 Git 自动补全升级到最新版本，请从 git contrib 下载必要的文件。

Git-for-windows 附带了 git-bash，其中已安装并启用了 bash 自动补全功能。

bash/zsh 提示符

对于命令行爱好者来说，Shell 提示符可以承载大量有用的信息。要在提示符中包含 Git 信息，请使用 git-prompt.sh。阅读文件中的详细说明。

在网络上搜索“git prompt”以查找其他提示符变体。

SSH 连接共享

SSH 连接共享是 OpenSSH 和可能像 PuTTY 这样的衍生产品的特性。SSH 连接共享是一种通过建立一个连接并将其重用于连接到同一服务器的所有后续客户端来减少 ssh 客户端启动时间的方法。SSH 连接共享可用于加速许多短时的 ssh 会话，如 scp、sftp、rsync，当然还有通过 ssh 的 git。如果您定期从通过 ssh 访问的远程存储库中获取/拉取/推送，则建议使用 ssh 连接共享。

要开启 ssh 连接共享，请在您的 ~/.ssh/config 中添加类似以下内容

Host *
ControlMaster auto
ControlPath ~/.ssh/mux-%r@%h:%p
ControlPersist 600

请参阅 OpenSSH wikibook 和 搜索 以获取更多信息。

SSH 连接共享可用于 GitHub、GitLab 和 SourceForge 存储库，但请注意，BitBucket 不允许这样做，并且在短时间内活动后会强制关闭主连接，因此您会看到 ssh 的类似错误：“Connection to bitbucket.org closed by remote host.”