How can I stash only one of multiple changed files on my branch?
相关问题
- Why does recursive submodule update from github fa
- Extended message for commit via Visual Studio Code
- Emacs shell: save commit message
- Can I organize Git submodules in a flat hierarchy?
- Upload file > 25 MB on Github
相关文章
- 请教Git如何克隆本地库?
- GitHub:Enterprise post-receive hook
- Git Clone Fails: Server Certificate Verification F
- SSIS solution on GIT?
- Is there a version control system abstraction for
- ssh: Could not resolve hostname git: Name or servi
- Cannot commit changes with gitextensions
- git: retry if http request failed
Solution
Local changes:
To create a stash "my_stash" with only the changes on file_C:
Done.
Explanation
You can use git status between the steps to see what is going on.
Warning
As noted in the comments, this puts everything into the stash, both staged and unstaged. The --keep-index just leaves the index alone after the stash is done. This can cause merge conflicts when you later pop the stash.
This will stash everything that you haven't previously added. Just
git add
the things you want to keep, then run it.For example, if you want to split an old commit into more than one changeset, you can use this procedure:
git rebase -i <last good commit>
edit
.git reset HEAD^
git add <files you want to keep in this change>
git stash --keep-index
git add
any changes.git commit
git stash pop
git rebase --continue
In this situation I
git add -p
(interactive),git commit -m blah
and then stash what's left if necessary.Every answer here is so complicated...
What about this to "stash":
This to pop the file change back:
Exact same behavior as stashing one file and popping it back in.
Another way to do this:
I came up with this after I (once again) came to this page and didn't like the first two answers (the first answer just doesn't answer the question and I didn't quite like working with the
-p
interactive mode).The idea is the same as what @VonC suggested using files outside the repository, you save the changes you want somewhere, remove the changes you don't want in your stash, and then re-apply the changes you moved out of the way. However, I used the git stash as the "somewhere" (and as a result, there's one extra step at the end: removing the cahnges you put in the stash, because you moved these out of the way as well).
Update (2/14/2015) - I've rewritten the script a bit, to better handle the case of conflicts, which should now be presented as unmerged conflicts rather than .rej files.
I often find it more intuitive to do the inverse of @bukzor's approach. That is, to stage some changes, and then stash only those staged changes.
Unfortunately, git doesn't offer a git stash --only-index or similar, so I whipped up a script to do this.
You can save the above script as
git-stash-index
somewhere on your path, and can then invoke it as git stash-indexNow the stash contains a new entry that only contains the changes you had staged, and your working tree still contains any unstaged changes.
In some cases, the working tree changes may depend on the index changes, so when you stash the index changes, the working tree changes have a conflict. In this case, you'll get the usual unmerged conflicts that you can resolve with git merge/git mergetool/etc.