Git Stash Usage

Git Stash Usage

Recently, when using GIT to manage project projects, there are a lot of problems, but also learned a lot about the common use of GIT skills, the following is about the use of Git stash and share.
First, a simple introduction to the use of git stash command, the detailed usage in the man document is related to the introduction, let me explain the common use.
Git stash: Backs up the contents of the current workspace, reads the content from the most recent commit, and makes the workspace guarantee consistent with the last commit. At the same time, save the current workspace content to the git stack.
Git stash pop: reads the last saved content from the Git stack and restores the workspace. Because there may be multiple stash content, the pop reads the content from the most recent stash and recovers it by using a stack to manage it.
Git stash list: Displays all the backups in the GIT stack and can use this list to decide where to recover from.
Git stash clear: Empty the git stack. Using graphical tools such as GITG, you will find out which nodes of the original stash have disappeared.
For a detailed explanation of git stash, for the occasion, here's a description:

When using git, we often use branch to solve task switching problems, for example, we tend to build a branch of our own to modify and debug the code, if others or ourselves found that there is a bug that has to be modified on the original branch, we tend to commit the completion of half of the code commit to the local repository, Then switch the branch to modify the bug, change it and then switch back. In this case, the log will often have a large number of unnecessary records. In fact, if we don't want to commit half or imperfect code, but have to modify an urgent bug, then use ' git stash ' to push the code you are currently not committing to the local (and server) into the git stack, when your work interval and the last commit content is exactly the same , so you can safely fix the bug, wait until the bug is completed, submit to the server, and then use ' git stash apply ' to apply the previous half of the work back. Maybe some people will say, can I put the uncommitted code on the stack several times? The answer is yes. When you use the ' git stash ' command multiple times, your stack will be filled with uncommitted code, and you'll be confused about which version to apply back, ' git stash list ' command can print the current git stack information, you just need to find the corresponding version number, such as using ' Git Stash apply [email protected]{1} ' can take your designated version number as [email protected]{1} To remove the work, when you apply all the stacks back, you can use ' git stash clear ' to empty the stack.
Here by the way git Format-patch-n, n is a specific number, such as ' git format-patch-1 ' will then generate a corresponding patch according to log, if ' git format-patch-2 ' then generate 2 patches, of course, before There are at least two records on your log.

Read the information above, you can know the use of the situation: the current workspace content has been modified, but not completed. Then the boss came, saying that the previous branch has a bug, need to repair immediately. But I do not want to submit the current changes, because the changes are not completed. However, without submitting the words, there is no way to checkout to the previous branch. At this point, git stash is the equivalent of a backup workspace. Then in the checkout past changes, you can achieve the preservation of the current workspace, and timely recovery of the role.

Below, I will share with you a question I encountered during my use:

First, after Git stash, the submission diagram looks like this:

You can see that develop and newdevelop are on the same branch, Because Branch Newdevelop is developed on the basis of the develop branch. Want to add a new feature, so open the Newdevelop branch, and then add something to it, add the attribute, the code. At this time the content of the work has changed, but develop and newdevelop are all pointing to the same commit, because the newdevelop above also has the wood to submit.
This time, boss came, said develop above a bug, quickly change, the work at hand first put, stable version can not be defective. No way, is currently engaged in Newdevelop on the high, git stash a bit. So you see two nodes above, red and one above. Is the result after stash, notice is on newdevelop above the stash.

As mentioned earlier, stash will stage the current workspace content and then keep the workspace content the same as the last commit, when the content is 8a32 the one submitted above. View the appropriate information from the terminal as follows:

confirms the signature, Newdevelop is modified, modified, and then stash, the workspace is the most recent commit, at which time Newdevelop and develop are the same, So again git status View found, all the same, nothing to commit.

and then after the stash is finished, fix the bug. To do this, go back to the develop branch to fix it, then commit, and the completed commit diagram looks like this:

As can be seen from the way, Newdevelop is still below, because the point is the old 8a32 commit. New develop due to bug fixes, a new commit is generated.


Then after fixing the bug on develop, go back to Newdevelop above a new feature of the continuation code, at this time checkout go back, no god horse content can be submitted, because all exist stash, there is no modification. Such as.

So, restore the workspace content. So git stash pop (note here because only stash once so use pop, specific how much you store, to restore which one to own clear, otherwise will be wrong!) ）

After recovery, you can see that at this point, git status will find that the file has been modified, indicating recovery. Then continue coding, submit a stable new feature version, for example, the resulting new commit is 0906.
Then look at the submission diagram, you will find that after the stash pop, the corresponding stored stash is emptied out, the submission diagram, Newdevelop above a new commit. and above the develop. The develop of the branch is the red, which is the commit that fixes the bug earlier.


To sum up:
The operation is simple, but the mind needs to be clear. In which branch to fix the bug, where to stage the content, and then repair the place to submit, and then to which branch to restore the workspace, all need to be aware of, otherwise, it is easy to cause the submission diagram confusion. Only by figuring out the workflow, it is not easy to make mistakes, to ensure high efficiency.
The last sentence: Git is an artifact, it depends on how you harness it.

Git Stash Usage