只能在Git中进行阶段性的变化 – 这有可能吗？
有没有一种方法可以隐藏我的阶段性变化？ 我遇到的情况是当我在给定时间处理了几个错误，并且有几个未分离的更改。 我希望能够单独演示这些文件，创build我的.patch文件，并将其隐藏起来，直到代码被批准。 这样，当它被批准时，我可以隐藏我的整个（当前）会话，popup错误并推送代码。
我是否以错误的方式去做这件事？ 我误解了git如何以其他方式工作来简化我的过程？
是的，这是真的有可能，相信与否， DOUBLE STASH ：
- 将所有需要存储的文件分级。
- 运行
git stash --keep-index。 这个命令将会创build一个包含所有更改（ 暂存和非暂存 ）的存储，但会将暂存的更改留在工作目录中（仍处于暂存状态）。 - 运行
git stash save "good stash" - 现在你的
"good stash"只有上演档案 。
现在，如果您在存储之前需要非暂存的文件，只需应用第一个存储（ 使用--keep-index创build的文件），现在可以删除您"good stash"文件以"good stash" 。
请享用
我制作了一个脚本，只保存目前正在播放的内容，并保留其他所有内容。 当我开始做太多无关的改变时，这真棒。 简单地说明与所期望的提交无关的东西，然后藏起来。
（感谢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}
你为什么不对某个bug进行修改，并从该修改及其前身创build补丁？
# 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
然后，要创build适当的修补程序，请使用git format-patch ：
git format-patch HEAD^^
这将创build两个文件： 0001-fix-bug-123.patch和0002-fix-bug-321.patch
或者，您可以为每个错误创build单独的分支，这样您可以单独合并或重新绑定错误修复，甚至可以删除它们，如果它们不能解决的话。
有了最新的git，你可以使用--patch选项
git stash save --patch
而git会询问你的文件中的每一个改变添加或不存储。 你只是回答y或n
是否有必要同时处理多个错误？ 而“立即”，我的意思是“同时编辑多个文件的文件”。 因为除非你绝对需要，否则我只能在你的环境中一次处理一个bug。 这样你就可以使用本地分支和rebase，这比pipe理一个复杂的存储/ stage更容易。
假设主人在提交B.现在工作在bug＃1。
git checkout -b bug1
现在你在分支bug1。 进行一些更改，提交，等待代码审查。 这是本地的，所以你不会影响其他任何人，而且应该很容易从git diffs中创build一个补丁。
AB < master \ C < bug1
现在你正在研究bug2。 使用git checkout master 回到 git checkout master 。 做一个新的分支， git checkout -b bug2 。 进行更改，提交，等待代码审查。
D < bug2 / AB < master \ C < bug1
让我们假装有人在等待审核时对E＆F提交主文件。
D < bug2 / ABEF < master \ C < bug1
当你的代码被批准后，你可以重新绑定它来掌握以下步骤：
git checkout bug1 git rebase master git checkout master git merge bug1
这将导致以下结果：
D < bug2 / ABEFC' < master, bug1
然后你可以推，删除你当地的bug1分支，然后离开你。 一次在你的工作区的一个错误，但使用本地分支你的仓库可以处理多个错误。 这避免了一个复杂的舞台/藏舞。
在评论中回答ctote的问题：
那么，你可以回头去隐藏每个bug，而且一次只能处理一个bug。 至less可以节省您的分期问题。 但是试过这个，我个人觉得很麻烦。 git log图中的stashes有点乱。 更重要的是，如果你搞砸了，你就无法恢复。 如果你有一个肮脏的工作目录，你popup藏匿，你不能“撤消”popup。 搞砸现有的提交要困难得多。
所以git rebase -i 。
当你将一个分支转换为另一个分支时，你可以交互地执行（-i标志）。 当你这样做时，你可以select你想要做的每个提交。 Pro Git是一本非常棒的书，它也是HTML格式的在线书籍，并且有一个关于重新镶嵌和压扁的很好的部分：
http://git-scm.com/book/ch6-4.html
为了方便起见，我会逐字地盗取他们的例子。 假装你有以下的提交历史logging，并且想要将bug1压缩到master上：
F < bug2 / ABGH < master \ CDE < bug1
当你inputgit 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. #
要将一个分支的所有提交压缩成一个单独的提交，保持第一个提交为“pick”，并用“squash”或简单的“s”replace所有随后的“pick”条目。 您也将有机会更改提交消息。
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
所以是的，挤压是有点痛苦，但我仍然会推荐它在大量使用的存储。
出于你的意见Mike Monkiewicz答案我build议使用一个更简单的模型：使用常规的开发分支，但使用合并的压扁选项在主分支中获得一个单一的提交：
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
这个过程的好处是你可以使用正常的git工作stream程。
太复杂。 我宁愿创build一个分支，并在那里进行阶段性的改变。
注意：如果只有部分文件被暂存，那么切换回原来的分支（假设我们可以继续使用未暂存的文件）可能会变得很复杂。 （我的解决scheme是提交这些也樱桃select到根分支。）
