Git配方 on GitFAQ中文网

什么是 Git？

Sun, 24 Nov 2024 16:50:12 +0800

什么是 Git？

到目前为止，Git 是世界上使用最为广泛的现代化版本控制系统。Git 最初由 Linux 系统内核的作者 Linus Torvalds 在 2005 年开始开发，目前已经是一个持续维护的成熟开源项目。如今，大量软件项目依赖 Git 进行版本管理，其中既有开源软件，也有商业软件。Git 在很多操作系统和集成开发环境（IDE）上都表现良好。绝大多数软件开发者或多或少都使用过 Git。

Git 是分布式版本管理（DVCS）的一种。CVS 和 Subversion（SVN）等集中式的版本管理软件将完整的版本历史存放在同一个地方。而在 Git 中，每个开发者的代码仓库都包含了所有变更历史。

除了分布式之外，Git 在设计之初也考虑了性能、安全性和灵活性。

高性能

Git 的底层性能相较于其他版本管理软件有强大的优势。提交修改、创建分支、合并分支和比较版本都针对性能进行了优化。Git 中实现的算法利用了现实中代码树的特点以及它们被修改和访问的常见模式。

不同于某些版本管理软件，Git 在决定文件树的储存和版本历史时，不会被文件名的变化所愚弄——Git 关注的是文件的内容本身。毕竟，代码文件经常会被重命名、拆分和重新编排。Git 仓库中的文件对象通过差分编码（delta encoding，仅保存代码修改的差分）和压缩技术储存，并且直接保存文件夹中的内容和版本控制元数据。

分布式架构也给 Git 带来了巨大的性能优势。

比如说，有一名开发成员 Alice 修改了代码，添加了一些准备在 2.0 版本中发布的功能，然后提交了这些修改及其描述。随后，她又编写并提交了另一个新功能。很自然地，这两次修改是版本历史中两份独立的工作。Alice 又切换到了 1.3 版本的分支，修复了一个只影响这个旧版本的 bug。这次修复的目的是为了让团队在 2.0 版本还没有完成之前，发布一个 1.3.1 版本来解决旧版本中的一些 bug。Alice 可以立刻回到 2.0 版本分支，继续新功能开发。这一切都不需要网络连接，非常快速可靠，甚至可以在飞机中完成。当她准备好将这些单独提交的更改发送到远程仓库时，她只需要一个“推送”（push）命令。

安全

Git 设计时就把托管代码的完好性作为重中之重。文件内容以及文件、目录、版本、标签和提交的关联，都通过安全的加密哈希校验算法（SHA1）保护。这可以避免代码和修改历史被不小心或者恶意改变，并且保证修改历史完全可追迹。

Git简易指南

Sun, 24 Nov 2024 16:50:12 +0800

Git简易指南

这节是完全面向入门者的，我假设你从零开始创建一个项目并且想用 Git 来进行版本控制，因此本文会避开分支这些相对复杂的概念。

在这节中，我会介绍如何在你的个人项目中使用 Git，我们会讨论 Git 最基本的操作——如何初始化你的项目，如何管理新的或者已有的文件，如何在远端仓库中储存你的代码。

安装 Git

Mac 用户：Xcode Command Line Tools 自带 Git（xcode-select --install）
Linux 用户：sudo apt-get install git

Windows 用户：下载 Git SCM

- 对于 Windows 用户，安装后如果希望在全局的 cmd 中使用 Git，需要把 git.exe 加入 PATH 环境变量中，或在 Git Bash 中使用 Git。

检出仓库

执行如下命令以创建一个本地仓库的克隆版本：

git clone /path/to/repository

如果是远端服务器上的仓库，你的命令会是这个样子：

git clone username@host:/path/to/repository （通过 SSH）

或者：

git clone https:/path/to/repository.git （通过 https）

比如说 git clone https://github.com/geeeeeeeeek/git-recipes.git 可以将 git 教程 clone 到你指定的目录。

Git创建代码仓库

Sun, 24 Nov 2024 16:50:12 +0800

Git创建代码仓库

这一章简要地带你了解一些最重要的 Git 命令。在这节中，我会向你介绍开始一个新的版本控制项目需要的所有工具，后面的几节包含了你每天都会用到的Git操作。

在这节之后，你应该能够创建一个新的 Git 仓库，缓存你的项目以免丢失，以及查看你项目的历史。

git init

git init 命令创建一个新的 Git 仓库。它用来将已存在但还没有版本控制的项目转换成一个 Git 仓库，或者创建一个空的新仓库。大多数Git命令在未初始化的仓库中都是无法使用的，所以这就是你运行新项目的第一个命令了。

运行 git init 命令会在你项目的根目录下创建一个新的 .git 目录，其中包含了你项目必需的所有元数据。除了 .git 目录之外，已经存在的项目不会被改变（就像 SVN 一样，Git 不强制每个子目录中都有一个 .git 目录）。

`git init`用法

git init

将当前的目录转换成一个 Git 仓库。它在当前的目录下增加了一个 .git 目录，于是就可以开始记录项目版本了。

git init <directory>

在指定目录创建一个空的 Git 仓库。运行这个命令会创建一个名为 directory，只包含 .git 子目录的空目录。

git init --bare <directory>

初始化一个裸的 Git 仓库，但是忽略工作目录。共享的仓库应该总是用 --bare 标记创建（见下面的讨论）。一般来说，用 —bare 标记初始化的仓库以 .git 结尾。比如，一个叫my-project的仓库，它的空版本应该保存在 my-project.git 目录下。

讨论

和 SVN 相比，git init 命令是一个创建新的版本控制项目非常简单的途径。Git 不需要你创建仓库，导入文件，检查正在修改的拷贝。你只需要 cd 到你的项目目录下，运行 git init，你就有了一个功能强大的 Git 仓库。

Git保存更改

Sun, 24 Nov 2024 16:50:12 +0800

Git保存更改

git add / git commit / git diff / git stash / .gitignore

“保存”这个概念在 Git 等版本控制系统和 Word 等文本编辑应用中不太一样。传统软件里的“保存”在 Git 里被叫做“提交”（commit）。我们常说的的保存可以理解成在文件系统中覆盖一个已有的文件或者创建一个新的文件。而在 Git 中，提交这个操作作用于若干个文件和目录。

在 Git 和 SVN 里保存更改也不一样。SVN 提交或检入（check-in）将会推送到远端的中央服务器。也就是说 SVN 的提交需要联网才能完全“保存”项目更改。Git 提交可以在本地完成，然后再使用git push -u origin master命令推送到远端服务器。这两种方法的区别体现了两种架构设计的本质区别。Git 是一个分布式的应用，而 SVN 是一个中心化的应用。分布式应用一般来说更可靠，因为它们不存在中央服务器这样的单点故障。

git add、git status和git commit这三个命令通常一起使用，将 Git 项目当前的状态保存成一份快照。

Git 还有另一个保存机制：“储藏”（stash）。储藏是一个临时的储存区域，保存还没准备好提交的更改。储藏操作作用于工作目录，三个文件树中的第一棵。它有很多用法，访问 git stash 页面了解更多。

Git检查仓库状态

Tue, 11 Mar 2025 10:10:12 +0800

Git检查仓库状态

git status

git status 命令显示工作目录和缓存区的状态。你可以看到哪些更改被缓存了，哪些还没有，以及哪些还未被 Git 追踪。status 的输出不会告诉你任何已提交到项目历史的信息。如果你想看的话，应该使用 git log 命令。

`git status`用法

git status

列出已缓存、未缓存、未追踪的文件。

讨论

git status 是一个相对简单的命令。它告诉你 git add 和 git commit 的进展。status 信息还包括了添加缓存和移除缓存的相关指令。样例输出显示了三类主要的 git status 输出：

# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#modified: hello.py
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
#modified: main.py
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#hello.pyc

忽略文件

未追踪的文件通常有两类。它们要么是项目新增但还未提交的文件，要么是像 .pyc、.obj、.exe 等编译后的二进制文件。显然前者应该出现在 git status 的输出中，而后者会让我们困惑究竟发生了什么。

Git检出之前的提交

Sun, 24 Nov 2024 16:50:12 +0800

Git检出之前的提交

git checkout

git checkout 这个命令有三个不同的作用：检出文件、检出提交和检出分支。在这一章中，我们只关心前两种用法。

检出提交会使工作目录和这个提交完全匹配。你可以用它来查看项目之前的状态，而不改变当前的状态。检出文件使你能够查看某个特定文件的旧版本，而工作目录中剩下的文件不变。

`git checkout`用法

git checkout master

回到 master 分支。分支会在下一节中讲到，而现在，你只需要将它视为回到项目「当前」状态的一种方式。

git checkout <commit> <file>

查看文件之前的版本。它将工作目录中的 <file> 文件变成 <commit> 中那个文件的拷贝，并将它加入缓存区。

git checkout <commit>

更新工作目录中的所有文件，使得和某个特定提交中的文件一致。你可以将提交的哈希字串，或是标签作为 <commit> 参数。这会使你处在分离 HEAD 的状态。

讨论

版本控制系统背后的思想就是「安全」地储存项目的拷贝，这样你永远不用担心什么时候不可复原地破坏了你的代码库。当你建立了项目历史之后，git checkout 是一种便捷的方式，来将保存的快照「加载」到你的开发机器上去。

检出之前的提交是一个只读操作。在查看旧版本的时候绝不会损坏你的仓库。你项目「当前」的状态在 master 上不会变化。在开发的正常阶段，HEAD 一般指向 master 或是其他的本地分支，但当你检出之前提交的时候，HEAD 就不再指向一个分支了——它直接指向一个提交。这被称为「分离 HEAD」状态，可以用下图可视化：

在另一方面，检出旧文件不影响你仓库的当前状态。你可以在新的快照中像其他文件一样重新提交旧版本。所以，在效果上，git checkout 的这个用法可以用来将单个文件回滚到旧版本。

Git回滚错误的修改

Sun, 24 Nov 2024 16:50:12 +0800

Git回滚错误的修改

这章教程提供了和项目旧版本打交道所需要的所有技巧。首先，你会知道如何浏览旧的提交，然后了解回滚项目历史中的公有提交和回滚本地机器上的私有更改之间的区别。

git checkout

见上一章「2.5 检出之前的提交」。

git revert

git revert 命令用来撤销一个已经提交的快照。但是，它是通过搞清楚如何撤销这个提交引入的更改，然后在最后加上一个撤销了更改的新提交，而不是从项目历史中移除这个提交。这避免了Git丢失项目历史，这一点对于你的版本历史和协作的可靠性来说是很重要的。

`git revert`用法

git revert <commit>

生成一个撤消了 <commit> 引入的修改的新提交，然后应用到当前分支。

讨论

撤销（revert）应该用在你想要在项目历史中移除一整个提交的时候。比如说，你在追踪一个 bug，然后你发现它是由一个提交造成的，这时候撤销就很有用。与其说自己去修复它，然后提交一个新的快照，不如用 git revert，它帮你做了所有的事情。

撤销（revert）和重设（reset）对比

理解这一点很重要。git revert 回滚了「单独一个提交」，它没有移除后面的提交，然后回到项目之前的状态。在 Git 中，后者实际上被称为 reset，而不是 revert。

撤销和重设相比有两个重要的优点。首先，它不会改变项目历史，对那些已经发布到共享仓库的提交来说这是一个安全的操作。至于为什么改变共享的历史是危险的，请参阅 git reset 一节。

其次，git revert 可以针对历史中任何一个提交，而 git reset 只能从当前提交向前回溯。比如，你想用 git reset 重设一个旧的提交，你不得不移除那个提交后的所有提交，再移除那个提交，然后重新提交后面的所有提交。不用说，这并不是一个优雅的回滚方案。

Git创建Pull Request

Tue, 11 Mar 2025 08:50:12 +0800

Git创建Pull Request

Pull Request 是开发者使用 GitHub 进行协作的利器。这个功能为用户提供了友好的页面，让提议的更改在并入官方项目之前，可以得到充分的讨论。

最简单地来说，Pull Request 是一种机制，让开发者告诉项目成员一个功能已经完成。一旦 feature 分支开发完毕，开发者使用 GitHub 账号提交一个 Pull Request。它告诉所有参与者，他们需要审查代码，并将代码并入 master 分支。

但是，Pull Request 不只是一个通知，还是一个专注于某个提议功能的讨论版。如果更改导致了任何问题，团队成员可以在 Pull Request 下发布反馈，甚至推送后续提交来修改这个 Pull Request。所有的活动都在这个 Pull Request里之间追踪。

和其他协作模型相比，这种共享提交的解决方案形成了更加线性的工作流。SVN 和 Git 都能通过一个简单的脚本发送通知邮件；但是，如果要讨论更改，开发者不得不在邮件里回复。这会变得愈发杂乱无章，尤其是后续提交出现时。Pull Request 将所有这些功能放入了一个友好的网页，在每个 GitHub 仓库上方都能找到。

剖析一个 Pull Request

当你提交一个 Pull Request 的时候，你做的事情是 请求（request） 另一个开发者（比如项目维护者）来 拉取（pull） 你仓库中的一个分支到他们的仓库。也就是说你需要提供 4 个信息来完成一个 Pull Request：源仓库、源分支、目标仓库、目标分支。

Git使用分支

Tue, 11 Mar 2025 11:40:12 +0800

Git使用分支

这份教程是 Git 分支的综合介绍。首先，我们简单讲解如何创建分支，就像请求一份新的项目历史一样。然后，我们会看到 git checkout 是如何切换分支的。最后，学习一下 git merge 是如何整合独立分支的历史。

我们已经知道，Git 分支和 SVN 分支不同。SVN 分支只被用来记录偶尔大规模的开发效果，而 Git 分支是你日常工作流中不可缺失的一部分。

git branch

分支代表了一条独立的开发流水线。分支是我们在第二篇中讨论过的「编辑/缓存/提交」流程的抽象。你可以把它看作请求全新「工作目录、缓存区、项目历史」的一种方式。新的提交被存放在当前分支的历史中，导致了项目历史被 fork 了一份。

git branch 命令允许你创建、列出、重命名和删除分支。它不允许你切换分支或是将被 fork 的历史放回去。因此，git branch 和 git checkout、git merge 这两个命令通常紧密地结合在一起使用。

`git branch`用法

git branch

列出仓库中所有分支。

git branch <branch>

创建一个名为 <branch> 的分支。不会自动切换到那个分支去。

git branch -d <branch>

删除指定分支。这是一个安全的操作，Git 会阻止你删除包含未合并更改的分支。

git branch -D <branch>

强制删除指定分支，即使包含未合并更改。如果你希望永远删除某条开发线的所有提交，你应该用这个命令。

git branch -m <branch>

将当前分支命名为 <branch>。

讨论

在 Git 中，分支是你日常开发流程中的一部分。当你想要添加一个新的功能或是修复一个 bug 时——不管 bug 是大是小——你都应该新建一个分支来封装你的修改。这确保了不稳定的代码永远不会被提交到主代码库中，它同时给了你机会，在并入主分支前清理你 feature 分支的历史。

Git常见工作流比较

Tue, 11 Mar 2025 14:41:12 +0800

Git常见工作流比较

多种多样的工作流使得在项目中实施 Git 时变得难以选择。这份教程提供了一个出发点，调查企业团队最常见的 Git 工作流。

阅读的时候，请记住工作流应该是一种规范而不是金科玉律。我们希望向你展示所有工作流，让你融会贯通，因地制宜。

这份教程讨论了下面四种工作流：

中心化的工作流

过渡到分布式分版本控制系统看起来是个令人恐惧的任务，但你不必为了利用 Git 的优点而改变你现有的工作流。你的团队仍然可以用以前SVN的方式开发项目。

然而，使用 Git 来驱动你的开发工作流显示出了一些SVN没有的优点。首先，它让每个开发者都有了自己本地的完整项目副本。隔离的环境使得每个开发者的工作独立于项目的其它修改——他们可以在自己的本地仓库中添加提交，完全无视上游的开发，直到需要的时候。

第二，它让你接触到了 Git 鲁棒的分支和合并模型。和 SVN 不同，Git 分支被设计为一种故障安全的机制，用来在仓库之间整合代码和共享更改。

如何工作

和 Subversion 一样，中心化的工作流将中央仓库作为项目中所有修改的唯一入口。和 trunk 不同，默认的开发分支叫做master，所有更改都被提交到这个分支。这种工作流不需要 master 之外的其它分支。

开发者将中央仓库克隆到本地后开始工作。在他们的本地项目副本中，他们可以像SVN一样修改文件和提交更改；不过，这些新的提交被保存在本地 ——它们和中央仓库完全隔离。这使得开发者可以将和上游的同步推迟到他们方便的时候。

为了向官方项目发布修改，开发者将他们的本地 master 分支「推送」到中央仓库。这一步等同于 svn commit，除了Git添加的是所有不在中央 master 分支上的本地提交。

管理冲突

中央仓库代表官方项目，因此它的提交历史应该被视作神圣不可更改的。如果开发者的本地提交和中央仓库分叉了，Git 会拒绝将他们的修改推送上去，因为这会覆盖官方提交。

Git图解

Sun, 24 Nov 2024 16:50:12 +0800

Git图解

此页图解 git 中的最常用命令。如果你稍微理解 git 的工作原理，这篇文章能够让你理解的更透彻。

基本用法

上面的四条命令在工作目录、stage 缓存(也叫做索引)和 commit 历史之间复制文件。

git add files 把工作目录中的文件加入 stage 缓存
git commit 把 stage 缓存生成一次 commit，并加入 commit 历史
git reset -- files 撤销最后一次 git add files，你也可以用 git reset 撤销所有 stage 缓存文件
git checkout -- files 把文件从 stage 缓存复制到工作目录，用来丢弃本地修改

你可以用 git reset -p、git checkout -p 或 git add -p 进入交互模式，也可以跳过 stage 缓存直接从 commit历史取出文件或者直接提交代码。

Git代码合并选Merge还是Rebase

Sun, 24 Nov 2024 16:50:12 +0800

Git代码合并选Merge还是Rebase

git rebase 这个命令经常被人认为是一种 Git 巫术，初学者应该避而远之。但如果使用得当的话，它能给你的团队开发省去太多烦恼。在这篇文章中，我们会比较 git rebase 和类似的 git merge 命令，找到 Git 工作流中 rebase 的所有用法。

概述

你要知道的第一件事是，git rebase 和git merge 做的事其实是一样的。它们都被设计来将一个分支的更改并入另一个分支，只不过方式有些不同。

想象一下，你刚创建了一个专门的分支开发新功能，然后团队中另一个成员在 master 分支上添加了新的提交。这就会造成提交历史被 fork 一份，用 Git 来协作的开发者应该都很清楚。

现在，如果 master 中新的提交和你的工作是相关的。为了将新的提交并入你的分支，你有两个选择：merge 或 rebase。

Merge

将 master 分支合并到 feature 分支最简单的办法就是用下面这些命令：

git checkout feature
git merge master

或者，你也可以把它们压缩在一行里。

git merge master feature

feature 分支中新的合并提交（merge commit）将两个分支的历史连在了一起。你会得到下面这样的分支结构：

Git代码回滚选Reset、Checkout还是Revert

Sun, 24 Nov 2024 16:50:12 +0800

Git代码回滚选Reset、Checkout还是Revert

git reset、git checkout 和 git revert 是你的 Git 工具箱中最有用的一些命令。它们都用来撤销代码仓库中的某些更改，而前两个命令不仅可以作用于提交，还可以作用于特定文件。

因为它们非常相似，所以我们经常会搞混，不知道什么场景下该用哪个命令。在这篇文章中，我们会比较 git reset、git checkout 和 git revert 最常见的用法。希望你在看完后能游刃有余地使用这些命令来管理你的仓库。

Git 仓库有三个主要组成——工作目录，缓存区和提交历史。这张图有助于理解每个命令到底产生了哪些影响。当你阅读的时候，牢记这张图。

提交层面的操作

你传给 git reset 和 git checkout 的参数决定了它们的作用域。如果你没有包含文件路径，这些操作对所有提交生效。我们这一节要探讨的就是提交层面的操作。注意，git revert 没有文件层面的操作。

Reset

在提交层面上，reset 将一个分支的末端指向另一个提交。这可以用来移除当前分支的一些提交。比如，下面这两条命令让 hotfix 分支向后回退了两个提交。

git checkout hotfix
git reset HEAD~2

hotfix 分支末端的两个提交现在变成了悬挂提交。也就是说，下次 Git 执行垃圾回收的时候，这两个提交会被删除。换句话说，如果你想扔掉这两个提交，你可以这么做。reset 操作如下图所示：

如果你的更改还没有共享给别人，git reset 是撤销这些更改的简单方法。当你开发一个功能的时候发现「糟糕，我做了什么？我应该重新来过！」时，reset 就像是 go-to 命令一样。

除了在当前分支上操作，你还可以通过传入这些标记来修改你的缓存区或工作目录：

–soft – 缓存区和工作目录都不会被改变
–mixed – 默认选项。缓存区和你指定的提交同步，但工作目录不受影响
–hard – 缓存区和工作目录都同步到你指定的提交

把这些标记想成定义 git reset 操作的作用域就容易理解多了。

Git log高级用法

Sun, 24 Nov 2024 16:50:12 +0800

Git log高级用法

每一个版本控制系统的出现都是为了让你记录代码的变化。你可以看到项目的历史记录——谁贡献了什么、bug 是什么时候引入的，还可以撤回有问题的更改。但是，首先你得知道如何使用它。这也就是为什么会有 git log 这个命令。

到现在为止，你应该已经知道如何用 git log 命令来显示最基本的提交信息。但除此之外，你还可以传入各种不同的参数来获得不一样的输出。

git log 有两个高级用法：一是自定义提交的输出格式，二是过滤输出哪些提交。这两个用法合二为一，你就可以找到你项目中你需要的任何信息。

格式化 Log 输出

首先，这篇文章会展示几种 git log 格式化输出的例子。大多数例子只是通过标记向 git log 请求或多或少的信息。

如果你不喜欢默认的 git log 格式，你可以用 git config 的别名功能来给你想要的格式创建一个快捷方式。

Oneline

--oneline 标记把每一个提交压缩到了一行中。它默认只显示提交ID和提交信息的第一行。git log --oneline 的输出一般是这样的：

0e25143 Merge branch 'feature'
ad8621a Fix a bug in the feature
16b36c6 Add a new feature
23ad9ad Add the initial code base

它对于获得项目的总体情况很有帮助。

Decorate

很多时候，知道每个提交关联的分支或者标签很有用。--decorate 标记让 git log 显示指向这个提交的所有引用（比如说分支、标签等）。

Git 钩子：自定义你的工作流

Sun, 24 Nov 2024 16:50:12 +0800

Git 钩子：自定义你的工作流

Git 钩子是在 Git 仓库中特定事件发生时自动运行的脚本。它可以让你自定义 Git 内部的行为，在开发周期中的关键点触发自定义的行为。

Git 钩子最常见的使用场景包括推行提交规范，根据仓库状态改变项目环境，和接入持续集成工作流。但是，因为脚本可以完全定制，你可以用 Git 钩子来自动化或者优化你开发工作流中任意部分。

在这篇文章中，我们会先简要介绍 Git 钩子是如何工作的。然后，我们会审视一些本地和远端仓库使用最流行的钩子。

Git钩子概述

Git 钩子是仓库中特定事件发生时 Git 自动运行的普通脚本。因此，Git 钩子安装和配置也非常容易。

钩子在本地或服务端仓库都可以部署，且只会在仓库中事件发生时被执行。在文章后面我们会具体地研究各种钩子。接下来所讲的配置对本地和服务端钩子都起作用。

安装钩子

钩子存在于每个 Git 仓库的 .git/hooks 目录中。当你初始化仓库时，Git 自动生成这个目录和一些示例脚本。当你观察 .git/hooks 时，你会看到下面这些文件：

applypatch-msg.sample pre-push.sample
commit-msg.sample pre-rebase.sample
post-update.sample prepare-commit-msg.sample
pre-applypatch.sample update.sample
pre-commit.sample

这里已经包含了大部分可用的钩子了，但是 .sample 拓展名防止它们默认被执行。为了安装一个钩子，你只需要去掉 .sample 拓展名。或者你要写一个新的脚本，你只需添加一个文件名和上述匹配的新文件，去掉 .sample 拓展名。

比如说，试试安装一个 prepare-commit-msg 钩子。去掉脚本的 .sample 拓展名，在文件中加上下面这两行：

#!/bin/sh

echo "# Please include a useful commit message!" > $1

钩子需要能被执行，所以如果你创建了一个新的脚本文件，你需要修改它的文件权限。比如说，为了确保 prepare-commit-msg 可执行，运行下面这个命令：

Git提交引用和引用日志

Sun, 24 Nov 2024 16:50:12 +0800

Git提交引用和引用日志

提交是 Git 的精髓所在，你无时不刻不在创建和缓存提交、查看以前的提交，或者用各种Git命令在仓库间转移你的提交。大多数的命令都对同一个提交操作，而有些会接受提交的引用作为参数。比如，你可以给 git checkout 传入一个引用来查看以前的提交，或者传入一个分支名来切换到对应的分支。

知道提交的各种引用方式之后，Git 的命令就会变得更加强大。在这章中，我们研究提交的各种引用方式，来一窥 git checkout、git branch、git push 等命令的工作原理。

我们还会学到如何使用 Git 的引用日志查看似乎已被删除的提交。

哈希字串

引用一个提交最直接的方式是通过 SHA-1 的哈希字串，这是每个提交唯一的 ID。你可以在 git log 的输出中找到提交的哈希字串。

commit 0c708fdec272bc4446c6cabea4f0022c2b616eba
Author: Mary Johnson <mary@example.com>
Date: Wed Jul 9 16:37:42 2014 -0500

 一些提交信息

在 Git 命令中传递时，你只需要提供足以确定那个提交的哈希子串即可。比如，你可以这样用 git show 的命令显示上面的提交：

git show 0c708f

有时，我们需要把分支、标签或者其他间接的引用转变成对应提交的哈希。git rev-parse 命令正是你需要的。下面这个命令返回 master 分支提交的哈希字串：

git rev-parse master

当你写的自定义脚本中需要将提交引用作为参数时，这个命令非常有用。你可以让 git rev-parse 帮你处理转换，而不用手动做这件事。

引用

ref 是提交的间接引用。你可以把它当做哈希字串的别名，但对用户更友好。这就是 Git 内部表示分支和标签的机制。

Git重写项目历史

Tue, 11 Mar 2025 10:31:12 +0800

Git重写项目历史

概述

Git 的主要职责是保证你不会丢失提交的修改。但是，它同样被设计成让你完全掌控开发工作流。这包括了让你自定义你的项目历史，而这也创造了丢失提交的可能性。Git 提供了可以重写项目历史的命令，但也警告你这些命令可能会让你丢失内容。

这份教程讨论了重写提交快照的一些常见原因，并告诉你如何避免不好的影响。

git commit –amend

git commit --amend 命令是修复最新提交的便捷方式。它允许你将缓存的修改和之前的提交合并到一起，而不是提交一个全新的快照。它还可以用来简单地编辑上一次提交的信息而不改变快照。

但是，amend 不只是修改了最新的提交——它进行了一次替换。对于 Git 来说，这看上去像一个全新的提交，即上图中用星号表示的那一个。在公共仓库工作时一定要牢记这一点。

`git commit --amend`用法

git commit --amend

合并缓存的修改和上一次的提交，用新的快照替换上一个提交。缓存区没有文件时运行这个命令可以用来编辑上次提交的提交信息，而不会更改快照。

讨论

仓促的提交在你日常开发过程中时常会发生。很容易就忘记了缓存一个文件或者弄错了提交信息的格式。--amend 标记是修复这些小意外的便捷方式。

不要修复公共提交

在git reset这节中，我们说过永远不要重设和其他开发者共享的提交。对于修复也是一样：永远不要修复一个已经推送到公共仓库中的提交。

修复过的提交事实上是全新的提交，之前的提交会被移除出项目历史。这和重设公共快照的后果是一样的。如果你修复了其他开发者在之后继续开发的一个提交，看上去他们的工作基础从项目历史中消失了一样。对于在这上面的开发者来说这是很困惑的，而且很难恢复。

例子

下面这个🌰展示了 Git 开发工作流中的一个常见情形。我们编辑了一些希望在同一个快照中提交的文件，但我们忘记添加了其中的一个。修复错误只需要缓存那个文件并且用 --amend 标记提交：

# 编辑 hello.py 和 main.py
git add hello.py
git commit

# 意识到你忘记添加 main.py 的更改
git add main.py
git commit --amend --no-edit

编辑器会弹出上一次提交的信息，加入 --no-edit 标记会修复提交但不修改提交信息。需要的话你可以修改，不然的话就像往常一样保存并关闭文件。完整的提交会替换之前不完整的提交，看上去就像我们在同一个快照中提交了 hello.py 和 main.py。

Git保持同步

Tue, 11 Mar 2025 09:50:12 +0800

Git保持同步

SVN 使用唯一的中央仓库作为开发者之间沟通的桥梁，在开发者的工作拷贝和中央仓库之间传递变更集合（changeset），协作得以发生。这和Git的协作模型有所不同，Git 给予每个开发者一份自己的仓库拷贝，拥有自己完整的本地历史和分支结构。用户通常共享一系列的提交而不是单个变更集合。Git 允许你在仓库间共享整个分支，而不是从工作副本提交一个差异集合到中央仓库。

下面的命令让你管理仓库之间的连接，将分支「推送」到其他仓库来发布本地历史，或是将分支「拉取」到本地仓库来查看其它开发者的贡献。

git remote

git remote 命令允许你创建、查看和删除和其它仓库之间的连接。远程连接更像是书签，而不是直接跳转到其他仓库的链接。它用方便记住的别名引用不那么方便记住的 URL，而不是提供其他仓库的实时连接。

例如，下图显示了你的仓库和中央仓库以及另一个开发者仓库之间的远程连接。你可以向 Git 命令传递 origin 和 john 的别名来引用这些仓库，替代完整的 URL。

`git remote`用法

git remote

列出你和其他仓库之间的远程连接。

git remote -v

和上个命令相同，但同时显示每个连接的 URL。

git remote add <name> <url>

创建一个新的远程仓库连接。在添加之后，你可以将 <name> 作为 <url> 便捷的别名在其他 Git 命令中使用。

git remote rm <name>

移除名为的远程仓库的连接。

git remote rename <old-name> <new-name>

将远程连接从 <old-name> 重命名为 <new-name>。

讨论

Git 被设计为给每个开发者提供完全隔离的开发环境。也就是说信息并不是自动地在仓库之间传递。开发者需要手动将上游提交拉取到本地，或手动将本地提交推送到中央仓库中去。git remote 命令正是将 URL 传递给这些「共享」命令的快捷方式。

Git配方 on GitFAQ中文网

什么是 Git？

什么是 Git？

高性能

安全

Git简易指南

Git简易指南

安装 Git

检出仓库

Git创建代码仓库

Git创建代码仓库

git init

git init用法

讨论

Git保存更改

Git保存更改

Git检查仓库状态

Git检查仓库状态

git status

git status用法

讨论

忽略文件

Git检出之前的提交

Git检出之前的提交

git checkout

git checkout用法

讨论

Git回滚错误的修改

Git回滚错误的修改

git checkout

git revert

git revert用法

讨论

撤销（revert）和重设（reset）对比

Git创建Pull Request

Git创建Pull Request

剖析一个 Pull Request

Git使用分支

Git使用分支

git branch

git branch用法

讨论

Git常见工作流比较

Git常见工作流比较

中心化的工作流

如何工作

管理冲突

Git图解

Git图解

基本用法

Git代码合并选Merge还是Rebase

Git代码合并选Merge还是Rebase

概述

Merge

Git代码回滚选Reset、Checkout还是Revert

Git代码回滚选Reset、Checkout还是Revert

提交层面的操作

Reset

Git log高级用法

Git log高级用法

格式化 Log 输出

Oneline

Decorate

Git 钩子：自定义你的工作流

Git 钩子：自定义你的工作流

Git钩子概述

安装钩子

Git提交引用和引用日志

Git提交引用和引用日志

哈希字串

引用

Git重写项目历史

Git重写项目历史

概述

git commit –amend

git commit --amend用法

讨论

不要修复公共提交

例子

Git保持同步

`git init`用法

`git status`用法

`git checkout`用法

`git revert`用法

`git branch`用法

`git commit --amend`用法

`git remote`用法