Git图解

十一月 24, 2024
Git

Git图解

BY 童仲毅（geeeeeeeeek@github）

这是一篇在原文基础上演绎的文章。原作者 Mark Lodato，译者 wych。原文采用创用 CC 姓名标示-非商业性-相同方式分享 3.0 美国授权条款授权。

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

基本用法

enter image description here

上面的四条命令在工作目录、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

十一月 24, 2024
Git

Git代码合并选Merge还是Rebase

BY 童仲毅（geeeeeeeeek@github）

这是一篇在原文（BY atlassian）基础上演绎的译文。除非另行注明，页面上所有内容采用知识共享-署名（CC BY 2.5 AU）协议共享。

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

概述

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

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

enter image description here

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

Merge

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

git checkout feature
git merge master

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

git merge master feature

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

enter image description here

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

十一月 24, 2024
Git

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

BY 童仲毅（geeeeeeeeek@github）

这是一篇在原文（BY atlassian）基础上演绎的译文。除非另行注明，页面上所有内容采用知识共享-署名（CC BY 2.5 AU）协议共享。

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

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

Git repo的主要组成

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

提交层面的操作

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

Reset

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

git checkout hotfix
git reset HEAD~2

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

把hotfix分支reset到HEAD~2

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

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

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

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

Git log高级用法

十一月 24, 2024
Git

Git log高级用法

BY 童仲毅（geeeeeeeeek@github）

这是一篇在原文（BY atlassian）基础上演绎的译文。除非另行注明，页面上所有内容采用知识共享-署名（CC BY 2.5 AU）协议共享。

每一个版本控制系统的出现都是为了让你记录代码的变化。你可以看到项目的历史记录——谁贡献了什么、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 钩子：自定义你的工作流

十一月 24, 2024
Git

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

BY 童仲毅（geeeeeeeeek@github）

这是一篇在原文（BY atlassian）基础上演绎的译文。除非另行注明，页面上所有内容采用知识共享-署名（CC BY 2.5 AU）协议共享。

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

git hook

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提交引用和引用日志

十一月 24, 2024
Git

Git提交引用和引用日志

BY 童仲毅（geeeeeeeeek@github）

这是一篇在原文（BY atlassian）基础上演绎的译文。除非另行注明，页面上所有内容采用知识共享-署名（CC BY 2.5 AU）协议共享。

提交是 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 for Windows v2.56.0.windows.4发布

十月 25, 2026
Git, Gitscm, Windows, CVE-2026-111497, Brotli

Git for Windows v2.56.0.windows.4发布

Git for Windows v2.56.0.windows.4

自 Git for Windows v2.56.0(3)（2026年10月22日）以来的变更

这是又一个紧急安全漏洞修复版本，针对的是CVE-2026-111497。

问题修复

下载Git for Windows

AI生成

下载Git

九月 3, 2026
Git, Gitforwindows, 2.56.0

Git for Windows下载

Git for Windows v2.56.0.windows.4

Git for Windows v2.56.0.windows.3

Git for Windows v2.56.0.windows

Git for Windows v2.55.0.windows.2

Git for Windows v2.54.0.windows.1

Git for Windows 2.53.0(3)

git 2.53.0.2

git 2.53.0

git 2.52.0

git 2.51.2

git 2.51.0

git 2.50.1

git 2.49.0

git 2.48.1

git 2.47.1

git 24.0.2

https://github.com/git-for-windows/git

Git常见问题20250507

五月 7, 2025
Git, Gitfaq

git配置

我应该在 user.name 中放什么？

您应该填写您的个​​人姓名，通常是使用名字和姓氏的形式。例如， Git 的当前维护者使用 “Junio C Hamano” 。这将是您所做的每个提交中存储的姓名部分。

此配置对远程服务的身份验证没有任何影响；有关详细信息，请参阅 git-config[1] 中的 credential.username 。

http.postBuffer 到底起什么作用？

此选项可更改 Git 通过 HTTP 或 HTTPS 将数据推送到远程时使用的缓冲区大小。如果数据大于此大小，处理 Git 的 HTTP 支持的 libcurl 将使用分块传输编码，因为事先不知道推送的数据的大小。

将此值保留为默认大小是可以的，除非您知道远程服务器或中间的代理不支持 HTTP/1.1（引入了分块传输编码）或已知分块数据会中断。这通常（错误地）被建议作为一般推送问题的解决方案，但由于几乎每个服务器和代理都至少支持 HTTP/1.1，因此提高此值通常无法解决大多数推送问题。无法正确支持 HTTP/1.1 和分块传输编码的服务器或代理在当今的互联网上不会那么有用，因为它会中断大量流量。

请注意，增加此值将增加 Git 通过 HTTP 或 HTTPS 执行的每个相关推送所使用的内存，因为无论是否全部使用，都会分配整个缓冲区。因此，最好将其保留为默认值，除非您确定需要不同的值。

git如何配置不同的编辑器？

如果您没有为 Git 专门指定编辑器，它将默认使用您通过 VISUAL 或 EDITOR 环境变量配置的编辑器，如果两者都未指定，则使用系统默认编辑器（通常为 vi ）。由于有些人发现 vi 难以使用或更喜欢其他编辑器，因此可能需要更改使用的编辑器。

如果要为大多数需要编辑器的程序配置通用编辑器，可以编辑 shell 配置（例如 ~/.bashrc 或 ~/.zshenv ），使其包含一行，将 EDITOR 或 VISUAL 环境变量设置为适当的值。例如，如果您更喜欢编辑器 nano ，则可以编写以下内容：

Git备忘录

三月 11, 2025
Git, Gitfaq, 版本控制, Git常见问题

Git 是一个免费的开源分布式版本控制系统，旨在快速高效地处理从小型到超大型项目的所有项目。

Git 易于学习，占用空间小，性能快如闪电。它超越了 Subversion、CVS、Perforce 和 ClearCase 等 SCM 工具，具有廉价的本地分支、方便的暂存区域和多个工作流程等功能。

– 来自git-scm的官方介绍

git是一个分布式版本控制软件，最初由林纳斯·托瓦兹创作，于2005年以GPL许可协议发布。最初目的是为了更好地管理Linux内核开发而设计。应注意的是，这与GNU Interactive Tools（一个类似Norton Commander界面的文件管理器）不同。

git最初的开发动力来自于BitKeeper和Monotone。git最初只是作为一个可以被其他前端（比如Cogito或Stgit）包装的后端而开发的，但后来git内核已经成熟到可以独立地用作版本控制。很多被广泛使用的软件项目都使用 git 进行版本控制，其中包括 Linux 内核、X.Org服务器和OLPC内核等项目的开发流程。

下载Git for Windows

Git备忘录

git创建仓库

在本地初始化仓库，然后将本地仓库与一个 GitHub 上的空仓库连接起来。

$ mkdir lrepo
$ cd lrepo
$ git init
$ git remote add origin [url]

git clone一个已存在于 GitHub 上的仓库，包括所有的文件、分支和提交(commits)

$ git clone [url]

git全局配置

## 配置用户名
$ git config --global user.name "[name]"

## 配置邮箱
$ git config --global user.email "[email address]"

### 配置彩色输出
$ git config --global color.ui auto

git分支

分支是使用 Git 工作的一个重要部分。你做的任何提交都会发生在当前“checked out”到的分支上。使用 git status 查看那是哪个分支。

1234
GitFAQ中文网 - black8