Source: juejin.cn/post/7096288358460031013
Foreword
Using Git for code version management has long been a necessary skill for development engineers today. However, most engineers still only know how to save, pull, and push the most basic tasks. They are helpless when encountering some commit management problems, or solve them in some inelegant ways.
This article shares 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 commands, list application scenarios, and teach hands-on use so that students can learn it immediately after reading it.
stash
Description
Official explanation: Use git stash when you want to record the current state of the working directory and index, but want to return to a clean working directory. This command will save local modifications and restore the working directory to match the head commit.
The stash command can save uncommitted code and make your working directory clean.
Application scenarios
I guess you must be thinking: Why do you want to get clean?
Application scenario: One day you are developing new requirements in the feature branch, and suddenly the product manager comes over and says there is a bug online and must be fixed immediately. At this time, your function is halfway developed, so you rush to switch to the master branch, and then you will see the following error:
Because there are currently files that have been changed, you need to submit a commit to keep the workspace clean before you can cut the branch. Due to the emergency, you have no choice but to commit in a hurry, and the commit information casually writes “temporary code”, so the commit record of the branch leaves a black history… (A real person has seen this kind of commit)
Command usage
If you learn stash, you don’t have to be so embarrassed. All you need is:
git stash
It’s that simple, the code is saved.
After you fix the online problem, switch back to the feature branch. If you want to restore the code, you only need to:
git stash apply
Related commands
# Save currently uncommitted code git stash # Save the currently uncommitted code and add comments git stash save "content of remarks" # List all records of stash git stash list # Delete all records of stash git stash clear #Apply the latest stash git stash apply #Apply the latest stash and then delete the record git stash pop # Delete the latest stash git stash drop
When there are multiple stashes, you can specify the stash operation. First, use stash list to list all records:
$ git stash list
stash@{0}: WIP on ...
stash@{1}: WIP on ...
stash@{2}: On ...
Apply the second record:
$ git stash apply stash@{1}
The same goes for pop and drop.
vscode integration
stash code
Fill in the remark content, or enter directly without filling it in
The saved stash can be seen in the STASHES menu
First click the small arrow next to the stash record, then click apply or pop to restore stash.
reset –soft
Description
Does not touch the index file or working tree at all (but does reset the head to it, like all modes). This makes all your changed files “changes to be committed”.
Roll back the commit you have submitted and put the commit modifications back into the staging area.
Generally, when we use the reset command, git reset –hard will be mentioned more often. It can force the commit record to be traced back to a certain node. The function of git reset –soft is just like its name. –soft (soft) will not only retrace the node, but also retain the modified content of the node.
Application scenarios
Backtracking nodes, why should the modified content be retained?
Application scenario 1: Sometimes you accidentally commit content that should not be submitted with your hand. If you want to change it back, you can only commit it again, which adds another piece of “black history”.
Application scenario 2: A more standardized team generally requires clear responsibilities for the content of the commit and fine granularity to facilitate subsequent troubleshooting. It is irregular to commit two modifications with different functions together. This time my hand happened to slip again, so I committed it all at once.
Command usage
After learning reset –soft, you only need to:
# Restore the latest commit git reset --soft HEAD^
reset –soft is equivalent to regret medicine, giving you a chance to make changes again. For the above scenario, you can modify and resubmit again to keep a clean commit record.
The above are commits that have not yet been pushed. You can also use this command for commits that have been pushed. However, when you push again, due to differences between the remote branch and the local branch, you need to force push git push -f to overwrite the reset commit.
Another thing to note is that when reset –soft specifies a commit number, all modifications from that commit to the most recent commit will be restored, not just that commit.
for example:
The commit records include c, b, and a.
reset to a.
git reset --soft 1a900ac29eba73ce817bf959f82ffcb0bfa38f75
At this time, HEAD reaches a, and the modified contents of b and c are returned to the temporary storage area.
cherry-pick
Description
Given one or more existing commits, apply the changes introduced by each commit, recording a new commit for each commit. This requires your working tree to be clean (no modifications committed from scratch).
Copy the submitted commit and apply the new commit to the branch
Application scenarios
The commit has been submitted, why do you need to copy the new one?
Application scenario 1: Sometimes some optimization requirements of a version are halfway developed, and one of the developed requirements may need to be temporarily launched, or some reasons cause the requirements to be developed to be stuck in the online development of the developed requirements. At this time, you need to extract the commit and process it separately.
Application scenario 2: Sometimes the code records in the development branch are contaminated, causing problems when merging the development branch to the online branch. In this case, you need to pull a clean development branch, and then copy the commit from the old development branch to new branch.
Command usage
Copy a single
There is now a feature branch, and the commit record is as follows:
You need to copy b to another branch. First copy the commitHash, and then switch to the master branch.
The latest record of the current master is a. Use cherry-pick to apply b to the current branch.
After completion, take a look at the latest log. b has been applied to master as the latest commit. You can see that the commitHash is different from the previous one, but the submission time is still the same as before.
Copy multiple
The above is the copy of a single commit. Let’s take a look at how to cherry-pick multiple commits.
Transfer multiple commits at once:
git cherry-pick commit1 commit2
The above command applies commit1 and commit2 to the current branch.
Multiple consecutive commits can also be copied in intervals:
git cherry-pick commit1^..commit2
The above command applies all the commits in the range from commit1 to commit2 to the current branch (including commit1 and commit2). Commit1 is the earliest commit.
cherry-pick code conflict
When cherry-picking multiple commits, you may encounter code conflicts. At this time, cherry-pick will stop and let the user decide how to continue. Let’s see how to solve this scenario.
It is still the feature branch. Now you need to copy c, d, and e to the master branch. First write down the commitHash of the starting point c and the end point e.
Cut to the master branch and use range cherry-pick. You can see that c was successfully copied. When proceeding to d, a code conflict was found and cherry-pick was interrupted. At this time, you need to resolve the code conflict and resubmit it to the staging area.
Then use cherry-pick –continue to let cherry-pick continue. Finally, e is also copied in, and the entire process is completed.
The above is the complete process, but sometimes you may need to give up or exit the process after code conflicts:
Give up cherry-pick:
git cherry-pick --abort
Return to the way it was before the operation, as if nothing happened.
Exit cherry-pick:
git cherry-pick --quit
Not going back to the way it was before the operation. That is, keep the commits that have been successfully cherry-picked and exit the cherry-pick process.
revert
Description
Given one or more existing commits, revert the changes introduced by the relevant commits and record some new commits with those changes. This requires that your working tree is clean (no modifications from the head).
Revert an existing commit, restore the submitted content, and generate a revert record.
Application scenarios
Application scenario: One day the tester suddenly tells you that there is a problem with the function you developed and launched and needs to be withdrawn 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 commit 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 ask your colleagues to combine his code again (the colleagues want to punch them when they hear it), so your technical image plummets in the eyes of your colleagues.
Command usage
revert normal submission
After learning revert, you can immediately save this embarrassing situation.
Now the master record is as follows:
git revert 21dcd937fe555f58841b17466a99118deb489212
Revert your own commit.
Because revert will generate a new submission record, you will be asked to edit the submission information. After editing, just :wq to save and exit.
Let’s take a look at the latest log. A revert record was generated. Although your previous submission record will still be retained, the code content you modified has been withdrawn.
revert merge commit
In the commit record of git, there is another type of merge commit. If you want to revert the merge commit, the usage will be a little different.
There are now more merge commits in the master branch.
Using the same revert method just now, you will find that the command line reports an error. Why is this happening? It is explained in the official documentation.
It’s generally impossible to revert a merge because you don’t know which side of the merge should be considered the mainline. This option specifies the parent number of the mainline (starting at 1) and allows revert to reverse changes relative to the specified parent number
My understanding is that the merge commit is the intersection node of two branches, and git does not know which branch needs to be withdrawn. You need to add the parameter -m to specify the mainline branch, retain the code of the mainline branch, and the other branch will be withdrawn.
-m should be followed by a parent number to identify the “main line”. Generally, 1 is used to reserve the main branch code.
git revert -m 1 <commitHash>
After revert merge and commit, merging branches again will be invalid
Still in the above scenario, after reverting the merge and commit on the master branch, then switching to the feature branch to fix the bugs, and then merging into the master branch, you will find that the previously revert modifications have not been merged again.
Because after using revert, the commits of the feature branch will still be retained in the record of the master branch. When you merge them in again, git will judge that they have the same commitHash and ignore the relevant commit modifications.
At this time, you need to revert the merge commit that was previously reverted. This is a bit confusing. Let’s look at the operation next.
The master record now looks like this.
Use revert again, and the modified content that was reverted before will come back.
reflog
Description
This command manages the information recorded in relogging.
If reset –soft is a regret medicine, then reflog is a powerful regret medicine. It records all commit operation records, making it easy to retrieve the records after incorrect operations.
Application scenarios
Application scenario: One day you are dazzled and find that you have submitted code in other people’s branches and pushed it to the remote branch. At this time, because the branch only has your latest submission, you want to use reset –hard, but you are nervous and accidentally remember the commitHash incorrectly. , the reset went too far, and the colleague’s commit was lost. There is no way, reset –hard is a forced rollback, and the commitHash cannot be found, so I can only ask my colleague to push it again from the local branch (my colleague suddenly became hard-fisted, why is it you again)? As a result, your technical image has plummeted again.
Command usage
The branch record is as above, and I want to reset to b.
If the reset operation is overdone by mistake, b is gone, and only a is the latest one.
At this time, use git reflog to check the history and write down the commitHash of the wrong submission.
If you reset again, you will find that b is back.
Set Git short commands
For enthusiasts like me who like to type commands without using graphical tools, setting short commands can greatly improve efficiency. Here are two ways to set short commands.
method one
git config --global alias.ps push
Method 2: Open the global configuration file
vim ~/.gitconfig
Write content
[alias]
co=checkout
ps = push
pl=pull
mer = merge --no-ff
cp = cherry-pick
use
# Equivalent to git cherry-pick <commitHash> git cp <commitHash>
Summary
This article mainly shares 5 practical Git commands in development and how to set short commands.
-
stash: stores temporary code.
-
reset –soft: Soft traceback, rolling back the commit while retaining the modified content.
-
cherry-pick: copy commit.
-
revert: Undo the modifications of the commit.
-
reflog: records the historical operations of commit.
Some of the application scenarios listed in the article are not appropriate. I just want to make it easier for students to understand. The most important thing is to understand the function of the commands. Only by learning and applying them can they be most effective.
The knowledge points of the article match the official knowledge archives, and you can further learn related knowledge. Git skill treeHomepageOverview 6770 people are learning the system