Git - Jul1en

Git stash

Fri, 15 May 2026 05:40:20 +0000

Git stash

在使用 Git 开发时，我们经常会遇到一种很尴尬的情况：当前功能还没写完，代码处于“半成品”状态，既不适合提交 commit，也不想直接丢掉。但这时突然来了一个新的任务，比如需要马上切换分支去修 Bug，或者需要拉取远程最新代码。

问题就出现了：Git 默认不太喜欢你带着一堆未提交的修改到处切换分支。因为这些修改可能会和目标分支的文件产生冲突，Git 无法确定你到底想保留哪一份内容。

这时候就需要 git stash。

stash 的作用可以理解为：把当前还不想提交的修改临时存起来，让工作区恢复到干净状态。等你处理完别的事情后，再把这些修改取回来继续写。

核心理解

Git 里常见的代码状态主要有三个区域：

区域	含义
工作区 Working Directory	你正在编辑的文件内容
暂存区 Staging Area / Index	已经`git add`，准备提交的内容
本地仓库 Repository	已经 commit 的历史版本

普通的 git commit 是把暂存区内容正式保存到版本历史里。

而 git stash 是把当前工作区和暂存区里的修改临时打包，放进一个 Git 管理的临时栈里。

当前写到一半的代码 -> git stash -> 临时保存到 stash 栈中 -> 工作区恢复干净 -> 切换分支 / 拉代码 / 修 Bug -> git stash pop 或 git stash apply -> 恢复刚才写到一半的代码

这里涉及到了栈的知识。

stash 保存的内容不是只有一份，而是可以保存多份。每执行一次 git stash，Git 就会往 stash 栈里新增一条记录。

最新的一条通常叫：stash@{0}，数字越小，表示越新。

再旧一点的是：stash@{1}、stash@{2}

最常用操作

临时保存当前修改

最基础的命令是：

git stash

或者更推荐写成：

git stash push

执行后，Git 会把当前工作区和暂存区里的修改保存起来，然后让项目回到一个干净状态。

比如你正在开发登录功能：

LoginController.java   修改中
UserService.java       修改中

但是突然需要切换到 hotfix 分支修 Bug，这时候可以执行：

git stash push

然后再切换分支：

git checkout hotfix

或者：

git switch hotfix

这样当前没写完的登录功能不会被丢掉，也不会影响你去处理别的任务。

添加说明

如果 stash 记录多了，只看 stash@{0}、stash@{1} 会很难分清楚每一份是干什么的。

所以更推荐加上说明：

git stash push -m "开发登录功能，临时保存"

之后查看 stash 列表时，就能看到这条说明。

这就像给临时保存的代码贴了一个便利贴，后面找起来会轻松很多。

查看 stash 列表

查看当前保存过的 stash：

git stash list

示例：

stash@{0}: On feature-login: 开发登录功能，临时保存
stash@{1}: On dev: 修改订单模块样式
stash@{2}: On main: 调整配置文件

这里需要注意，stash 是按照时间倒序排列的，最新的永远在最上面。

查看某个 stash 里改了什么

只看简略变更：

git stash show stash@{0}

如果想看具体代码差异：

git stash show -p stash@{0}

其中 -p 表示以 patch 的形式展示详细修改内容。

如果你 stash 记录很多，恢复之前最好先看一下，避免把不相关的旧代码恢复回来。

恢复

恢复 stash 主要有两个命令：apply 和 pop。

它们看起来都能把代码拿回来，但差别很重要。

apply

git stash apply

恢复代码，stash 记录还保存着。

默认恢复最新的一条：git stash apply stash@{0}

git stash apply stash@{0}

如果要恢复指定记录：git stash apply stash@{1}

也就是说，你把临时代码拿回来了，但 Git 不会自动删除那条 stash。

适合的场景是：你不确定这份 stash 恢复后是否完全正确，想先拿出来试试看。如果没问题，再手动删除。

pop

git stash pop

恢复代码，并尝试删除这条 stash 记录。

它相当于：git stash apply 加上 git stash drop

也就是说，代码恢复回来之后，这条临时记录就会从 stash 栈里移除。

不过如果恢复时发生冲突，Git 通常不会直接删除 stash 记录，这样可以避免代码丢失。

pop 更适合已经确定这条 stash 就是要继续使用的场景。

apply 和 pop 的区别

命令	是否恢复代码	是否删除 stash 记录	适合场景
`git stash apply`	是	否	想先恢复看看，保留备份
`git stash pop`	是	是	确定要恢复并继续开发

删除

删除特定 stash

git stash drop stash@{0}

这会删除指定的一条 stash。

如果你已经用 apply 恢复过代码，并且确认这条 stash 不需要了，就可以手动删除。

清空所有 stash

git stash clear

这个命令会删除所有 stash 记录。

这个操作要谨慎，因为一旦清空，普通方式下就很难再找回来了。

一般不建议随手执行，除非你非常确定这些临时修改都不需要了。

注意事项

这是学习 stash 时非常容易踩坑的地方。

默认情况下：git stash会保存已被 Git 跟踪的文件修改，如 git add 到暂存区的修改这两类文件

但它默认不会保存新建但还没有被 Git 跟踪的文件，如.gitignore 忽略的文件，这个新文件不会被 stash 保存。

保存未跟踪文件

如果想把新建的、还没被 Git 跟踪的文件也一起 stash，可以使用：git stash push -u

-u 是 –include-untracked 的简写，表示把未跟踪文件也保存进去。

eg：git stash push -u -m "保存登录功能和新建测试文件"，这样新建文件也会一起被临时保存。

保存被忽略的文件

如果连 .gitignore 里忽略的文件也想一起保存，可以使用git stash push -a命令，这会把所有文件都包含进去，包括一些本地构建产物、缓存文件、临时文件也一起 stash 进去~

stash 指定文件

有时候你并不想保存所有修改，只想 stash 某几个文件。那就在stash后面跟上具体的文件名，跟git add操作一致

git stash push -m "只保存配置文件修改" src/main/resources/application.yml

如果有多个文件，就用空格分开：

git stash push -m "保存登录相关修改" LoginController.java UserService.java

这样 Git 只会把指定文件的修改临时保存起来，其他文件的修改还会留在工作区。

这个操作在多人协作时很有用。比如你只想临时收起某个模块的修改，但另一个模块还要继续调试，就可以精确 stash。

从 stash 创建新分支

有时候你写着写着发现：这部分代码不应该继续放在当前分支了，应该单独开一个新分支。

这时可以使用：

git stash branch new-branch-name stash@{0}

执行逻辑：

基于 stash 创建时所在的提交创建一个新分支
切换到这个新分支
把 stash 里的修改恢复出来
如果成功，删除对应的 stash

这个命令适合写着写着发现分支开错了的情况。比如你本来在 dev 分支上随手改了登录功能，但后来发现应该新开一个 feature-login 分支。这时就可以先 stash，再用 git stash branch 把修改转移到新分支上。

stash 冲突解决

stash 恢复时也可能产生冲突。比如你 stash 的时候修改了 UserService.java，后来目标分支也修改了同一个文件的同一段代码。此时执行git stash pop：

git stash pop

Git 可能会提示冲突。

冲突文件里通常会出现类似结构：

<<<<<<< Updated upstream
当前分支中的代码
=======
stash 中恢复出来的代码
>>>>>>> Stashed changes

解决方式和普通 merge 冲突类似：先打开冲突文件，手动决定保留哪部分代码。修改完成后再次add冲突文件后文件执行就可以接下来的工作了。

如果你使用的是 pop，并且发生了冲突，要注意检查 stash 是否还在：

git stash list

如果冲突导致 stash 没有被删除，解决完之后可以手动删除：

git stash drop stash@{0}

命令总结

命令	作用
`git stash`	临时保存当前修改
`git stash push`	更推荐的 stash 写法
`git stash push -m "说明"`	保存 stash 并添加说明
`git stash list`	查看 stash 列表
`git stash show stash@{0}`	查看某条 stash 的简略变更
`git stash show -p stash@{0}`	查看某条 stash 的详细代码差异
`git stash apply`	恢复最新 stash，但不删除记录
`git stash apply stash@{1}`	恢复指定 stash，但不删除记录
`git stash pop`	恢复最新 stash，并删除记录
`git stash drop stash@{0}`	删除某条 stash
`git stash clear`	清空所有 stash
`git stash push -u`	保存未跟踪文件
`git stash push -a`	保存所有文件，包括 ignored 文件
`git stash branch new-branch stash@{0}`	从 stash 创建新分支并恢复修改

理解图

git stash 本质上是 Git 提供的临时保存现场机制。它适合在代码还没完成、不想提交，但又必须切换任务时使用。它不会替代 commit，而是补充 commit 之前那段混乱、临时、半成品的开发过程。用得好的话，stash 可以让你在多个任务之间切换时更从容，不至于因为工作区不干净而手忙脚乱~

‍

Git LFS 突破大文件上传限制

Fri, 03 Apr 2026 00:18:50 +0800

Git LFS

接触此技术背景

本人一直有将笔记备份的习惯，虽然已经有云同步，但是异地存档能再加多层保险

随时间推移，笔记内容也越来越多，我的笔记快照的体积越来越大，最近一次直接超出了 Git 单次推送的最大体积限制（100MB），在查询解决方法时，发现 Git 有一种叫 LFS 的技术（Large File Storage），他能很好的解决此问题。

技术介绍

Git LFS 是 Git 的一个开源扩展，旨在解决 Git 在处理大尺寸二进制文件（如视频、数据集、压缩包）时的性能瓶颈。

因为 Git 的设计初衷是管理文本文件，它会完整记录文件的每一个版本。对于像我这样提交这么大我体积的的 ZIP 包，如果修改一次再提交，仓库体积会立刻翻倍。

底层原理

那么它的思路就是把大文件给“拆开”。

LFS 的解决方法是：当你将文件放入 LFS 管理时，Git 仓库中存储的不再是那个 180MB 的实体，而是一个几百字节的指针文件。真实的二进制数据被存储在 GitHub 的 LFS 专用服务器上。

当执行 git checkout 时，LFS 会根据指针里的哈希值，自动从服务器下载对应的真实文件覆盖到你的工作区。这样本地的 .git 目录（版本库历史）依然保持精简，这个设计非常巧妙。

技术实现

我的最近一次提交是错误的，虽然提交了但是 push 失败了，故必须通过重置索引并应用 LFS 规则来修复。

首先要安装 LFS 扩展

# 在你本地的git工作区
git lfs install

标记你的大文件由 LFS 来管理，以我的笔记快照为例，它的文件格式就是 .ZIP，那么命令就是
```
git lfs track "*.zip"
```
注意：这会生成或更新 .gitattributes 文件，必须将其一同提交

重新添加并提交

由于你之前的 Commit 已经包含了这个超限文件，需要先撤销上一次失败的提交，重新打包提交

# 撤销上一次 commit，但保留文件变动
git reset --soft HEAD~1

# 重新添加属性文件和大文件
git add .
git commit -m "commit message"
git push origin master

执行到这一步，就已经能正确 push 上去了

后续维护

看到这会有疑惑：那么这次能提交成功了，后续该如何维护呢？

维护 LFS 需要关注 .gitattributes 文件、本地存储占用以及云端配额三个维度

追踪管理

你需要明确告诉 Git 哪些文件属于大文件。使用命令 git lfs track "你的文件"。这会更新 .gitattributes 文件。每次更新必须提交这个属性文件，否则协作成员拉取代码时，Git 会将其当作普通大文件处理，再次导致推送失败
监控状态
- 使用 git lfs ls-files：查看当前索引中哪些文件正受 LFS 管理
- 使用 git lfs status：检查当前暂存区的对象状态
本地存储清理

长期频繁更新大文件会导致本地 .git/lfs 目录体积激增。使用 git lfs prune 可以安全删除本地不再被当前分支引用的旧版二进制块。
配额管理

GitHub 免费账户提供 1GB 存储和 1GB 每月下行流量，这要注意它的限制，如果配额耗尽，别人拉下来的包都是指针文本，不会真正下载内容

希望对你有帮助，祝您身体健康。

‍

🪶 Git命令大全

Mon, 15 Dec 2025 00:47:22 +0800

Git命令大全

前提介绍

git是一个分布式版本控制系统，相当于一个时光机，拿来保管代码，一旦出错，可以随时回滚到任何一个历史节点

其核心架构分为三个区域：工作区（写代码的地方）、暂存区（临时存放的地方）和版本库（安全存档的地方）

添加文件

git add .表示添加所有在工作区的文件至暂存区

git add <fileName> <fileName>

eg：git add file1 file2

提交

提交暂存区的文件至版本库中

git commit -m "<填写你要备注的内容>"

eg：git commit -m "no message commit"

查看日志

查看最近日志：git log / git log --pretty=oneline
记录本地每一次提交的命令 git reflog

得到每一次的id，此id可用于版本回退功能

高亮部分就是每次提交的id，用git reflog命令也能得到，且id更加简洁

版本回退

它有三个版本

git reset [--soft / --mixed / --hard] <HEAD>，区别如图所示

git reset <使用 git log / git reflog 后查看的对应版本的提交id>，版本id在<查看日志>部分可得到

eg：git reset --mixed 3f50f68

查看当前仓库状态

查看与上一次提交之后到现在是否对文件进行修改（工作区）

git status

查看是哪个文件被修改了之后，用下面介绍的diff命令即可查看修改的具体内容

查看差异

查看暂存区与工作区之间的差异：git diff <fileName>

eg：git diff ReadMe

‍
查看版本库和工作区文件的区别：git diff HEAD --<fileName>

eg：git diff HEAD -- ReadMe

撤销修改

如果你在工作区中写了好多天的代码，但是效果还不如初次的，此时你想要退回到未修改的状态，就需要撤销修改操作

撤销修改虽然可以手动把你自己写的代码删掉，但如果写的太多了，手动删除会有隐患且耗费时间精力

撤销的目的，就是为了不影响远程仓库，所以撤销修改的前提是代码没有push到远程仓库

以下是撤销修改的命令，分三种情况

删除文件

终端命令使用rm <fileName>，这时会将工作区的文件删除，如果想提交修改的话后续使用add 、commit操作，分为三步
git 也提供了这个命令，将这个流程简化为了两布：git rm <fileName>，这是将工作区与暂存区的文件同时删除，此时git已经自动将删除后的文件提交到暂存区中，只需要commit操作即可

‍

分支

查看本地仓库分支情况

git branch

创建分支

在git branch后加上想要添加分支的名字即可

git branch <branchName>，如：git branch dev

切换分支

跟撤销修改的命令有点相似，只是少了--

git checkout <已有的分支>，如：git checkout dev

还能使用切换并创建一个未创建的分支，使用git checkout -b <branchName>，相当于git branch <branchName> + git checkout <branchName>

合并分支

合并分支的前提下是在选定某一个分支内对另一分支进行合并，不能合并现在所选的分支上

git merge <branchName>（Fast-forward模式）

例如有两个分支：master 和 dev

如果想要合并dev分支，那需要讲选中的分支切换到master上，用git branch来查看现在所处的分支，前面带 * 号的就是所在分支

像这样，所在是分支dev，就使用git checkout master转回master分支

然后就能进行合并操作了，使用git merge dev，这时master就指向了dev的最新一次提交

此时的分支情况为

在这种Fast-forward模式下，删除分支历史时，会丢掉分支的信息，看不出来最新的提交是merge进来的还是master分支上正常提交的，为了更好的溯源以及留痕，日后便于发现是哪个分支提交出了问题，在合并的时候会使用no-ff模式，即No-Fast-forward

git merge --no-ff -m "新提交的信息" <branchName>

其中-m "新提交的信息"表示在使用no-ff的模式下，表示merge之后还带有一个提交，说明no-ff模式下，master必须要指向一个新的提交

例如：有分支dev、master，在选中master分支的前提下使用git merge --no-ff -m "merge dev" dev，此时分支的情况为

==在平时使用中，更加建议使用no-ff模式，能进行更好的区别与溯源==

合并冲突

如果出现merge冲突，需要手动解决，并进行一次《添加 + 提交》操作！！！如果不提交，是不属于成功的merge

此时的分支情况

在git中也支持提交线的可视化图标，使用git log --graph --abbrev-commit，如图所示

删除分支

删除分支也是只能在其他的分支上删除分支，比如在dev分支上就不能删除dev，必须要切到master分支上才可以

使用git branch -d <branchName>

因为创建、合并和删除分支非常快，所以鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更加的安全

删除分支2

开发过程中，可能dev分支在中途被废弃了，不需要合并到master中，直接删除dev分支，此时强制删除分支用命令git branch -D <branchName>

在终端命令中也会提醒你，这个分支未被完全合并到master分支上，如果确定你要删除，使用git branch -D <branchName>

分支策略

在实际开发中，git给我们的分支管理能力是非常重要的，这能帮我们进行多人协同开发

在git管理中，需要遵守的几个重要约定

master分支应该是非常稳定的，仅用来发布新版本，平时不能在上面修改操作
干活修改的内容都应该在dev分支上，等到某个时候迎来版本更新，再把dev分支合并到master上，在master分支上发布新版本

这样每个人都能在基于master上创建dev分支进行协同开发，每个人都有自己的分支，时不时往dev分支上合并即可

故团队协同开发的分支belike：

Bug分支

在平时开发过程中，master分支一般是稳定的版本，其他分支都是基于master分支进行完善开发，但master也有可能有bug，此时如果没能及时发现小bug，其他分支在有bug的master上基础上进行开发，这就需要我们建立bug分支对master进行bug修复

假如已经建立了分支dev，但是发现了master上有bug，那是不建议在dev分支上进行bug修复的，因为这违背了分支dev的任务，可能dev的任务是对某个模块进行更新，且已经修改了部分文件，所以我们需要再创建分支专门对master分支进行修复bug

这时候我们切回master分支后其实能看到分支dev修改的代码，虽然这只是在工作区的修改，还未提交到暂存区，但这也影响了对master的创建bug分支的步骤

比如在dev上修改了readme文件

在master分支上也能看到dev修改的内容

原因是master工作区中的代码有变动的

虽然代码只存在工作区中，但我们还是不想在master上看到dev修改的代码，且在dev分支上不影响master，可在dev分支上用git stash，将工作区中的内容进行储存。

此时的tree .git仓库一下就能看到stash分区保存在refs上

此时再返回到master分支上，就已经看不到dev修改的代码了

此时就能对master进行bug修复了，先切回master分支。然后在master上新建fix_bug分支并切换到fix_bug，可用git checkout -b fix_bug

在fix_bug上修改代码后，更新提交后就可以提交到master上了，可合并后直接提交，这里用no-ff方式提交，命令为git merge --no-ff -m "<commit message>" <devName>

此时的master分支上就是已经修复好的bug了

但dev分支上我们还是以有bug的master基础上开发的，那怎么办呢？dev分支的修改信息还存在stash上，我们需要把暂存在stash区的代码给拉回来，这是没拉回来的readme文件

在上面提到，dev已经修改了readme的内容，那这些内容都存在了stash区，且dev本地是没在的。可以用git stash list查看stash区的状态

现在拉回来的dev分支上的readme文件就显示正常了，用到命令git stash pop，这时readme文件就正常显示了

假设dev分支上已经完成开发，且已经更新最新一次提交。（add + commit）

现在要提交到master上，那怎么办呢？它还存有master原来的bug代码，==如果直接合并到==****==master====分支上，那会出现合并冲突，需要我们手动解决，手动解决是非常危险的，处理不当可能会污染master分支，变得更加不稳定。== 情况如图所示，会更加直观。

解决这个问题的一个好的建议是：最好在自己的分支上合并下master，再让master去合并dev，这样做的目的是有冲突可以在本地分支解决并进行测试，而不影响master，这样做此时的状态为：

具体操作如下，在第一步中不出意外遇到了冲突

手动修改后别忘了提交，然后切回到master分支上，再合并dev，此时master上就既有修改后的代码，也有dev上提交的新代码且不冲突了

完成后记得删分支，这是个好习惯😁

git branch -d dev、git branch -d fix_bug

推送

git push origin <远程主机名> <本地分支名>:<远程分支名>，比如git push origin test-branch:remote-test-branch，远程仓库就会出现

remote-test-branch 的新分支

拉取

Pull其实是有拉取 + 合并的操作，拉取过程中自动帮你合并了，且默认的是fast-forward模式

git pull origin <远程branchName>:<要拉取到的本地branchName>

如果远端的master与本地的分支名字一样，即是拉取到本地master分支，则可以省略:master，即git pull origin master

忽略特殊文件

在开发中，有时候有些文件不应该被提交到远端仓库，比如重要的数据库密码等配置文件，那怎么才能让git知道并自动忽略呢？

在git的工作区根目录上创建一个特殊的.gitignore文件，然后把忽略的文件名填进去，git就会自动忽略这些文件了

可以手动创建，如：touch .gitignore，也可以在创建远程仓库的时候选择

然后修改在.gitignore上写上要忽略的文件类型 / 文件后缀名，修改命令为vim，如vim .gitignore

此处我在工作区中新建了file.txt、a.io、c.io、picture.png文件

查看git状态的时发现，picture.png没有被忽略，file.txt、a.io和单独指定的c.io文件被忽略了，没有被git追踪管理，这个结果是理想的

有时候.gitignore文件太大了，记不清具体忽略了哪些文件，但是又不小心建立了被忽略的文件，手动在ignore文件内查看太费劲了，可以使用命令git check-ignore -v <被忽略的文件名>

这就能看到具体的被忽略的文件的具体位置

标签管理

标签tag，可以简单理解为对某次commit 的一次标识，相当于起了个别名。

相较于难以记住的commit id，tag可以很好的解决这个问题，当我们需要回退某个重要的版本时，直接使用标签就能很快的定位到对应的commit

这里引用hutool 工具包的GitHub仓库，能看到不同版本的tag

创建标签

在Git中打标签非常简单，首先切换到需要打标签的分支上，直接git tag <name>就可以打一个新的标签，这样的标签默认指向最新的一次提交

当然也可以指定某个提交打tag，只需在后面加上提交的id，如：git tag v0.9 f7340fd

描述标签

新建tag的同时还能对标签进行一些描述，使用git tag -a v0.8 -m "XXX" <需要指定的哪次提交id，如果没有默认指向最新的一次>

查看标签

使用git tag就能看到当前目录下有多少个标签，

如果需要看具体某一次的tag的详细描述，则需要命令git show <某一次的tag>，如：git show v0.8 / git show v1.0

删除标签

本地删除： 删除标签与删除分支的操作类似：git tag -d <tagName>，如git tag -d v0.8，可见已经删除了tagv0.8

删除远程仓库标签：

直接在远程仓库删除
在本地执行git push origin :<你要删除的标签>，注意这个标签需要先在本地进行删除，才有变更，变更之后才能push

推送标签

将标签推送同步至远程仓库

**推送单一标签：**git push origin <标签名>

**一次性推送所有标签：**git push origin --tags，就能把本地所有的标签都推送到远程仓库

‍