Git备忘录 on GitFAQ中文网

什么是 Git？

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

什么是 Git？

✍️ houkensjtu | 童仲毅

©️ 本文演绎自 Atlassian 编写的 What is Git。页面上所有内容采用知识共享-署名（CC BY 2.5 AU）许可协议。

到目前为止，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）保护。这可以避免代码和修改历史被不小心或者恶意改变，并且保证修改历史完全可追迹。

安装和使用GitFS完整示例

Tue, 11 Mar 2025 08:32:11 +0800

安装和使用GitFS完整示例

安装GitFS

Ubuntu安装方法

Ubuntu 18.04+

sudo add-apt-repository ppa:presslabs/gitfs
sudo apt-get update
sudo apt-get install gitfs

MacOS安装方法

先决条件

Homebrew

brew install gitfs

Debian安装方法

包含Raspbian系统

sudo echo "deb http://ppa.launchpad.net/presslabs/gitfs/ubuntu disco main" > /etc/apt/sources.list.d/gitfs.list
sudo echo "deb-src http://ppa.launchpad.net/presslabs/gitfs/ubuntu disco main" >> /etc/apt/sources.list.d/gitfs.list
sudo apt update
sudo apt install gitfs

挂载

在挂载之前，您需要一个有效的 git 存储库。您可以使用本地存储库或像 GitHub 这样的 git 服务。

为了将存储库挂载到所需的目录，请使用如下命令：

gitfs http://your.com/repository.git /mount/directory

完整的 github 示例

参考以下设置：

以 www-data 用户/组身份运行的 apache2
foo_user - github.com账号名
boo_password - github账号密码
https://github.com/foo_user/my_git_project.git - 远端库URL

挂载前先新建以下两个目录:

Git简易指南

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

Git简易指南

BY 童仲毅（geeeeeeeeek@github）

除非另行注明，页面上所有内容采用知识共享-署名（CC BY 2.5 AU）协议共享。git-guide 项目对本文亦有贡献。

这节是完全面向入门者的，我假设你从零开始创建一个项目并且想用 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 到你指定的目录。

GitFS参数说明

Tue, 11 Mar 2025 08:37:11 +0800

GitFS参数说明

使用选项

为了挂载 gitfs 时使用自定义选项，你需要在挂载命令后面添加相应参数，如下所示：

gitfs git@github.com:user/repo.git /mypath -o repo_path=/tmp/path,branch=dev,foreground=true,fetch_timeout=0.1,merge_timeout=0.1

所有可用选项

名称	默认	描述
`remote_url`		远端地址，支持http和ssh访问方式: `https://username:password@hostname.com/repo.git` `username@hostname.com:repo.git`
`branch`	`master`	分支名称
`repo_path`	`/var/lib/gitfs/repo_path`	克隆存储库的位置
`max_size`	`10MB`	单个文件允许的最大大小（以 MB 为单位）。如果设置为 0，则不限制。
`user`	`root`	挂载文件系统的用户
`group`	`root`	挂载文件系统的组
`commiter_name`	`user`	提交显示的名称
`commiter_email`	`user@FQDN`	提交显示的电子邮件
`merge_timeout`	`5 sec`	空闲和提交(推送)的间隔
`fetch_timeout`	`30 sec`	获取操作间隔
`min_idle_times`	`10`	idle循环直到 gitfs 进入空闲模式
`idle_fetch_timeout`	`30 min`	空闲和获取的间隔
`log`	`syslog`	日志文件的路径。特殊名称 ‘syslog’ 将记录到系统记录器中
`log_level`	`warning`	日志记录级别。’error’， ‘warning’， ‘info’， ‘debug’
`debug`	`false`	将日志级别设置为 ‘debug’ 并启用 FUSE 的调试的开关
`foreground`	`true`	指定 FUSE 是否在前台工作的开关
`allow_other`	`true`	该开关将覆盖限制对挂载文件系统的用户进行文件访问的安全措施。因此，所有用户（包括 root）都可以访问这些文件。默认情况下，此选项只允许 root 使用，但可以使用上一节中描述的配置选项删除此限制
`allow_root`	`false`	类似于 allow_other但 File Access 的开关仅限于挂载文件系统和 root 的用户。此选项和allow_other互斥
`username`		HTTP 基本身份验证的用户名
`password`		HTTP 基本身份验证的密码
`key`	`$HOME/.ssh/id_rsa`	SSH 私钥的路径。注意：公钥是通过将 .pub 附加到此路径来构建的，并且文件必须存在。

AI生成

Git创建代码仓库

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

Git创建代码仓库

BY 童仲毅(geeeeeeeeek@github)

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

这一章简要地带你了解一些最重要的 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

✍️ 童仲毅 | ⏳ 2018 年 10 月 26 日（部分章节未更新）

©️ 本文演绎自 Atlassian 编写的 Saving Changes。页面上所有内容采用知识共享-署名（CC BY 2.5 AU）许可协议。

“保存”这个概念在 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检查仓库状态

BY 童仲毅（geeeeeeeeek@github）

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

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检出之前的提交

BY 童仲毅（geeeeeeeeek@github）

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

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回滚错误的修改

BY 童仲毅（geeeeeeeeek@github）

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

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

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

BY 童仲毅（geeeeeeeeek@github）

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

原文以 Bitbucket 为例，考虑到git-recipes主要面向 GitHub 用户，因此例子替换成了 GitHub。Pull Request 在 GitLab 等平台上也有，用法和本教程基本一致。

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使用分支

BY 童仲毅（geeeeeeeeek@github）

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

这份教程是 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常见工作流比较

BY 童仲毅（geeeeeeeeek@github）

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

多种多样的工作流使得在项目中实施 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图解

BY 童仲毅（geeeeeeeeek@github）

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

此页图解 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

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 来协作的开发者应该都很清楚。

现在，如果 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

BY 童仲毅（geeeeeeeeek@github）

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

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高级用法

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 钩子：自定义你的工作流

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

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

BY 童仲毅（geeeeeeeeek@github）

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

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

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发布

Sun, 25 Oct 2026 19:34:12 +0800

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

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

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

问题修复

32 位 MinGit 中包含的可执行文件存在代码签名损坏的问题，现已修复。
将内置的brotli组件升级至 v1.2.1，以解决CVE-2026-111497。

下载Git for Windows

AI生成

下载Git

Thu, 03 Sep 2026 10:42:11 +0800

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-2.56.0-64-bit.exe (访问密码: 3705)
Git-2.56.0-arm64.exe (访问密码: 3705)

Git for Windows v2.55.0.windows.2

Git-2.55.0.2-64-bit.exe (访问密码: 3705)
Git-2.55.0.2-arm64.exe (访问密码: 3705)
Git-2.55.0.2-64-bit.7z (访问密码: 3705)
Git-2.55.0.2-arm64.7z (访问密码: 3705)

Git for Windows v2.54.0.windows.1

Git-2.54.0-64-bit.exe.7z (访问密码: 3705)
Git-2.54.0-arm64.exe.7z (访问密码: 3705)
PortableGit-2.54.0-64-bit.7z.exe.7z (访问密码: 3705)
PortableGit-2.54.0-arm64.7z.exe.7z (访问密码: 3705)

Git for Windows 2.53.0(3)

Git-2.53.0.3-64-bit.7z (访问密码: 3705)
Git-2.53.0.3-arm64.7z (访问密码: 3705)
PortableGit-2.53.0.3-64-bit.7z.7z (访问密码: 3705)
PortableGit-2.53.0.3-arm64.7z.7z (访问密码: 3705)

git 2.53.0.2

Git-2.53.0.2-64-bit.exe (访问密码: 3705)
Git-2.53.0.2-arm64.exe (访问密码: 3705)
PortableGit-2.53.0.2-64-bit.7z.exe (访问密码: 3705)
PortableGit-2.53.0.2-arm64.7z.exe (访问密码: 3705)

git 2.53.0

Git-2.53.0-64-bit.exe (访问密码: 3705)
Git-2.53.0-arm64.exe (访问密码: 3705)
PortableGit-2.53.0-arm64.7z.exe (访问密码: 3705)

git 2.52.0

Git-2.52.0-64-bit.exe (访问密码: 3705)
PortableGit-2.52.0-64-bit.7z.exe (访问密码: 3705)

git 2.51.2

Git-2.51.2-64-bit.exe (访问密码: 3705)

git 2.51.0

Git-2.51.0-64-bit.exe (访问密码: 3705)
Git-2.51.0-arm64.exe (访问密码: 3705)

git 2.50.1

Git-2.50.1-64-bit.exe (访问密码: 3705)
Git-2.50.1-32-bit.exe (访问密码: 3705)

git 2.49.0

Git-2.49.0-64-bit.exe (访问密码: 3705)

git 2.48.1

Git-2.48.1-64-bit.exe (访问密码: 3705)
Git-2.48.1-32-bit.exe (访问密码: 3705)

git 2.47.1

Git-2.47.1-64-bit.exe (访问密码: 3705)
Git-2.47.1-32-bit.exe (访问密码: 3705)

git 24.0.2

Git-2.47.0.2-32-bit.exe (访问密码: 3705)
Git-2.47.0.2-32-bit.exe (访问密码: 3705)

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

Git常见问题20250507

Wed, 07 May 2025 06:43:12 +0800

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重写项目历史

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

Git重写项目历史

BY 童仲毅（geeeeeeeeek@github）

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

概述

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保持同步

BY 童仲毅（geeeeeeeeek@github）

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

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 传递给这些「共享」命令的快捷方式。

GitHub发布Release详尽指南

Wed, 01 Jan 2025 15:00:12 +0800

在开发过程中，发布 Release 是一个重要的环节，能够有效地管理软件的版本和交付。本文将详细介绍如何在 GitHub 上发布 Release，包括操作步骤、注意事项及常见问题解答。

什么是GitHub Release

GitHub Release 是 GitHub 提供的一项功能，用于管理项目的发布版本。每一个 Release 都可以附带二进制文件、源代码压缩包以及变更日志，方便用户下载和使用。通过 Release，开发者能够清晰地展示项目的进展，并为用户提供稳定的版本。

为什么要在 GitHub 上发布 Release

版本管理：使用 Release 可以帮助开发者对项目进行有效的版本管理。
便于用户下载：用户可以轻松找到适合自己的版本进行下载。
信息透明：Release 说明可以让用户了解到版本更新的内容与改动。

如何在 GitHub 上发布 Release

第一步：准备工作

在发布 Release 之前，需要确保你的项目已经完成了相应的功能开发和测试。

确保代码稳定：确认你的代码已经经过充分测试，能够正常运行。
更新文档：确保项目的文档（如 README 文件）是最新的，并且描述了新版本的主要特性。

第二步：创建 Tag

登录到你的 GitHub 账号，进入需要发布 Release 的项目页面。
点击页面上方的 “Code” 选项卡。
在页面右侧，找到 “Releases” 链接，点击进入。
点击 “Draft a new release” 按钮。
在 “Tag version” 输入框中输入新的 Tag 名称（例如 v1.0.0）。
选择相应的基础分支（通常是 main 或 master）。

第三步：填写 Release 信息

在创建 Release 页面中，需要填写一些关键信息：

Git实用命令详解

Thu, 19 Sep 2024 09:34:12 +0800

将本地项目推送到远程仓库

git init（初始化）
git remote -v (查看已经关联的地址)
git add . （添加本地仓库）
git commit -m "第一次提交"（提交说明）
git remote add origin xxx（关联远程仓库）
git pull --rebase origin master（同步本地与远程仓库）
git push -u origin master（提交远程仓库）-f：强制推送至远程

Git回退到某个历史版本

找到要回退的版本号(右击项目–> Git –> Show History –>选中要回退的版本–>Copy Revision Number)

git reset --hard 139dcfaa558e3276b30b6b2e5cbbb9c00bbdca96 (后面为版本号)

把修改推到远程服务器

git push -f -u origin master 或者 git push -f 强制同步远程仓库。

修改项目关联远程地址方法

修改命令

git remote set-url origin <url>

手动修改

项目.git文件夹下，编辑config配置文件中url

Git 修改分支的名称

需要将分支br_rename_old修改为br_rename_new，执行如下步骤：

执行命令git checkout br_rename_old切换到br_rename_old分支，如果已经在这个分支下，可以不执行此步骤
执行命令git pull origin br_rename_old将代码更新到和远程仓库一致
执行命令git branch -m br_rename_old br_rename_new将本地仓库的br_rename_old的名称修改为br_rename_new
执行命令git push --set-upstream origin br_rename_new将本地分支push到远程仓库
执行命令git push origin --delete br_rename_old将远程分支br_rename_old删除

Git 删除分支

我现在在dev20181018分支上，想删除dev20181018分支

修改Git远程URL

Wed, 14 Aug 2024 09:34:12 +0800

查看当前远端地址

$ git remote -v
origin ssh://ov@git.zjq.xyz:29/ex.git (fetch)
origin ssh://ov@git.zjq.xyz:29/ex.git (push)

修改新的远端地址

git remote set-url origin ssh://vo@git.jidan.org:29/ex.git

验证修改结果

$ git remote -v
origin ssh://vo@git.jidan.org:29/ex.git (fetch)
origin ssh://vo@git.jidan.org:29/ex.git (push)

下来就可以Push最新修改

On branch master
Your branch is ahead of 'origin/master' by 1 commit.
 (use "git push" to publish your local commits)

nothing to commit, working tree clean
The authenticity of host '[git.jidan.org]:29 ([8.8.8.8]:29)' can't be established.
ED25519 key fingerprint is SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
This host key is known by the following other names/addresses:
 ~/.ssh/known_hosts:6: [git.zjq.xyz]:29
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[git.jidan.org]:29' (ED25519) to the list of known hosts.
Enumerating objects: 39, done.
Counting objects: 100% (39/39), done.
Delta compression using up to 4 threads
Compressing objects: 100% (23/23), done.
Writing objects: 100% (23/23), 10.86 MiB | 3.13 MiB/s, done.
Total 23 (delta 4), reused 0 (delta 0), pack-reused 0 (from 0)
To ssh://git.jidan.org:29/ex.git
 17ae34c..b8ae5da master -> master
Push Done!

AI生成

如何最简便的搭建Git服务?

Thu, 25 Jul 2024 17:18:12 +0800

假设你有个绑定域名为git.gitfaq.cn的服务器，并且可以通过SSH登录,计划将所有仓库(repository)放到/data/git目录中。

建立仓库(repository)

本地新建仓库(repository)

mkdir repo.git
git init

将仓库(repository)上传到服务器中。

scp -r repo.git user@git.gitfaq.cn:/data/git

成功后，即可通过user@git.gitfaq.cn:/data/git/repo.git来访问远端仓库。

访问仓库(repository)

建立好仓库后，拥有SSH权限的user就可以对user@git.gitfaq.cn:/data/git/repo.git拥有操作权限。

还可以通过git init --shared设置仓库目录的组权限为可写，此命令不会影响任何提交、引用等内容。

ssh user@git.gitfaq.cn
cd /data/git/repo.git
git init --bare --shared

如果需要多个用户都对仓库有读写权限，又不能给每个用户在服务器上建立账户，那么提供 SSH 连接就是唯一的选择。假设用来共享仓库的服务器已经安装了 SSH 服务，而且你通过它访问服务器。

以下几个方法可以使你给团队每个成员提供访问权:

给每个人创建账号，为每个人运行一次 adduser（或者 useradd）并且设置密码。
在主机上建立一个 git 公用账户，每个需要权限的人发一个 SSH 公钥，然后将其加入 git 账户的 ~/.ssh/authorized_keys 文件。这样一来，所有人都将通过 git账户访问主机。
让 SSH 服务器通过某个 LDAP 服务，或者其他已经设定好的集中授权机制，来进行授权。只要每个用户可以获得主机的 shell 访问权限，任何 SSH 授权机制你都可视为是有效的。

AI生成

初次使用 Git 的一些配置

Thu, 25 Jul 2024 16:46:12 +0800

安装完Git，你会想要做几件事来定制你的 Git 环境。每台计算机上只需要配置一次，程序升级时会保留配置信息。你可以在任何时候再次通过运行命令来修改它们。

git配置管理

Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量。这些变量存储在三个不同的位置：

/etc/gitconfig 文件: 包含系统上所有用户及他们仓库的通用配置。如果在执行 git config 时带上 --system 选项，那么它就会读写该文件中的配置变量。（需要管理员或超级用户权限）
~/.gitconfig 或 ~/.config/git/config 文件：只针对当前用户。你可以传递 --global 选项让 Git 读写此文件，这会对你系统上所有的仓库生效。
当前使用仓库的 Git 目录中的 config 文件（即 .git/config）：针对当前仓库。你可以传递 --local 选项让 Git 强制读写此文件，虽然默认情况下用的就是它。（需要进入某个 Git 仓库中才能让该选项生效。）

每一个级别会覆盖上一级别的配置，所以 .git/config 的配置变量会覆盖 /etc/gitconfig 中的配置变量。

在 Windows 系统中，Git 会查找 $HOME 目录下（一般情况下是 C:\Users$USER ）的 .gitconfig 文件。 Git 同样也会寻找 /etc/gitconfig 文件，但只限于 MSys 的根目录下，即安装 Git 时所选的目标位置。如果你在 Windows 上使用 Git 2.x 以后的版本，那么还有一个系统级的配置文件，Windows XP 上在 C:\Documents and Settings\All Users\Application Data\Git\config ，Windows Vista 及其以后的版本在 C:\ProgramData\Git\config 。此文件只能以管理员权限通过 git config -f <file> 来修改。

zsh中使用git的一些配置建议

Thu, 25 Jul 2024 11:40:12 +0800

Zsh 为 Git 提供了一个 Tab 补全库。想要使用它，只需在你的 .zshrc 中执行 autoload -Uz compinit && compinit 即可。相对于 Bash，Zsh 的接口更加强大：

$ git che<Tab>
check-attr -- 显示 gitattributes 信息
check-ref-format -- 检查引用名称是否符合规范
checkout -- 从工作区中检出分支或路径
checkout-index -- 从暂存区拷贝文件至工作目录
cherry -- 查找没有被合并至上游的提交
cherry-pick -- 从一些已存在的提交中应用更改

有歧义的 Tab 补全不仅会被列出，它们还会有帮助性的描述，你可以通过不断敲击 Tab 以图形方式浏览补全列表。该功能可用于 Git 命令、它们的参数和在仓库中内容的名称（例如 refs 和 remotes），还有文件名和其他所有 Zsh 知道如何去补全的项目。

Zsh 提供了一个从版本控制系统中获取信息的框架，叫做 vcs_info 。把如下代码添加至你的 ~/.zshrc 文件中，就可以在右侧显示分支名称：

autoload -Uz vcs_info
precmd_vcs_info() { vcs_info }
precmd_functions+=( precmd_vcs_info )
setopt prompt_subst
RPROMPT=\$vcs_info_msg_0_
# PROMPT=\$vcs_info_msg_0_'%# '
zstyle ':vcs_info:git:*' formats '%b'

当你的命令行位于一个 Git 仓库目录时，在任何时候，都可以在命令行窗口右侧显示当前分支。（当然也可以在左侧显示，只需把上面 PROMPT 的注释去掉即可。）它看起来像这样：

为什么windows下文本文件被检测为二进制文件？

Thu, 25 Jul 2024 10:23:12 +0800

当您将文本文件存储为 UTF-8 时，Git 效果最佳。Windows 上的许多程序都支持 UTF-8，但有些程序不支持，并且仅使用小端 UTF-16 格式，Git 将其检测为二进制文件。如果您无法在程序中使用 UTF-8，则可以指定一个工作树编码，指示应使用哪个编码签出您的文件，同时仍将这些文件作为 UTF-8 存储在存储库中。这允许像 git-diff这样的工具按预期工作，同时仍允许您的工具工作。

为此，您可以使用具有 working-tree-encoding 属性的 gitattributes 模式。例如，以下模式将所有 C 文件设置为使用 UTF-16LE-BOM，这是 Windows 上常见的编码

*.c	working-tree-encoding=UTF-16LE-BOM

您需要运行 git add --renormalize 以使其生效。请注意，如果您在跨平台使用的项目上进行这些更改，您可能希望在按用户配置的文件中或在 $GIT_DIR/info/attributes 中进行更改，因为在存储库中的 .gitattributes 文件中进行更改将适用于存储库的所有用户。

另请参阅以下条目以获取有关规范换行符的信息，并参阅 gitattributes以获取有关属性文件的更多信息。

via https://gitfaq.org/1/01/how-do-i-add-only-a-portion-of-a-file/

AI生成

为什么我有一个总是被修改的文件?

Thu, 25 Jul 2024 10:04:12 +0800

在内部，Git 始终将文件名存储为字节序列，并且不执行任何编码或大小写转换。但是，Windows 和 macOS 默认情况下都对文件名执行大小写转换。因此，最终可能会出现多个文件或目录，其名称仅在大小写上有所不同。Git 可以很好地处理这种情况，但文件系统只能存储其中一个文件，因此当 Git 读取另一个文件以查看其内容时，它看起来已被修改。

最好删除其中一个文件，以便您只有一个文件。您可以使用以下命令（假设在其他干净的工作树上存在两个文件 AFile.txt 和 afile.txt）执行此操作

$ git rm --cached AFile.txt
$ git commit -m 'Remove files conflicting in case'
$ git checkout .

这样可以避免接触磁盘，但会删除附加文件。你的项目可能更喜欢采用命名约定，例如全小写名称，以避免此问题再次发生；可以使用pre-receive钩子或作为持续集成 (CI) 系统的一部分来检查此类约定。

如果你的系统正在使用污点或清理过滤器，但之前已提交文件而未运行污点或清理过滤器，则任何平台上都可能出现永久修改的文件。要解决此问题，请在其他干净的工作树上运行以下内容

$ git add --renormalize .

via https://git.js.cn/docs/gitfaq

AI生成

Git 中存储文件的推荐方法是什么?

Thu, 25 Jul 2024 09:51:12 +0800

虽然 Git 可以存储和处理任何类型的任何文件，但有些设置比其他设置效果更好。一般来说，我们建议将文本文件存储在 UTF-8 中，不带字节顺序标记 (BOM)，并带有 LF（Unix 样式）结尾。我们还建议在提交消息中使用 UTF-8（同样，不带 BOM）。这些设置在各个平台上以及与git diff和git merge等工具配合使用时效果最佳。

此外，如果你可以在基于文本或非基于文本的存储格式之间进行选择，我们建议将文件存储在文本格式中，并在必要时将它们转换为其他格式。例如，每行一个记录的基于文本的 SQL 转储将比实际数据库文件更适合于差异和合并。类似地，基于文本的格式（如 Markdown 和 AsciiDoc）将比二进制格式（如 Microsoft Word 和 PDF）效果更好。

类似地，通常不建议在存储库中存储二进制依赖项（例如共享库或 JAR 文件）或构建产品。最好将依赖项和构建产品存储在工件或包服务器上，只将引用、URL 和哈希存储在存储库中。

我们还建议设置一个gitattributes文件来明确标记哪些文件是文本文件，哪些是二进制文件。如果你希望 Git 猜测，你可以设置属性text=auto。例如，以下内容可能适用于某些项目

# By default, guess.
*	text=auto
# Mark all C files as text.
*.c	text
# Mark all JPEG files as binary.
*.jpg	binary

这些设置帮助工具为输出（例如补丁）选择正确的格式，并导致文件以适合该平台的行尾签出。

via https://git.js.cn/docs/gitfaq

AI生成

Windows下如何安装Git?

Thu, 25 Jul 2024 09:34:12 +0800

Windows下安装Git需要在https://git-scm.com/download下载git for windows安装包

进入以上页面后，找到如下处，点击Download for Windows开始下载

随后进入开始下载页面，但是从github源地址下载，国内访问异常的话可以点击这里通过国内线路下载。

git scm历史版本

Git-2.47.0.2-32-bit.exe (访问密码: 3705)
Git-2.47.0.2-32-bit.exe (访问密码: 3705)

安装完成后，在任意目录右键，点击Open Git Bash here打开terminal，输入git version查看当前git版本

alair@e64 MINGW64 /d/dt2
$ git version
git version 2.45.2.windows.1

AI生成

Git中fetch和pull有什么不同之处？

Wed, 24 Jul 2024 17:20:12 +0800

git pull [remote] [branch] 等同于如下操作

## 从远程仓库获取最新修改
git fetch [remote] [branch] 
## 合并最新修改
git merge [remote][/branch]

git pull --rebase [remote] [branch]等同于如下操作

## 从远程仓库获取最新修改
git fetch [remote] [branch]
git rebase [remote][/branch]

via https://gitfaq.org/1/01/what-is-the-difference-between-fetch-and-pull/

AI生成

如何仅添加文件的部分内容？

Wed, 24 Jul 2024 16:50:12 +0800

git add --patch <file>

使用该命令会打开一个交互式界面，将每处不同的地区按照区块(hunk)的方式逐一显示，并提示你如何处理，从而达到仅添加部分内容的目的。

git add --patch package.json
diff --git a/package.json b/package.json
index 7a558a3..e03ce3f 100644
--- a/package.json
+++ b/package.json
@@ -2,7 +2,6 @@
 "name": "package",
 "version": "0.4.3",
 "description": "this is an example package",
- "keywords": ["key", "middleware", "connect"],
 "repository": "git://github.com/foo/bar.git",
 "author": "jxt <info@gitfaq.cn> (http://gitfaq.cn)",
 "repository": "git://github.com/foo/bar",
Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? y

Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? 提示如何处理当前区块(hunk)，输入?可查看帮助信息

y - stage this hunk 暂存此区块
n - do not stage this hunk 不暂存此区块
q - quit; do not stage this hunk or any of the remaining ones 退出；不暂存包括此块在内的剩余的区块
a - stage this hunk and all later hunks in the file 暂存此块与此文件后面所有的区块
d - do not stage this hunk or any of the later hunks in the file 不暂存此块与此文件后面所有的区块
g - select a hunk to go to 选择并跳转至一个区块
/ - search for a hunk matching the given regex 搜索与给定正则表达示匹配的区块
j - leave this hunk undecided, see next undecided hunk 暂不决定，转至下一个未决定的区块
J - leave this hunk undecided, see next hunk 暂不决定，转至下一个区块
k - leave this hunk undecided, see previous undecided hunk 暂不决定，转至上一个未决定的区块
K - leave this hunk undecided, see previous hunk 暂不决定，转至上一个区块
s - split the current hunk into smaller hunks 将当前的区块分割成多个较小的区块
e - manually edit the current hunk 手动编辑当前的区块
? - print help 输出帮助

via https://gitfaq.org/1/01/how-do-i-add-only-a-portion-of-a-file/

Git如何设置代理?

Wed, 24 Jul 2024 16:43:12 +0800

GIT配置代理如下设置，socks5为代理协议，可配置http/https/socks5等。

 git config --global http.proxy socks5://127.0.0.1:20170

AI生成

git writing objects 卡死怎么办?

Wed, 24 Jul 2024 16:30:12 +0800

git writing objects时常卡死，可以试着将远端地址改为ssh方式再重新push

git remote set-url origin git@gitlab.com:username/repo.git

AI生成

如何归档备份Git内容?

Wed, 24 Jul 2024 15:53:12 +0800

想将当前版本的内容归档并备份，可以使用git archive命令来实现

归档当前master，然后压缩成zip文件。

git archive --format=zip --output=repobak_$(date +%Y-%m-%d).zip master

AI生成

Git备忘录 on GitFAQ中文网

什么是 Git？

什么是 Git？

高性能

安全

安装和使用GitFS完整示例

安装和使用GitFS完整示例

安装GitFS

Ubuntu安装方法

MacOS安装方法

Debian安装方法

挂载

完整的 github 示例

Git简易指南

Git简易指南

安装 Git

检出仓库

GitFS参数说明

GitFS参数说明

使用选项

所有可用选项

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 init`用法

`git status`用法

`git checkout`用法

`git revert`用法

`git branch`用法

`git commit --amend`用法

`git remote`用法