Don’t just pull and push Git, try these 5 commands to improve efficiency

Don’t just pull and push Git, try these 5 commands to improve efficiency

This article mainly shares 5 practical Git commands in development and how to set short commands.

  • stash
  • reset –soft
  • cherry-pick
  • revert
  • reflog

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

Official documentation: Git – git-stash Documentation

git tutorial:

https://www.bookstack.cn/read/git-tutorial/docs-commands-git-stash.md

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. Since the situation is urgent, you can only commit in a hurry, and the commit information also casually writes “temporary code”, so the branch’s submission record leaves a black history… (Real person has seen this kind of submission)

Command usage

If you learn stash, you don’t have to be so embarrassed. All you need is:

sh copy code 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:

sh copy code git stash apply

Related commands

sh copy code# Save the current 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:

sh copy code $ git stash list
stash@{0}: WIP on ...
stash@{1}: WIP on ...
stash@{2}: On ...

Apply the second record:

sh copy code $ 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

Official documentation: https://git-scm.com/docs/git-reset

Git tutorial: https://www.bookstack.cn/read/git-tutorial/docs-commands-git-reset.md

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 frequently. 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:

sh copy code# Restore the latest commit
git reset --soft HEAD^

reset –soft is equivalent to regret medicine, giving you a chance to change things 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. This command can also be used for commits that have been pushed. However, when pushing 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.

Give a chestnut:

The commit records include c, b, and a.

reset to a.

sh copy code 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

Official documentation: https://git-scm.com/docs/git-cherry-pick

git cherry-pick tutorial: http://www.ruanyifeng.com/blog/2020/04/git-cherry-pick.html

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:
sh copy code 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:
sh copy code 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 d was reached, 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

sh copy code gits cherry-pick --abort

Return to the way it was before the operation, as if nothing happened.

  • quit

cherry-pick

sh copy code 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

Official documentation: https://git-scm.com/docs/git-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:

?

sh copy code 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.

sh copy 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

Official documentation: https://git-scm.com/docs/git-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. I can only ask my colleague to push it again from the local branch (my colleague suddenly got 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 record 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 1

sh copy code git config --global alias.ps push

Method 2

Open global configuration file

sh copy code vim ~/.gitconfig

Write content

ini copy code [alias]
        co=checkout
        ps = push
        pl=pull
        mer = merge --no-ff
        cp=cherry-pick

Use

sh copy code# 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
  • reset –soft
  • cherry-pick
  • revert
  • reflog

Note

There is also git rebase -i, which is used to merge commit records. Some people commit dozens of times in one iteration, and merge their messy commit records into one big commit before finally merging it into the Master, which is clean and hygienic.

This can also be used when merging –squash (if merge is used)

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.

If you also have some practical Git commands, please share them in the comment area~