Git使用指南

2026 年 6 月 7 日 · 2618 字

这是一篇基本的 Git 使用指南，帮助你快速查阅需要的指令。对于更加具体的教程，可以查看 git-recipes。

以下教程基于 GitHub 平台。

基础指令

配置与初始化

在管理代码之前，你需要在 Git 的全局配置中配置好自己的身份标识，这样在提交代码时，第三方代码托管平台可以自动识别修改者的账户，其他人也能知道是谁做出了修改。

# 设置全局用户名和邮箱
git config --global user.name "你的用户名"
git config --global user.name "你的邮箱"

# 查看当前的所有配置
git config --list

对于一个新项目，你可以选择在本地直接初始化，或者从 GitHub 上克隆一个现有的仓库。

# 情况 A：在本地新建的项目中初始化 Git 仓库
git init

# 情况 B：从 GitHub 克隆已有仓库到本地（最常用）
git clone 仓库的Git地址.git

日常修改与提交

Git 的核心工作流可以简单概括为：修改文件 → 暂存修改 → 提交保存。在操作过程中，你可以随时使用 git status 来查看当前工作区的状态。

# 查看当前工作区的状态
git status

# 将修改后的文件添加到暂存区
git add . # 暂存当前目录下所有修改及新文件

# 将暂存区的内容提交到本地仓库
git commit -m "commit 信息"

# 3. 如果发现刚提交的信息写错了，可以用这条指令修改最后一次的提交信息
git commit --amend -m "新的、正确的 commit 信息"

提交信息建议按照一定的规范书写，这样便于他人阅读和后期排查。常用格式为：<type>(<scope>): <subject>，其中：

type：必需，本次提交的类别（详见下面表格）。
scope：可选，本次修改的影响范围（比如某些模块）。
subject：必需，对变动的简短描述。

`type`	含义	使用场景
`feat`	新功能	引入了新功能、新接口或新页面。
`fix`	修复 Bug	修复了某个已知的问题。
`docs`	文档更新	修改了 README、API 文档、注释等。
`style`	样式/格式调整	不影响代码逻辑的改动（如空格、分号、格式化、Lint 修复等）。
`refactor`	代码重构	既不是新增功能，也不是修复 Bug 的代码变动。
`test`	测试相关	新增测试用例或修改现有的测试代码。
`chore`	杂务/构建工具	改变构建流程、增加依赖库、修改 CI/CD 配置等。

同步远程仓库

本地代码提交完成后，需要将其推送到 GitHub 远程仓库；同理，当团队其他成员更新了代码，你也需要将远程的最新改动拉取到本地。

在 Git 中，origin 是远程仓库（Remote Repository）的默认别名。当你把代码推送到云端平台或者从这些平台克隆（Clone）项目时，Git 需要知道远程服务器的地址。为了不需要每次都输入一长串类似 https://github.com/user/repo.git 的 URL，Git 会用一个简短的名字来代替它，这个名字默认就是 origin。

当你从 GitHub 克隆一个仓库到本地时，Git 会默认自动将你克隆的那个远程服务器地址命名为 origin。如果你是在本地新建的项目（git init），需要手动连接到 GitHub，你会执行 git remote add origin 指令。

# 本地 init 的仓库需要先关联远程 GitHub 仓库
git remote add origin 仓库的Git地址.git

# 将本地分支的改动推送到远程仓库，首次推送主分支需加 -u 参数
git push -u origin main

# 获取远程仓库的最新改动并合并到本地当前分支
git pull

# 查看远程有哪些更新，但不自动合并
git fetch origin

团队协作

PR 是 Pull Request 的简称，中文翻译为代码合并请求。当一个开发者修改了代码，想要把自己的改动合并到项目的其他分支（或者别人的开源项目中）时，需要发起一个 PR。

整个流程包括：提交 PR → 代码审阅（Code Review）→合并（Merge）。

提交 PR

提交 PR 分为两种情况：一种是你对该仓库拥有修改权限，另一种是没有权限。

对于拥有权限的仓库，可以本地直接创建一个新的分支，再该分支上面对代码进行修改，最后将该分支合并到目标分支上面。创建分支的时候，通常可以遵循一定的命名规范，一般建议使用“类型/功能描述” 结构，比如 feat/user-profile，fix/login-crash。

# 基于当前的分支生成一个名称为 feat/xxx 的新分支
git checkout -b feat/xxx

# 修改代码后提交到本地仓库，并推送到云端
git add .
git commit -m "feat: xxx"
git push origin feat/xxx

# 可选：完成合并后删除本地的分支
git branch -d feat/xxx
git push origin --delete feat/xxx

对于没有权限的仓库，你需要先 Fork 该仓库。Fork 字面意思是“分叉”，指的是复制别人的开源项目到你自己的账号下，成为一个独立的远程仓库，其主要解决一个问题：权限控制。对于一个开源项目，如果你不是项目的管理员，是没有权限将代码直接 Push 到这个仓库中的。但是如果你将这个仓库 Fork 一份到你自己的代码库中，这个复制出来的仓库完全属于你，你拥有所有读写权限。这样你便可以对代码进行任意修改，最后只需要从 Fork 后的仓库提交一个 PR 到原本的仓库即可。对于 GitHub 平台，可以点击仓库右上角的 Fork 按钮快速 Fork 到自己的代码库。

Fork 仓库之后，只需要将代码 Clone 到本地，就可以按照上述有权限的流程进行操作，最后提交到远程仓库。提交 PR 的过程也可以直接在 Github 平台完成。当你 Push 到远程仓库时，在你 Fork 的仓库页面会看到 “Compare & pull request” 按钮，点击它即可向原作者的仓库提交 PR。

# 克隆 Fork 的仓库到本地，并创建新分支
git clone 你的_Fork_仓库地址.git
git checkout -b feat/xxx

# 修改代码后提交到本地仓库，并推送到云端
git add .
git commit -m "feat: xxx"
git push origin feat/xxx

代码审阅

作为仓库的管理员，当有人提交 PR 的时候，你需要对代码进行审阅（Review）。在审阅的过程中，你可能会发现代码还有一些地方需要进行修改，这个时候，你就需要在对方 Fork 的仓库里进行修改。通常，GitHub 默认允许项目原作者直接向贡献者的 PR 分支提交代码。你可以按照下面的操作，在 PR 的基础上进行继续修改。

将对方的仓库添加为你的远程仓库
获取对方的分支数据
切换到对方的 PR 分支
修改文件并提交
推送到对方的仓库

# 添加远程仓库，contributor 为远程仓库的名称，可以随便命名
git remote add contributor 对方的_Fork_仓库地址.git

# 获取远程分支数据
git fetch contributor 

# 切换到对方的 PR 分支，本地分支名称为 pr-x
git checkout -b pr-x contributor/对方的分支名称

# 对代码进行修改后提交到本地仓库
git add .
git commit -m "chore: fix xxx"

# 推送到对方的仓库
git push contributor pr-x:对方的分支名称

这样你的代码就会直接 Push 到对方的 GitHub 仓库里，并且自动更新在当前的 PR 页面中。如果修改完之后需要还原本地的环境，可以按照下面的操作进行。

git checkout main             # 切换回主分支
git branch -D pr-x            # 删除临时的本地分支
git remote remove contributor # 删除远程仓库连接

合并

GitHub 在合并 PR 的时候，提供了三种合并方式，它们的核心区别在于提交历史的呈现方式。

Create a merge commit：会把源分支的所有 Commit 原封不动地搬过去，并在目标分支上自动生成一个新的“Merge commit”，把两个分支的历史连接起来
Squash and merge：把 PR 中的所有 Commit 压缩合并成一个单一的 Commit，然后追加到目标分支的末尾
Rebase and merge：把 PR 中的每一个 Commit，逐个复制并重新应用（Rebase）到目标分支的最新提交之后，不会产生新的 Merge commit

对于大部分的合并，推荐使用第二种 Squash and merge，这样可以保持主分支历史线性、干净，每一个 Commit 都代表一个完整的功能或修复