Git 精简手册

改不了ID啦？

1193人浏览 · 2026-01-05 23:00:43

改不了ID啦？ · 2026-01-05 23:00:43 发布

本文致力于列举常用场景的git操作，而非系统性的教学。
斯以为，git 的常用功能，在于多多练习，即可快速理解掌握，至于更深层次的理解与使用，根据个人需要可以在后期补充加强。

文章目录

Q&A

这部分记录使用git遇到的问题。

.git文件是什么？

命令行切换到某个目录下，执行git init 命令后，该目录会自动生成.gt文件夹，表示该目录可以通过 git 进行管理。
.gitignore文件怎么使用？

使用git add .会将当前目录所有文件都添加到暂存区，而我们有时不想全部添加进去。
使用touch .gitignore命令生成此文件，通过编辑器打开，输入想让git忽略的目录和文件（不想让git管理的文件夹）即可，每一行表示一个文件或目录。
因为git一般用于管理文本文件、源码等，这些可以通过git查看内容变化情况。
待更新。。。。。。。

一、Git 初步使用

1. Git 核心认知

（1）什么是 Git

Git 是一款分布式版本控制系统（DVCS），用于跟踪文件（尤其是代码文件）的修改历史、协作开发、回溯版本、管理分支，解决了多人协作开发中的代码冲突、版本丢失、迭代混乱等问题。

如果我们写一个md文件或者代码，会有版本v1, v2, v3…，简单粗暴的解决方法是：拷贝一份 => 命名后面添加_v1，_v2，_完整版等等具有区分性的命名标识，但这会导致目录中的文件越来越多，并且空间占用变大。

如果使用 git 后，就不需要拷贝文件、重命名，既可以使得目录简洁清爽，又可以减少不必要拷贝带来的空间占用。此外，回退到不同版本只需要使用一个命令即可，从而方便我们的文件管理。

（2）Git 适用于什么文件？

Git 是为「文本文件的版本追踪与协作」设计的分布式版本控制系统。所以我们首选文本文件进行管理。

这种文件可以被git解析到具体的某行的变化对比，典型文件如：

**源代码类：**各类编程语言的源代码文件.py, .cpp, .js 等
**脚本类：**构建及脚本文件Makefile, .sh
配置类： Git自身的配置文件.gitignore、配置文件json，xml
**文档类：**markdown文件.md、记事本文件.txt、等

git 对二进制文件、大文件、自动生成文件等支持不佳，不推荐直接管理。这类文件使用 git 管理起来和拷贝重命名基本没两样，因此不推荐。

二进制文件内容无法被git解析，只能记录创建、替换、删除，而内容更改则无法回溯（比如word文档修改，图片的P图前后，这些是无法分析出更改情况对比的）；大文件不建议使用git管理，一方面是耗时维护困难，另一方面多人协同需要 pull/push，大文件传输过程难免出现意外。对于自动生成文件，这类文件一般是构建编译过程自动生成的，不需要我们去编辑，每次改动生成的临时产物也会有不同，我们既不用关注这些文件，更不需要去管理它们了；敏感信息文件，涉及到个人隐私可以本地管理，但务必不要推送到远程；临时/缓存文件基本没有价值，频繁生成和修改会污染Git提交历史，因此也没必要管理。

以上常见，不适合管理的文件有，仅列举部分：

二进制文件类：
- 图片/音视频媒体文件.jpg, .git, .mp4, .psd 等等不在列举，
- 办公文档 .docx, .pptx, .xlsx等office三件套文件。
- 编译产物 .exe, .dll, .class, .jar等等
- 安装包.apk, .dmg ,.zip等等
大文件： 比如3D模型，好几个G的数据集等
自动生成产物：
- 依赖文件夹，体积大文件数量多，并且可能每次文件夹内容会不一样，这种不需要人工处理的文件不必纳入管理。
- 还有一些构建产物，比如C++生成的.obj
**敏感文件：**密钥 / 证书：id_rsa（SSH 密钥）、.p12、.cer（SSL 证书）等等。
临时文件：
- 日志文件.log，日志文件是运行时生成的，没有长期保留价值，并且是软件本身自动频繁生成及修改的。我们使用日志仅用于排查，而非日志内容及版本的管理。
- 缓存目录：.idea, .vscode等。

总结，通常我们优先关注项目的源代码文件、md文件、需要手动编辑的配置文件等，其余文件及文件夹的路径写在.gitignore文件中忽略即可。

下面分「适用文件」和「不推荐 / 不适合文件」详细说明：典型的是代码文件，此外

2. 前置准备

安装git及添加到环境变量。
git用户的身份配置，这是类似于QQ登陆时填写QQ号的步骤。

（1）Git 安装

Windows 系统：下载 Git for Windows，默认下一步安装即可（可自定义安装路径，建议保留 Git Bash 终端）。
Mac 系统：两种方式
1. 安装 Xcode 命令行工具：xcode-select --install
2. 通过 Homebrew 安装：brew install git
Linux 系统（Ubuntu/Debian）：sudo apt-get install git；（CentOS/RHEL）：sudo yum install git

打开终端（Git Bash/系统终端），执行以下命令：

git --version

若显示版本号则说明安装成功，若未显示，则检查环境变量是否添加成功。

（2）必做配置：用户身份配置

Git 要求每一次提交必须记录提交者身份，就像交作业需要有姓名及联系方式一样。这个是必做配置，好比QQ发信息必须要QQ号一样。

git 配置用户身份分为两种：

# 1. 全局配置（设置一次即可，后续所有本地仓库通用）
# 多次执行会覆盖更新之前的配置，因此用户名和邮箱可以随时修改
git config --global user.name "Joker"  # 自定义用户名
git config --global user.email "Joker@email"    # 常用邮箱

# 2. 局部配置（仅当前仓库生效，适用于多身份场景，去掉 --global 即可），
git config user.name "你的仓库专属用户名"
git config user.email "你的仓库专属邮箱"

# ----列出全局配置信息，可验证是否配置成功----
git config --global --list

如果不进行协同工作，只是在自己电脑自己管理文件，用户名和邮箱可以随便填写，甚至造一个。但是一旦涉及到远程协同，或者使用GitHub，那么联系方式最好真实有效。

全局配置一次设置之后，后续所有项目都会默认使用这个用户名和联系方式，除非针对某个项目进行了局部配置。

关于局部配置，这是针对某个项目的配置，因为一个人可以接手多个项目，而你在每个项目的“代号”或许是不同的，所以可能需要根据不同项目配置不同的名字和联系方式。

3. Git 本地使用流程

先介绍最基础的「本地版本管理」流程案例，不连接远程仓库，本地完成文件的版本跟踪。

（1）初始化本地 git 仓库

进入需要管理的目录，将之初始化为 Git 仓库（适用于从零开始的项目、本地的项目）

# 1. 进入目标目录（替换为你的实际目录路径）
cd D:\Project\MyGitProject
# 2. 初始化 Git 仓库，执行后目录下会生成隐藏的 .git 文件夹（核心配置目录）
git init

（2）工作区操作：新建/修改文件

在仓库目录下新建/修改文件（如 test.py、README.md），此时文件处于「工作区」（未被 Git 跟踪）。

（3）暂存区操作：将文件纳入 Git 跟踪

使用 git add 命令将工作区的文件提交到「暂存区」（临时存储，相当于“提交缓冲区”），这是提交到版本库的前置步骤。

# 方式 1：添加指定单个文件（替换为你的文件名）
git add test.py
# 方式 2：添加当前目录下所有修改/新增的文件（推荐，高效便捷）
git add .
# 方式 3：添加当前目录下所有修改/新增的文件（与 git add . 功能类似，略有差异，可通用）
git add -A

如果项目中有不想纳入管理的文件，可以新建一个名为.gitignore 的文件，并将不想纳入管理的文件目录、文件夹目录填写到其中，之后，再使用git add . 会自动忽略.gitignore文件中的内容。

建议优先将项目的源代码文件、md文件、需要手动编辑的配置文件等纳入git管理，而其余文件及文件夹的路径，比如构建目录、二进制文件、图片视频、log文件等，填写在.gitignore文件中以忽略。

（4）版本库操作：提交暂存区文件到本地仓库

使用 git commit 命令将暂存区的文件永久提交到「本地版本库」，生成一个唯一的版本快照（含提交信息、作者、时间等）。

# 格式：-m 后跟随提交说明（必须填写，规范清晰的说明便于后续追溯版本）
git commit -m "提交说明：如 初始化项目、修改test.py功能、修复某某bug"
# 示例 
git commit -m "初始项目状态"

注意：提交说明要简洁明了，避免无意义的描述（如 “update”、“fix”），建议包含「操作类型+内容」。

commit会随机生成唯一的、一串十六进制数，代表该次的commit记录，后续通过这串数字进行版本回退，分支切换等。

（5）查看版本历史：追溯提交记录

使用 git log 命令查看本地仓库的所有提交历史，便于回溯版本、查看修改记录。

# 方式 1：完整格式显示所有提交历史（按 q 键退出查看）
git log
# 方式 2：简洁格式显示（每行一条记录，仅显示哈希值前7位和提交说明，推荐）
git log --oneline
# 方式 3：显示所有分支的提交历史（含分支合并记录）
git log --graph --oneline --all

查看提交记录，记录对应的备注说明、快照对应的哈希值（上一步的一串十六进制数），以便于下一步的回溯。

二、常见场景

1. 仓库初始化场景

场景1：本地初始化Git仓库

操作命令

# 1. 进入项目根目录（替换为你的项目路径）
cd /path/to/your/project

# 2. 初始化 Git 仓库，生成 .git 隐藏目录（存储仓库配置和版本记录）
git init

作用：将本地目录转化成git可管理的仓库，之后才可以进行提交、分支等 Git 操作。

使用该命令后，自动生成.git目录，其中包含仓库的相关数据，不用管它，也不要删除。

场景2：远程clone 到本地

操作命令：

# 方式 1：HTTPS 协议（无需配置，克隆时可能需输入远程仓库账号密码/个人访问令牌）
git clone https://github.
  
   com
  /xxx/xxx-repo.git

# 方式 2：SSH 协议（需提前配置 SSH 密钥，后续克隆/推送无需重复验证）
git clone git@github.
  
   com
  :xxx/xxx-repo.git

# （可选）克隆后指定本地仓库目录名（避免使用默认仓库名）
git clone https://github.
  
   com
  /xxx/xxx-repo.git my-local-repo-name

作用：将远程仓库的完整代码、版本历史克隆到本地，快速获取可开发的项目副本。

clone远程仓库到本地，因为其已经是一个git仓库的（半）成品，所以里面会有他人的历史提交记录，已创建的分支。

场景3：设定`.gitignore`文件

创建 .gitignore文件：

# 方式 1：命令行输入以下命令，创建该文件
touch .gitignore

# 方式 2：右击 => 新建任意文件，比如记事本 => 删除原来文件名及后缀名 => 修改为 .gitignore

编辑 .gitignore文件：

使用记事本、vim、VScode都可以打开它。

假如我的项目中，我要忽略build文件夹、assets下的images文件夹，以及temp.log文件。

D:.
├───build
├───assets
│   └───images
├───include
├───pyScript
├───src
├─temp.log
└─readme.md

直接将对应目录填入即可，相对于.gitignore文件所在目录即可。

# 忽略目录如下
./build/
./assets/images/
temp.log

简单的使用照葫芦画瓢即可，还有一些语法规则，可参照：

# 忽略所有 .log 后缀文件. 
*.log

# 忽略 node_modules 文件夹（前端项目依赖）
node_modules/

# 忽略 IDE 配置文件夹（VS Code）
.vscode/

# 忽略环境变量配置文件（包含敏感信息）
.env

# 忽略编译后的构建目录
dist/
build/

# 例外：不忽略 test.log 文件（覆盖上面的 *.log 规则）
!test.log

语法规则支持通配符：* 匹配任意字符、/ 匹配目录、! 表示不忽略，即追踪。

2. 日常开发流程

场景1：查看当前工作区 / 暂存区状态（确认文件修改情况）

操作命令：

# 基础查看，显示文件修改状态（未跟踪、已修改、已暂存）
git status

# 简化查看，输出简洁结果（适合熟悉状态标识的用户）
git status --short  # 简写：git status -s

快速了解当前仓库的文件变更情况，区分「未被 Git 追踪的新文件」「已修改但未暂存的文件」「已暂存待提交的文件」，这是最常用的校验命令。

注意： 在每次提交 commit 前建议先执行 git status，确认待提交的文件无遗漏、无多余（如误改的配置文件）。相当于每次使用commit之前，养成使用git status的习惯。

场景2：将工作区修改添加到暂存区（准备提交）

操作命令：

# 方式 1：添加单个指定文件到暂存区（推荐，精准提交，避免多余文件）
git add filename.ext  # 示例：git add src/main.js

# 方式 2：添加多个指定文件到暂存区，空格隔开即可
git add file1.ext file2.ext dir/

# 方式 3：添加当前目录下所有修改（已追踪文件的修改、删除，不包含未追踪新文件）
git add .

# 方式 4：添加当前仓库所有变更（包含未追踪新文件，慎用，易提交多余文件）
git add -A  # 等价于 git add --all

作用说明

将工作区的文件变更「暂存」起来，形成一个提交候选集，暂存区是工作区和本地仓库之间的过渡区域，只有暂存的内容才能被提交到本地仓库。

在commit之前，我们会先执行git status检查，如果有觉得合适需要提交的修改，需要执行 add 命令添加到暂存区，之后才能commit。

场景 3：将暂存区内容提交到本地仓库（生成版本记录）

操作命令：

# 方式 1：直接在命令行填写提交说明（推荐，简洁高效）
git commit -m "feat: 新增用户登录功能"

# 方式 2：跳过暂存区，直接将已追踪的修改提交到本地仓库（无需先执行 git add）
git commit -am "fix: 修复登录按钮点击无响应问题"

# 方式 3：修改最后一次提交（提交信息写错、遗漏少量文件，未推送到远程时使用）
git commit --amend  # 打开vim 重新编辑提交信息
git commit --amend -m "修正后的提交说明"  # 直接覆盖最后一次提交信息

作用说明

将暂存区的变更生成一条不可篡改的版本提交记录（或者称之为快照），包含提交者、提交时间、提交说明和文件变更内容，是版本管理的核心步骤。

注意事项

提交说明建议遵循规范（如 Conventional Commits），格式为「类型：描述」，便于后续方便根据备注追溯历史（常用类型：feat 新功能、fix 修复、docs 文档、style 格式调整、refactor 重构）。
git commit --amend 会改写最后一次提交历史，若该提交已推送到远程公共分支，严禁使用，会导致团队协作冲突。
git commit -am 仅对已被 Git 追踪的文件有效，新创建的未追踪文件无法直接使用该命令。

场景4：查看提交历史（追溯版本变更）

操作指令：

# 方式 1：查看完整提交历史（按时间倒序，包含完整哈希、作者、时间、提交说明）
git log

# 方式 2：简洁查看，每条提交仅显示一行（哈希简写+提交说明，推荐）
git log --oneline

# 方式 3：查看指定数量的最新提交（示例：查看最近 5 条提交）
git log --oneline -5

# 方式 4：查看提交历史并附带文件变更统计（了解每次提交修改了哪些文件）
git log --stat

# 方式 5：可视化查看分支合并历史（命令行中像图形格式化展示，适合多分支协作场景）
git log --graph --oneline --all

# ---------------------------------------
# reflog 是参考日志，追踪所有Git操作历史，误操作（删除分支、丢弃提交等）后的最后一根救命稻草。
# 但是数据有默认保存期限，通常为90天，仅追踪本地仓库，不涉及远程仓库
git reflog

作用说明

追溯本地仓库的版本提交记录，可查询提交者、提交时间、文件变更，用于定位问题、回退版本等操作。

注意事项

若显示的提交历史太长，会导致屏幕显示不完整，自动进入命令模式，可使用 q 键退出 git log 查看界面。

3. 版本回退

场景1：丢弃工作区未暂存的修改（单个 / 所有文件）

操作命令：

# 方式 1：丢弃单个文件的工作区未暂存修改
git checkout -- filename.ext  # 示例：git checkout -- src/main.js

# 方式 2：丢弃当前目录下所有文件的工作区未暂存修改
git checkout -- .

作用说明

将文件恢复到「最近一次暂存或提交」的状态，丢弃工作区的未暂存修改，仅影响工作区，不改变暂存区和本地仓库。

注意事项

该操作不可逆，丢弃的修改无法恢复，执行前需要确保修改无保留价值。

场景 2：撤销暂存区的修改（恢复到工作区，不丢弃修改）

# 方式 1：撤销单个文件的暂存状态（从暂存区退回工作区）
git reset HEAD filename.ext  # 示例：git reset HEAD src/main.js

# 方式 2：撤销所有文件的暂存状态（全部退回工作区）
git reset HEAD

作用说明

取消文件的暂存状态，将变更从暂存区退回工作区，保留修改内容，便于重新筛选暂存。

注意事项

该操作仅改变暂存区，不影响工作区的修改，是安全操作，无需担心数据丢失。

场景 3：彻底回退到指定提交（丢弃后续所有修改和提交）

操作命令：

# 步骤 1：查看提交历史，拷贝回退目标提交的简写哈希，取前几位即可。（如 a1b2c3d）
git log --oneline

# 步骤 2：硬重置到目标提交（彻底丢弃后续所有提交和修改，不可逆）
git reset --hard <commit-id>  # 示例：git reset --hard a1b2c3d

# (补充) 若仅回退到上一次提交，可简写为
git reset --hard HEAD^  # HEAD^ 表示上一个提交，HEAD^^ 表示上两个，以此类推

作用说明

将当前分支的 HEAD 指针强制移动到目标提交。
覆盖暂存区和工作区，使其完全匹配目标提交的状态。
彻底丢弃目标提交之后的所有提交记录和修改，不可逆。

注意事项

该操作风险极高，执行前请确认后续修改无保留价值，或提前备份相关文件。
若目标提交已推送到远程仓库，回退后需要强制推送才能同步（git push -f），公共协作分支严禁使用，会覆盖远程历史，导致其他成员提交丢失。

场景 4：安全暂回指定提交（不丢弃后续修改，仅查看测试）

# 切换到目标提交对应的状态（进入分离头指针模式）
git checkout <commit-id>  # 示例：git checkout a1b2c3d

作用说明

暂时脱离当前分支，进入「分离头指针」状态，工作区同步到目标提交的内容，可用于查看、测试该版本的代码，不修改任何提交历史，后续可随时切回原分支恢复修改。

注意事项

分离头指针模式下不要提交新代码，若提交，切换回原分支时会丢失这些新提交。
如需保留分离头指针下的新提交，可基于此状态创建新分支：git checkout -b new-branch-name。
切回原分支恢复后续修改：git checkout 你的分支名（如 git checkout main）

场景 5：删除最后一次提交但保留修改（软重置）

操作命令：

# 软重置到上一次提交，修改保留在工作区（未暂存）
git reset --soft HEAD^

作用说明

将 HEAD 指针回退到上一次提交，丢弃最后一次提交记录，但保留该提交的所有修改内容（退回工作区），便于重新整理后再次提交，是安全的「撤销提交」方式。

注意事项

该操作仅修改提交历史，不丢弃任何代码，适合提交后发现需要补充修改，且不想生成多条冗余提交的场景。

4. 分支管理

场景 1：查看所有分支（本地 + 远程）

# 方式 1：查看本地所有分支（当前分支前标有 *）
git branch

# 方式 2：查看本地+远程所有分支
git branch -a  # 简写：git branch --all

# 方式 3：仅查看远程分支
git branch -r  # 简写：git branch --remotes

作用说明

了解当前仓库的分支分布，确认当前所在分支，以及远程仓库的分支情况。

场景 2：创建新分支（基于当前分支 / 指定分支 / 提交）

操作指令：

# 方式 1：创建新分支（仅创建，不切换）
git branch new-branch-name  # 示例：git branch feature/user-center

# 方式 2：创建新分支并直接切换到该分支（推荐，常用）
git checkout -b new-branch-name  # 示例：git checkout -b feature/user-center

# 方式 3：基于远程分支创建本地分支（同步远程分支内容）
git checkout -b local-branch-name origin/remote-branch-name  # 示例：git checkout -b dev origin/dev

# 方式 4：基于指定提交创建新分支（用于抢救旧版本代码）
git checkout -b new-branch-name <commit-id>  # 示例：git checkout -b fix/old-bug a1b2c3d

作用说明

分支是 Git 实现并行开发、隔离功能的核心，新分支会继承原分支 / 提交的所有代码和版本历史，便于在不影响主分支的前提下开发新功能、修复 Bug。

注意事项

日常开发中，主分支（main/master）通常用于发布版本，禁止直接在主分支开发，需创建开发分支（dev/xxx）、功能分支（feature/xxx）、Bug 修复分支（fix/xxx）等进行开发。

场景 3：切换已存在的分支

git checkout branch-name  # 示例：git checkout main

# （Git 2.23+ 新增，更直观的切换命令，功能与 git checkout 一致）
git switch branch-name  # 示例：git switch dev

作用说明

切换到目标分支，工作区会同步为该分支的最新状态，便于在不同分支间切换开发。

注意事项

切换分支前，需确保当前分支的修改已提交或暂存（git stash），否则 Git 会阻止切换（避免修改丢失）。

场景 4：合并分支（将其他分支内容合并到当前分支）

# 步骤 1：切换到接收合并的目标分支（如将 feature 分支合并到 main 分支）
git checkout main

# 步骤 2：确保目标分支是最新状态（多人远程协作时，先拉取远程最新代码; 本地个人开发不需要这一步）
git pull origin main

# 步骤 3：执行合并命令，将 source-branch 合并到 => 当前分支
git merge source-branch  # 示例：git merge feature/user-center

# （补充）若合并过程中出现冲突，解决冲突后执行以下命令完成合并
git add 冲突文件名.ext  # 标记冲突已解决
git commit -m "merge: 合并 feature/user-center 分支，解决登录功能冲突"

作用说明

将源分支的所有提交变更合并到目标分支，完成并行开发后的代码整合，是多人协作中整合功能的核心操作。

注意事项

合并前建议先在源分支完成自测，确保代码无语法错误、功能正常。
合并冲突是常见情况，Git 会在冲突文件中标记 <<<<<<<< HEAD（当前分支内容）、=======（分隔线）、>>>>>>> source-branch（源分支内容），需手动编辑保留正确内容，删除冲突标记。
若合并过程中想放弃合并，执行 git merge --abort 撤销合并，恢复到合并前的状态。

场景 5：删除分支（本地 + 远程）

# 方式 1：删除本地已合并的分支（安全，Git 会校验是否已合并，避免误删）
git branch -d branch-name  # 示例：git branch -d feature/user-center

# 方式 2：强制删除本地未合并的分支（丢弃该分支所有修改，慎用）
git branch -D branch-name  # 示例：git branch -D feature/unused

# 方式 3：删除远程仓库的分支（多人协作时，功能上线后清理远程分支）
git push origin --delete remote-branch-name  # 示例：git push origin --delete feature/user-center

作用说明

清理无用分支，保持仓库分支结构整洁，避免分支过多造成混乱。

注意事项

删除本地分支前，确认该分支的内容已合并到其他分支或无保留价值。
删除远程分支后，其他协作成员需执行 git fetch --prune 同步远程分支删除记录，更新本地远程分支列表。

场景 6：更新本地远程分支列表（远程分支新增 / 删除后同步）

# 拉取远程仓库最新信息，并清理本地无效的远程分支引用（已在远程删除的分支）
git fetch --prune  # 简写：git fetch -p

作用说明

同步远程仓库的分支变更，确保本地查看的远程分支列表与远程仓库一致，避免看到已在远程删除的无效分支。

5. 远程仓库协作

场景 1：查看已关联的远程仓库

# 查看远程仓库的简短信息（名称+地址）
git remote

# 查看远程仓库的详细信息（名称+完整地址+推送/拉取地址）
git remote -v  # 简写：git remote --verbose

作用说明

确认本地仓库已关联的远程仓库，默认远程仓库名称为 origin。

场景 2：关联本地仓库到远程仓库（本地新建仓库后推送远程）

# 关联远程仓库（替换为你的远程仓库地址，https/ssh 均可）
git remote add origin https://github.
  
   com
  /xxx/xxx-repo.git

# （补充）若需删除已关联的远程仓库
git remote remove origin

作用说明

将本地仓库与远程仓库建立关联，后续可通过 origin 进行推送（push）和拉取（pull）操作。

场景 3：拉取远程仓库最新代码到本地

# 方式 1：拉取远程指定分支的最新代码，并自动合并到当前本地分支
git pull origin remote-branch-name  # 示例：git pull origin main

# 方式 2：仅拉取远程最新代码，不自动合并（先查看变更，再手动合并，更安全）
git fetch origin remote-branch-name  # 示例：git fetch origin main

# 方式 3：拉取远程所有分支的最新代码（同步远程分支变更）
git fetch --all

作用说明

获取远程仓库的最新代码变更，同步到本地，避免本地代码与远程存在差异导致推送冲突。

注意事项

git pull 等价于 git fetch + git merge，自动合并可能会产生冲突，多人协作高频更新场景下，推荐使用 git fetch 先查看变更，再手动合并。
拉取前确保当前分支的修改已提交或暂存，避免合并时出现冲突混乱。

场景 4：推送本地代码到远程仓库

# 方式 1：首次推送本地分支到远程（-u 关联本地分支与远程分支，后续可简化为 git push）
git push -u origin local-branch-name  # 示例：git push -u origin main

# 方式 2：非首次推送，推送当前分支的最新提交到远程关联分支
git push

# 方式 3：推送指定本地分支到远程指定分支（分支名不同时使用）
git push origin local-branch-name:remote-branch-name

作用说明

将本地仓库的提交记录推送到远程仓库，实现代码共享和团队协作，让其他成员可以获取你的修改。

注意事项

推送前建议先执行 git pull 拉取远程最新代码，避免出现「远程仓库比本地新」的推送冲突。
若本地改写了提交历史（如 git reset --hard），推送时需要使用强制推送 git push -f，公共分支严禁使用。

场景 5：更换远程仓库地址（远程仓库地址变更 / 迁移）

# 方式 1：直接修改远程仓库的地址（推荐）
git remote set-url origin 新的远程仓库地址  # 示例：git remote set-url origin git@github.
   
    com
   :xxx/new-repo.git

# 方式 2：先删除旧的远程仓库，再添加新的
git remote remove origin
git remote add origin 新的远程仓库地址

作用说明

当远程仓库地址变更（如仓库迁移、HTTPS 改 SSH）时，更新本地仓库的远程关联地址，确保后续推送 / 拉取操作正常。

6. 特殊场景

场景 1：暂存当前未提交的修改（切换分支前保存工作进度）

# 方式 1：暂存当前所有未提交修改（工作区+暂存区），生成一条 stash 记录
git stash

# 方式 2：暂存并添加备注（便于后续区分多个 stash 记录，推荐）
git stash save "feat: 未完成的用户中心开发"

# 方式 3：查看所有 stash 记录
git stash list

# 方式 4：恢复最新的 stash 记录，且保留 stash 记录（可重复恢复）
git stash apply

# 方式 5：恢复最新的 stash 记录，且删除该 stash 记录（推荐，恢复后清理）
git stash pop

# 方式 6：恢复指定的 stash 记录（示例：恢复第 0 条记录，从 0 开始计数）
git stash apply stash@{0}

# 方式 7：删除指定的 stash 记录
git stash drop stash@{0}

# 方式 8：删除所有 stash 记录（清理无用缓存）
git stash clear

作用说明

当需要切换分支，但当前分支的修改尚未完成（无需提交）时，可将修改暂存到「stash 缓存区」，切换分支后再恢复，避免修改丢失或污染其他分支。

注意事项

git stash 不会暂存「未被 Git 追踪的新文件」（如新建的未 git add 的文件），若需暂存，可先执行 git add，或使用 git stash -u（暂存未追踪文件）。
恢复 stash 记录时，若当前分支存在同名文件的修改，可能会产生冲突，需手动解决。

场景 2：删除未追踪的文件 / 文件夹（清理项目冗余文件）

# 方式 1：查看将被删除的未追踪文件/文件夹（先预览，避免误删，推荐）
git clean -nfd

# 方式 2：彻底删除未追踪的文件（f）和文件夹（d），不可逆
git clean -fd

作用说明

清理项目中未被 Git 追踪的冗余文件（如临时文件、未被忽略的依赖文件），保持项目目录整洁。

注意事项

该操作不可逆，删除的文件无法恢复，执行前务必先用 git clean -nfd 预览。
仅删除未被 Git 追踪的文件，已追踪的文件不受影响。

Git 操作的核心是「版本记录」，所有提交都会形成不可篡改的历史快照，分支操作是并行开发的常用操作。
对于一些高危操作（如，–hard、push -f、git clean -fd）执行前务必确认无数据丢失风险，多人协作优先使用安全操作。
团队协作中，需遵循统一的分支规范、提交规范，避免不必要的冲突。
以上是 git 开发可能遇到的场景，更高级的操作（变基、子模块等）可参考 Git 官方文档，或者借助搜索工具。
–2026.1.14