Git storage is a very common function in git.

You’ve all had the experience when you’re co-developing, where you’re halfway through a feature, and for some reason you want to checkout to checkout code on another branch or do some work. But if we perform checkout directly, Git forbids us from doing so.

Git rejected our checkout command after we executed the checkout command, prompting us that some changes to the file would be overwritten.


What should you do at this point? The best way, of course, is to commit your changes using git commit. The problem is that sometimes we don’t want to submit code that hasn’t been rigorously tested, or test features that we’ve developed on the fly, etc. A commit is not appropriate in this case, because even if it is committed, the commit will later be revoked before the push. But if you’re not careful, it can lead to tragedy.

Git provides a solution to this problem with the Stash feature.

Storage changes

Git Stash stores all changes that haven’t been committed locally. Then we added a line of -test Stash to one of our previous articles.

Let’s do git diff and see the change.


Then we execute the Git stash and find that our Git directory is back to its unchanged state. Git diff will not see any changes.


This is because Git temporarily stores changes that we haven’t committed locally, making it easier for us to checkout or do something else without causing conflicts or other impacts.

Application changes

So what should we do when we want to restore the content temporarily saved?

There is a way to do this. Just use git Stash apply or git Stash pop to restore the stash. But there’s a problem here, and that’s the difference between Stash apply and pop.

There’s an implementation mechanism inside stash, which is actually implemented through the stack. Pop is a very specific word for stack. It just means pop. That is, if we use pop, when we pop, the record will be removed from the stack. If you use Apply, the record is not removed from the stack and remains.

I usually use POP more, but pop has its drawbacks, such as the fact that pop doesn’t have a way to select the app’s record. We can use the Git Stash list to look at the records already in the current stack.


If we use git stash pop, the default is the top stack record of the application, stash@{0}. But if we use stash Apply, we have the freedom to choose which records we want to apply. For example, if we wanted to apply the last record, we could do this:

git stash apply stash@{2}

Copy the code

There are a few details about the changes to the app store. First, the store and modify branches can be different. We can store it in one branch and then switch to another branch for application. And if we modify the same content before applying it, we can also cause merge conflicts.

The other is that when we apply the store, we will find that the files we added before are back to the unstored state. If we want to go back to the state where the file was temporarily stored, we can do this using the index option.

git stash apply --index

Copy the code

For unwanted stash records, we can do a Git Stash drop to remove them.

Other skills

In addition to the above functionality, git Stash has several other uses.

For example, the –keep-index option, without this option, when we use git stash, will stash everything that is not committed. But sometimes we don’t want that, we want it to just hold what we haven’t added to the staging area. At this point we can implement it with this parameter.

The other argument is -u or –include-untracked, as we can tell from the name. This means that newly created files that are not yet managed by Git are also stored under stash.

In addition, patch functions are also commonly used. Patch, which we covered in the last article on interactive commands, allows you to narrow changes that Git targets to code rather than files. Interactively tell us which code-level changes need to be stored, just as we did in the previous article. If you have forgotten, you can find the last article at the end of the article to review.


The last feature is to create a new branch from the repository. Sometimes we store the code first and then work on it later. At this point, if we go back to the previous changes, there will be a conflict. At this point we can run the Git Stash branch to create a new branch on which to apply our commit.

git stash branch applystash

Copy the code

After successful application, Git will automatically discard the corresponding Stash record, which is very convenient, but I have never used it personally, because I have not encountered such a complex situation in my actual work.

That’s all for today’s article. I sincerely wish you all a fruitful day. If you still like today’s content, please join us in a three-way support.

Original link, ask a concern