仅在git中存储分阶段的更改-可能吗？_do you want to commit just the staged changes of t-优快云博客

本文探讨了在Git中管理多个错误修复的策略，包括使用本地分支、重新设置基准和压缩提交，以及如何仅存储暂存的更改，避免复杂的隐藏和阶段管理。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

本文翻译自：Stashing only staged changes in git - is it possible?

Is there a way I can stash just my staged changes? 有什么办法可以隐瞒我分阶段进行的更改？ The scenario I'm having issues with is when I've worked on several bugs at a given time, and have several unstaged changes. 我遇到的情况是我在给定的时间处理了多个错误，并且进行了一些未分级的更改。 I'd like to be able to stage these files individually, create my .patch files, and stash them away until the code is approved. 我希望能够分别暂存这些文件，创建我的.patch文件，并将其存放起来，直到批准代码为止。 This way, when it's approved I can stash my entire (current) session, pop that bug and push the code. 这样，当批准时，我可以隐藏整个（当前）会话，弹出该错误并推送代码。

Am I going about this the wrong way? 我会以错误的方式处理吗？ Am I misunderstanding how git can work in other ways to simplify my process? 我是否误解了git如何以其他方式简化我的流程？

#1楼

参考：https://stackoom.com/question/zvgS/仅在git中存储分阶段的更改-可能吗

#2楼

Why don't you commit the change for a certain bug and create a patch from that commit and its predecessor? 您为什么不提交针对某个错误的更改，并根据该提交及其前身创建补丁？

# hackhackhack, fix two unrelated bugs
git add -p                   # add hunks of first bug
git commit -m 'fix bug #123' # create commit #1
git add -p                   # add hunks of second bug
git commit -m 'fix bug #321' # create commit #2

Then, to create the appropriate patches, use git format-patch : 然后，使用git format-patch创建适当git format-patch ：

git format-patch HEAD^^

This will create two files: 0001-fix-bug-123.patch and 0002-fix-bug-321.patch 这将创建两个文件： 0001-fix-bug-123.patch和0002-fix-bug-321.patch

Or you can create separate branches for each bug, so you can merge or rebase bug fixes individually, or even delete them, if they don't work out. 或者，您可以为每个错误创建单独的分支，以便可以单独合并或调整错误修复的基础，如果无法解决，则可以删除它们。

#3楼

Is it absolutely necessary to work on several bugs at once? 绝对需要一次处理多个错误吗？ And by "at once," I mean "having files edited for multiple bugs at the same time." “一次”是指“同时编辑多个错误的文件”。 Because unless you absolutely need that, I'd only work on one bug at a time in your environment. 因为除非您绝对需要，否则我一次只能在您的环境中处理一个错误。 That way you can use local branches & rebase, which I find far easier than managing a complex stash/stage. 这样，您可以使用本地分支和重新设置基准，这比管理复杂的存储/阶段要容易得多。

Let's say master is at commit B. Now work on bug #1. 假设master在提交B处。现在处理错误＃1。

git checkout -b bug1

Now you're on branch bug1. 现在，您正在使用分支bug1。 Make some changes, commit, wait for code review. 进行一些更改，提交，等待代码审查。 This is local, so you're not affecting anyone else, and it should be easy enough to make a patch from git diffs. 这是本地的，因此您不会影响其他任何人，并且应该很容易从git diffs制作补丁。

A-B < master
   \
    C < bug1

Now you're working on bug2. 现在，您正在研究bug2。 Go back to master with git checkout master . 使用git checkout master 返回 git checkout master 。 Make a new branch, git checkout -b bug2 . 新建一个分支git checkout -b bug2 。 Make changes, commit, wait for code review. 进行更改，提交，等待代码审查。

    D < bug2
   /
A-B < master
   \
    C < bug1

Let's pretend that someone else commits E & F on master while you're waiting on review. 假设您在等待审核时，其他人在master上提交了E＆F。

    D < bug2
   /
A-B-E-F < master
   \
    C < bug1

When your code has been approved, you can rebase it on to master with the following steps: 批准代码后，可以通过以下步骤将其重新构建为掌握代码的基础：

git checkout bug1
git rebase master
git checkout master
git merge bug1

This will result in the following: 这将导致以下结果：

    D < bug2
   /
A-B-E-F-C' < master, bug1

Then you can push, delete your local bug1 branch, and off you go. 然后，您可以推送，删除本地bug1分支，然后退出。 One bug at a time in your workspace, but with using local branches your repository can handle multiple bugs. 在工作区中一次只能出现一个错误，但是通过使用本地分支，您的存储库可以处理多个错误。 And this avoids a complicated stage/stash dance. 并且这避免了复杂的舞台/隐藏舞蹈。

Answer to ctote's question in the comments: 在评论中回答ctote的问题：

Well, you can go back to stashing for each bug, and only work with one bug at a time. 好了，您可以返回针对每个错误的存储，并且一次只能处理一个错误。 Atleast that saves you the staging issue. Atleast为您节省了分期问题。 But having tried this, I personally find it troublesome. 但是尝试过此之后，我个人觉得很麻烦。 Stashes are a bit messy in a git log graph. git日志图中的散乱有点混乱。 And more importantly, if you screw something up you can't revert. 更重要的是，如果您搞砸了，您将无法还原。 If you have a dirty working directory and you pop a stash, you can't "undo" that pop. 如果您的工作目录很脏并且弹出存储，则无法“撤消”该弹出窗口。 It's much harder to screw up already existing commits. 搞砸已经存在的提交要困难得多。

So git rebase -i . 所以git rebase -i 。

When you rebase one branch onto another, you can do it interactively (the -i flag). 将一个分支重新建立到另一个分支时，可以进行交互操作（-i标志）。 When you do this, you have the option to pick what you want to do with each commit. 执行此操作时，您可以选择选择每次提交要执行的操作。 Pro Git is an awesome book which is also online in HTML format, and has a nice section on rebasing & squashing: Pro Git是一本很棒的书，它也以HTML格式在线发布，并且有一个很好的章节介绍了变基和压榨：

http://git-scm.com/book/ch6-4.html http://git-scm.com/book/ch6-4.html

I'll steal their example verbatim for convenience. 为了方便起见，我将逐字窃听他们的示例。 Pretend you have the following commit history, and you want to rebase & squash bug1 onto master: 假设您具有以下提交历史记录，并且想要将bug1重新定位并压入master：

    F < bug2
   /
A-B-G-H < master
   \
    C-D-E < bug1

Here's what you will see when you type git rebase -i master bug1 这是您在键入git rebase -i master bug1

pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

To squash all commits of a branch down into a single commit, keep the first commit as "pick" and replace all subsequent "pick" entries with "squash" or simply "s". 要将分支的所有提交压缩为单个提交，请将第一个提交保留为“ pick”，然后将所有后续“ pick”条目替换为“ squash”或简单的“ s”。 You will get the opportunity to change the commit message, too. 您还将有机会更改提交消息。

pick f7f3f6d changed my name a bit
s 310154e updated README formatting and added blame
s a5f4a0d added cat-file
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit

So yeah, squashing is a bit of a pain, but I would still recommend it over heavy use of stashes. 是的，挤压有点痛苦，但是我还是建议您不要大量使用隐藏物。

#4楼

Out of your comments to Mike Monkiewicz answer I suggest to use a simpler model: Use regular development branches, but use the squash option of the merge to get a single commit in your master branch: 在对Mike Monkiewicz回答的评论中，我建议使用一个更简单的模型：使用常规开发分支，但使用merge的squash选项在您的master分支中获得单个提交：

git checkout -b bug1    # create the development branch
* hack hack hack *      # do some work
git commit
* hack hack hack *
git commit
* hack hack hack *
git commit
* hack hack hack *
git commit
git checkout master     # go back to the master branch
git merge --squash bug1 # merge the work back
git commit              # commit the merge (don't forget
                        #    to change the default commit message)
git branch -D bug1      # remove the development branch

The advantage of this procedure is that you can use the normal git work flow. 此过程的优点是您可以使用正常的git工作流程。

#5楼

Yes, It's possible with DOUBLE STASH 是的， DOUBLE STASH有可能

Stage all your files that you need to stash. 暂存您需要存放的所有文件。
Run git stash --keep-index . 运行git stash --keep-index 。 This command will create a stash with ALL of your changes ( staged and unstaged ), but will leave the staged changes in your working directory (still in state staged). 此命令将创建包含所有更改（ 暂存和未暂存 ）的存储，但是会将暂存的更改保留在工作目录中（仍处于暂存状态）。
Run git stash push -m "good stash" 运行git stash push -m "good stash"
Now your "good stash" has ONLY staged files . 现在，您的"good stash" 仅具有暂存文件 。

Now if you need unstaged files before stash, simply apply first stash ( the one created with --keep-index ) and now you can remove files you stashed to "good stash" . 现在，如果在存储之前需要未暂存的文件，只需应用第一个存储（ 使用--keep-index创建的存储），现在就可以删除"good stash"到"good stash" 。

Enjoy 请享用

#6楼

I made a script that stashes only what is currently staged and leaves everything else. 我编写了一个脚本，该脚本仅存储当前正在上演的内容，并保留其他所有内容。 This is awesome when I start making too many unrelated changes. 当我开始进行太多无关的更改时，这真棒。 Simply stage what isn't related to the desired commit and stash just that. 只需暂存与所需提交无关的内容，然后隐藏即可。

(Thanks to Bartłomiej for the starting point) （感谢Bartłomiej为起点）

#!/bin/bash

#Stash everything temporarily.  Keep staged files, discard everything else after stashing.
git stash --keep-index

#Stash everything that remains (only the staged files should remain)  This is the stash we want to keep, so give it a name.
git stash save "$1"

#Apply the original stash to get us back to where we started.
git stash apply stash@{1}

#Create a temporary patch to reverse the originally staged changes and apply it
git stash show -p | git apply -R

#Delete the temporary stash
git stash drop stash@{1}