git stash的原理是什么，临时文件被存在哪里？

Git stash 的核心思想是将你当前工作目录中尚未提交的修改（包括已暂存和未暂存的文件）暂时“打包”起来，恢复工作目录到上一个提交的状态，以便你能够切换到其他分支进行操作，或者执行一些需要干净工作目录的操作。当你需要这些修改时，再将它们“解压”回来。

想象一下，你正在辛勤地修改代码，可能已经修改了好几个文件，但这些修改还没有准备好提交。突然，你接到一个紧急任务，需要立即切换到另一个分支去修复一个 bug。这时，如果你直接切换分支，Git 会提示你工作目录中有未提交的修改，并可能阻止你切换，或者将你的修改带到新分支，这往往不是我们想要的。Git stash 就是为了解决这个场景而生的。

当你执行 `git stash` 命令时，Git 实际上做了几件事情：

首先，它会创建一个新的提交对象，这个提交对象代表了你当前工作目录中所有未提交的修改。这个新的提交对象并不是一个常规的提交，它不会被包含在你的分支历史中，它被存放在一个特殊的地方。Git 会将你已暂存的修改（`git add` 过的）和未暂存的修改（直接修改但未 add 的）分开处理。

然后，Git 会将你工作目录中所有被 stash 的修改从你的工作目录中移除，并将你的工作目录恢复到你当前分支的 HEAD（也就是最后一个提交）的状态。这样，你的工作目录就变得“干净”了，可以让你自由地进行分支切换、拉取更新等操作。

那么，这些被 stash 的修改到底存在哪里呢？它们被存放在 Git 的一个叫做 `reflog` 的东西里，更具体地说，是存放在 `refs/stash` 这个引用下。你可以把它理解成一个临时的存储区域，专门用来存放你 stash 起来的更改。每次你 stash 一个新的更改，Git 都会在这个区域创建一个新的“stash 记录”，并为它分配一个唯一的标识符，通常以 `stash@{n}` 的形式表示，其中 `n` 是一个数字，表示你 stash 的顺序（`stash@{0}` 是最新的）。

你可以通过 `git stash list` 命令来查看你 stash 过的所有记录。每条记录都包含了一些信息，告诉你 stash 的是哪个分支上的哪些更改。

当你想要恢复这些修改时，可以使用 `git stash pop` 或者 `git stash apply` 命令。

`git stash pop` 会将最新的 stash 记录应用到你当前的工作目录，并且将这条记录从 stash 列表中移除。
`git stash apply` 也会将最新的 stash 记录应用到你当前的工作目录，但它 不会 将这条记录从 stash 列表中移除。这意味着你可以多次应用同一个 stash 记录。

如果你的 stash 记录有冲突（例如，你 stash 了某个文件的修改，然后又在另一个分支上对同一个文件做了不同的修改，再切换回来应用 stash 时，Git 不知道该保留哪个修改），Git 会尝试应用，如果不行，它会告诉你冲突在哪里，然后你需要手动解决这些冲突，就像解决普通 Git 合并冲突一样。

总而言之，Git stash 就像一个临时的“收纳箱”，让你可以在不丢失工作进度的情况下，快速清理你的工作目录，处理其他紧急事务。它通过创建临时的提交对象并存放在 `refs/stash` 引用下，然后清理工作目录来实现这一功能。

网友意见

你可以认为stash就是一个特殊的branch。

类似的话题

• 

  git stash的原理是什么，临时文件被存在哪里？

  

  Git stash 的核心思想是将你当前工作目录中尚未提交的修改（包括已暂存和未暂存的文件）暂时“打包”起来，恢复工作目录到上一个提交的状态，以便你能够切换到其他分支进行操作，或者执行一些需要干净工作目录的操作。当你需要这些修改时，再将它们“解压”回来。想象一下，你正在辛勤地修改代码，可能已经修改了.............
• 

  Git 有什么奇技淫巧？

  

  说起 Git，很多人脑子里第一个冒出来的就是 `git add`, `git commit`, `git push`, `git pull` 这些基本操作。但 Git 远不止于此，它就像一个功能丰富的瑞士军刀，隐藏着许多能让你的开发流程如丝般顺滑的“黑魔法”。今天，咱们就来聊聊那些藏在角落里的 Gi.............
• 

  git本身是客户端还是服务端？

  

  在 Git 的世界里，“客户端”和“服务端”的概念，就像一把双刃剑，用得不恰当，容易让人一头雾水。但如果我们仔细剖析，就会发现 Git 本身的核心，其实更偏向于一个“强大的本地工作站”，而我们通常所说的“服务端”，更多的是指托管 Git 仓库的远程服务器，它扮演的是一个集中协调和共享的角色。咱们先别.............
• 

  Git 有哪些缺点？

  

  Git 就像一枚硬币，有光明的一面，也有不那么光彩的一面。对于很多开发者来说，它已经成为一种几乎不可替代的工具，但要说它完美无缺，那可就有点言过其实了。首先，Git 的学习曲线确实比较陡峭。尤其对于初学者来说，那些诸如 `rebase`、`cherrypick`、`reflog` 这样的命令，以及背.............
• 

  Git还差什么？版本控制中还有什么痛点？要是做一个Git++(幻想一下)可以有些什么？

  

  Git，这个我们日常开发离不开的工具，确实已经足够强大，但要说它一点瑕疵都没有，那也未必。回想一下，我们在使用Git的过程中，有没有过一些让人抓狂的时刻？比如，当你的项目历史变得无比复杂，充斥着各种小提交、合并冲突的痕迹，想要理清楚某个功能的演进过程，简直像是在一本写满涂鸦和修改痕迹的书里找寻一段清.............
• 

  Git算不算程序员的必备技能？

  

  说Git算不算程序员的必备技能？ 我觉得，如果一个程序员想要在这个行业里走得更远，并且能够和别人顺畅、高效地协作，那么Git几乎是绕不开的。想象一下，你一个人开发项目，文件改来改去，突然发现某个改动不对劲，想要回退到上一个状态，如果没有Git，你可能只能手动备份，或者祈祷自己记得所有改动。但一旦项目.............
• 

  git合并分支，为什么会比svn容易？

  

  这事儿说起来，得从 Git 和 SVN 的底层设计思路说起。SVN 呢，它是一个集中式版本控制系统。你可以想象成一个大公司，所有人都得对着一个中央服务器来提交代码，提交的时候，你的代码直接替换了服务器上的版本，就像你把你的工作成果直接塞进老板办公室的文件柜里一样。在 SVN 里，合并分支就像是让你的.............
• 

  git是Linus一个人开发出来的吗？

  

  很多人可能只知道Linus Torvalds是Linux的创造者，也顺理成章地认为Git也是他一个人从零开始捣鼓出来的。这不无道理，因为Linus在Git的早期开发中确实扮演了绝对核心的角色，可以说没有他，就没有Git的今天。事情是这样的，在2000年代初期，Linux内核的开发已经相当庞大了。全球.............
• 

  Git 为什么成为主流源代码管理选择？

  

  Git之所以能成为当下主流的源代码管理工具，绝非偶然，而是它在设计理念、功能特性以及社区生态等多方面因素共同作用的结果。首先，我们得回顾一下它诞生之前，主流的源代码管理方式。那时候，像CVS、SVN这样的集中式版本控制系统（CVCS）是市场上的主要玩家。它们的核心模式是有一个中央服务器，所有开发者都.............
• 

  git怎么控制成员的权限？

  

  在Git的世界里，管理团队成员对代码库的访问权限，并非Git本身直接提供“用户管理”和“角色分配”这样中心化的系统。Git是一个分布式的版本控制系统，它的核心功能在于跟踪代码变更，而不是在一个统一的服务器上管控谁能做什么。那么，我们是怎么通过Git来控制成员权限的呢？这其实是 结合了Git的服务器端.............
• 

  用 Git 管理源代码的优势有哪些？

  

  Git 是当前最流行且功能强大的分布式版本控制系统（DVCS），它在软件开发中扮演着核心角色。使用 Git 管理源代码具有以下显著优势，这些优势不仅提升了开发效率，也保障了代码的可维护性和团队协作的可靠性： 1. 分布式版本控制（Distributed Version Control） 本地仓库独立.............
• 

  用 Git 一定要用命令行吗？用命令行一定高贵吗？

  

  说起 Git，很多人脑海里第一个浮现的词可能就是“命令行”。是不是觉得那些敲击键盘、一行行命令的画面自带一种高冷范儿？就像武侠小说里，高手过招，只用招式，没有花里胡哨的道具。那么，问题来了：用 Git 真的就非命令行不可吗？用命令行就一定“高贵”吗？咱就掰开了揉碎了聊聊。Git 和命令行：不得不说的.............
• 

  如何理解 Git 的分布式？

  

  要理解 Git 的分布式，我们首先要理解 Git 不是一个集中式的版本控制系统，而是分布式的。这是 Git 最核心、最革命性的特性之一。下面我将从多个角度详细阐述 Git 的分布式概念： 1. 与集中式版本控制系统（CVCS）的对比在深入 Git 的分布式之前，我们先回顾一下传统的集中式版本控制系统.............
• 

  怎样让git在linux始终显示status?

  

  要让 `git status` 在 Linux 环境下始终显示状态，可以通过以下几种方法进行配置和调整。以下步骤详细说明如何确保每次运行 `git status` 时都显示完整的状态信息： 1. 使用 `git status fullstatus` 显示所有文件状态默认情况下，`git status.............
• 

  IDE 有必要集成 Git 吗？

  

  集成 Git 是现代 IDE（集成开发环境）的重要功能之一，其必要性取决于开发场景、团队协作需求以及项目规模。以下从多个维度详细分析 Git 集成的必要性、优势和适用场景： 一、Git 集成的必要性1. 协作开发的核心工具 团队协作：在多人协作的项目中，Git 是唯一可行的版本控制系统。没有 .............
• 

  如何写好 Git commit log?

  

  写好 Git commit log，绝不是一件可有可无的小事。它更像是一门艺术，一种与未来自己和团队沟通的技艺。一个清晰、有条理的 commit log，能够让你在回顾历史时事半功倍，也能让你的团队成员更轻松地理解你的工作，从而提高整个项目的效率和可维护性。我个人在 Git commit log 的.............
• 

  如何学习好 Git ？

  

  磨砺你的代码操控术：一份实战向的 Git 学习指南想要在开发的世界里如鱼得水，Git 绝对是你必须掌握的核心技能。它不仅仅是一个版本控制系统，更是一种强大的协作工具，是保障你代码安全、项目有序推进的基石。别被那些“高深莫测”的 Git 命令吓到，其实，掌握 Git 的精髓，就像学习骑自行车一样，一开.............
• 

  如何克服解决 Git 冲突的恐惧症？

  

  别再让“冲突”二字束缚你：攻克 Git 冲突恐惧症的实战指南我知道，当你看到屏幕上那醒目的 `<<<<<<< HEAD`，`=======`，`>>>>>>> [branchname]` 时，心里都会咯噔一下。仿佛面前出现了一道难以逾越的鸿沟，脑海里瞬间涌现出无数个“我把代码弄坏了怎么办？”、“这要.............
• 

  如何删除Git里来自pull request的commit中包含的个人敏感信息？

  

  你有没有遇到过这种情况：兴冲冲地合并了一个 `pull request`，却在提交历史里发现了一堆不该出现的敏感信息，比如密码、API密钥或者其他私密数据？这时候怎么办？别急，今天咱们就来聊聊如何清理这些“不速之客”，让你的 Git 历史重新变得干净整洁。为什么会出现这种情况？通常，这些敏感信息出现.............
• 

  如何看待 Git 的 Windows 安装程序称 Vim「很难用」？

  

  Git for Windows 安装程序里提到 Vim“很难用”，这背后其实透露出几个很有意思的观点，而且这事的“梗”也挺深的。首先，我们得认识到，Git for Windows 的安装程序，包括它附带的很多工具，都是为了尽可能地降低 Git 的使用门槛，让更多人能够顺利上手。Vim 的定位是什么？.............