This article shared practical commands that I have practiced in my development work. These can greatly improve work efficiency and solve many difficult scenarios. The following will introduce the commands and list the application scenarios for hand-touch teaching, so that students can learn them after reading them.
Official explanation: When you want to record the current status of working directory and index, but want to return to a clean working directory, please use git stash. This command will save local modifications and restore the working directory to match the submitted file header.
The Stash command can save uncommitted code and make your working directory clean.
I guess you must be thinking: why clean?
Application scenario: one day you are developing new requirements in the feature branch, and suddenly the product manager comes over and says that there are bugs on the line that must be fixed immediately. At this point, your function is half developed, so you want to cut to the main branch in a hurry, and then you will see the following error:
Because there are files that have been changed at present, you need to submit commit to keep the workspace clean before splitting branches. Due to the emergency, the submission was made in a hurry, and the submission information was also written in "temporary code", so the branch submission record left a black history ... (true story, I have seen this submission)
Stash won't be so embarrassed if you learn it. You just need to:
It's that simple, and the code is saved.
When you fix the online problem and switch back to the feature branch, you only need to restore the code:
When there are multiple stores, you can specify the operation store. First, use the stash list to list all records:
Apply the second record:
Prevalence and decline are the same.
Hidden code
Fill in comments, or enter directly without filling in.
You can see the saved stores in the Store menu.
Click the small arrow next to the stash record first, and then click apply or pop to restore the stash.
Do not touch the index file or working tree at all (but reset the title to in all modes). This will change all your changed files to "Changes to Commit".
Rollback your submission and put the submitted modifications back into the temporary storage area.
Generally, when we use the reset command, we will mention git reset-hard more, which can force the submission of records back to a node. And the function of git reset-soft is just as its name implies. -Soft (soft) will not only backtrack the node, but also keep the modified content of the node.
Backtracking nodes, why do you want to keep the modified content?
Application scenario 1: Sometimes you accidentally submit something you shouldn't have submitted. At this time, if you want to change it back, you can only commit it again and add a "black history."
Application Scenario 2: Standardized teams generally require clear responsibilities and fine granularity for the content submitted, which is convenient for subsequent problem investigation. It is irregular to submit two modifications with different functions together. This time, my hand slipped again and I made it once.
After learning reset-soft, you only need to:
Resetting softness is equivalent to regret medicine, giving you a chance to turn over a new leaf. For the above scenario, you can modify it again and resubmit it to keep a clean submission record.
The above is a submission that has not been pushed yet. You can also use this command for committed that has been pushed, but when you push it again, because there is a difference between the remote branch and the local branch, you need to forcibly push git push -f to overwrite reset committed.
It should also be noted that when reset-soft specifies the submission number, all modifications from the submission to the latest submission will be restored, not just the submission.
For example:
The submission records are c, b and a.
Reset to a.
At this time, the head arrived at A, and the changes of B and C all returned to the temporary storage area.
Given one or more existing submissions, apply the changes introduced by each submission and record a new submission for each submission. This requires that your working tree is clean (no changes have been submitted from scratch).
Copy the committed commit and apply the new commit to the branch.
The submission has been submitted. Why do you need to copy a new one?
Application scenario 1: Sometimes, some optimization requirements of the version are under development, and a developed requirement may be temporarily put on, or the requirement to be developed is stuck online for some reason. At this time, you need to take out the commit and deal with it separately.
Application scenario 2: Sometimes the code records in the development branch are polluted, which leads to problems when the development branch is merged into the online branch. At this time, you need to pull a clean development branch, and then copy the commit from the old development branch to the new branch.
Copy a single
Now there is a function branch, and the submission record is as follows:
You need to copy B to another branch, copy commitHash first, and then cut to the master branch.
The latest record of the current master node is a. Use cherry-pick to apply b to the current branch.
Read the latest log when you are finished. B has been applied to the master server as the latest submission. You can see that the commitHash is different from the previous one, but the submission time is still before. Wechat search wechat official account: java back-end programming, reply: Java gets information.
Repetition multiple
The above is a copy of a single submission. Let's look at how to pick multiple commit operations.
The above command applies commit 1 and commit2 to the current branch.
The above command applies all commits in the range of commit 1 to commit2 to the current branch (including commit 1 and commit2), and commit 1 is the earliest commit.
When cherry-pick has multiple submissions, you may encounter code conflicts, and then cherry-pick will stop and let the user decide how to proceed. Let's see how to solve this situation.
It is still a characteristic branch, and now you need to copy C, D and E to the main branch. Write down the commitHash of starting point c and ending point e first.
Cut to the main branch and use the cherry stone in the middle. You can see that C was copied successfully. When I got to D, I found a code conflict, and cherry-pick was interrupted. At this time, it is necessary to resolve the code conflict and resubmit it to the temporary storage area.
Then use cherry-pick-continue to let cherry-pick continue. Finally, copy the E and the whole process will be completed.
The above is a complete process, but sometimes it may be necessary to give up or quit the process after code conflicts:
Go back to the way you were before the operation, as if nothing had happened.
Don't go back to the way you were before the operation. That is, keep the submissions that have been successfully selected and exit the selection process.
Given one or more existing submissions, restore the changes introduced by related submissions and record some new submissions of these changes. This requires that your work tree is clean (unchanged from the beginning).
Restore the existing submission, restore the submitted content, and generate a restore record.
Application scenario: One day, the test suddenly tells you that there is something wrong with the function you developed online, and you need to cancel it immediately, otherwise it will affect the use of the system. At this time, you may think of using reset to roll back, but if you look at the latest submission on the branch and the code of other colleagues, using reset will also withdraw this part of the code. Because the situation is urgent and you can't think of a good way, you still use reset willfully, and then let your colleagues combine his code (colleagues want to hit people when they listen), so your technical image has plummeted in the eyes of colleagues.
Reply to ordinary submission
After learning revert, you can immediately save this embarrassing situation.
Now the master record is as follows:
Revert gave up his own submission.
Because revert will generate a new submission record, you will be asked to edit the submission information at this time. When editing is finished, wq will save and exit.
Let's look at the latest log and generate a recovery record. Although your previous submission record will still be kept, the code content you modified has been withdrawn.
There is another type of merge submission in git's submission record. If you want to revert to merge submission, it will be used a little differently.
There is now a merge commit in the main branch.
Using the same revert method just now, you will find that the command line reported an error. Why is this happening? It is explained in the official documents.
It is usually impossible to undo a merger because you don't know which side of the merger should be regarded as the main line. This option specifies the parent number of the main line (starting from 1) and allows revert to reverse the changes from the specified parent number.
My understanding is that merge submission is the intersection of two branches, and git doesn't know which branch needs to be revoked. It needs to add the parameter -m to specify the main branch, keep the code of the main branch, and the other branch will be revoked.
The -m should be followed by a initials to identify the "main line". Generally, 1 is used to reserve the main branch code.
Still in the above scenario, after the main branch revert is merged and submitted, then the bug is fixed in the feature branch and merged into the main branch, and you will find that the contents modified by revert have not been merged again.
Because after using revert, the submission of the feature branch will still remain in the record of the main branch. When you merge it again, git judges that there is the same commitHash, and ignores the related committed modifications.
At this time, it is a bit embarrassing to restore, merge and submit before restoring. Next let's look at the operation.
Now the master's record is like this.
If you use revert again, the content previously modified by revert will be restored.
This command manages the information recorded in re-recording.
If reset-soft is a regret medicine, then reflog is a powerful regret medicine. It records all the submission operation records, which is convenient to retrieve the records after the wrong operation.
Application scenario: One day, you are dazzled and find that you have submitted the code in someone else's branch and pushed it to a remote branch. At this time, because the branch is only submitted by you recently, you want to use reset-hard. As a result, you accidentally misremembered the commitHash, reset too much, and your colleague's commit was lost. No way, reset-hard was forced to retreat, and commitHash could not be found, so I had to ask my colleague to push it again from the local branch (colleague's fist suddenly hardened, and it was you again). As a result, your technical image plummeted.
The branch record is as above, and you want to reset it to B.
There are too many reset misoperation, B is gone, and the latest one is only A.
At this point, use git reflog to check the history and write down the commitHash of the submission error.
Reset again, and you will find that B is back.
For me, a fan who likes to input commands rather than graphical tools, setting short commands can improve efficiency. Here are two ways to set short commands.
Open the global configuration file
Write content
This paper mainly shares five Git commands that are practical in development, and the method of setting short commands.
Some application scenarios listed in this paper are not appropriate, just for students' understanding. The most important thing is to understand what the command is, so that learning and use can exert the greatest effect.
Ok, that's all for today's sharing. See you next time ~