preface

Using Git for code versioning is now a must-have skill for developers. However, most engineers only know the basics of save, pull, and push, and are unable to solve commit management problems or solve them in some inelegant way.

This article shares some of the practical commands I’ve experimented with in my development work. These can greatly improve work efficiency, but also solve many difficult scenes. The following will introduce the command, list the application scenarios, hand to hand teaching use, so that students can learn after reading.

stash

The official documentation

Git tutorial

describe

Official explanation: Use git Stash when you want to keep track of the current state of your working directory and index, but still want to return a clean working directory. This command will save the local changes and restore the working directory to match the header submission.

The stash command keeps your working directory clean by storing code that has not yet been committed.

Application scenarios

I bet you’re thinking: Why clean?

Application scenario: One day you are developing a new requirement in the feature branch, and suddenly the product manager comes to you and says there is a bug on the line that must be fixed immediately. At this point, you are in the middle of functionality development, so you rush to switch to the Master branch, and you get the following error:

Because there are currently file changes, you need to commit to keep your workspace clean in order to cut branches. Because of the urgency of the situation, you have to rush to commit, commit information also randomly write a “temporary code”, so the branch commit record left a black history… (Real people, read this submission)

Command to use

If you learn Stash, you won’t be so embarrassed. You just need to:

git stash
Copy the code

As simple as that, the code is stored.

When you have fixed the online problem and cut back to the feature branch, you only need to restore the code:

git stash apply
Copy the code

Relevant command

Save the current uncommitted code
git stash

Save the current uncommitted code and add a note
git stash save "Contents of remarks"

List all stash records
git stash list

Delete all stash records
git stash clear

# Apply the most recent Stash
git apply

# Apply the most recent Stash and then delete the record
git pop

# Delete the most recent Stash
git stash drop
Copy the code

When there are multiple stash operations, you can specify the stash operation. First use the Stash list to list all the records:

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

Apply the second record:

$ git stash apply stash@{1}
Copy the code

Same thing with pop and drop.

Vscode integration

Stash code

Enter the remarks or Enter

You can see the stash saved in the STASHES menu

Click the little arrow next to the Stash record and then click Apply or Pop to restore the Stash record

reset –soft

The official documentation

Git tutorial

describe

The index file or working tree is not touched at all (but the header is reset to, as is the case with all modes). This changes the file for all your changes to “Changes to commit”.

Roll back your commit and put your commit changes back into the staging area.

Git reset –hard is often used when using the reset command to force the commit to go back to a node. Git reset –soft does what it sounds like –soft does not only retrace the node, but also keep the changes made by the node.

Application scenarios

Looking back at the node, why keep the changes?

Application Scenario 1: Sometimes you accidentally commit something that shouldn’t be committed. If you want to change it back, you have to commit it again, which means another “black history”.

Application Scenario 2: Standard teams generally require clear responsibilities and fine granularity for commit content to facilitate follow-up troubleshooting. It is not standard to commit two changes of different functions together. This time happens to slip hand, one-time commit up.

Command to use

After learning to reset –soft, you just need to:

Restore the most recent commit
git reset --soft HEAD^
Copy the code

Reset –soft is like a medicine for repentance, giving you a chance to mend your ways. For the above scenario, you can modify the commit again, keeping the commit record clean.

This is the commit that hasn’t been pushed yet. You can also use git push -f to override the reset commit if the remote and local branches are different.

It is also important to note that when you specify a commit number in reset –soft, all changes from that commit to the last commit are restored, not just for that commit.

Here’s an example:

Commit Records C, B, and A.

Reset to a.

git reset --soft 1a900ac29eba73ce817bf959f82ffcb0bfa38f75
Copy the code

At this time, the HEAD is in A, and the modifications of B and C are back to the temporary storage area.

cherry-pick

The official documentation

Git cherry – pick tutorial

describe

Given one or more existing commits, the changes introduced by each commit are applied and a new commit is logged for each commit. This requires your work tree to be cleaned (no changes committed from scratch).

Copy the existing commit and apply the new commit to the branch

Application scenarios

If a commit is already committed, why copy a new one?

Application scenario 1: Sometimes some optimization requirements of the version are halfway developed. One of the requirements may be temporarily developed, or some reasons may cause that the requirements to be developed are blocked and the completed requirements are put online. At this point, you need to extract the COMMIT and handle it separately.

Application scenario 2: Sometimes the code record in the development branch is contaminated, causing problems in merging the development branch to the online branch. In this case, you need to pull a clean development branch and copy the COMMIT from the old development branch to the new branch.

Command to use

Copy of a single

Now there is a feature branch and the commit is as follows:

We need to copy b to another branch, first copy commitHash, then cut to the master branch.

The latest record for the current master is A, and use cherry-pick to apply B to the current branch.

When done, look at the latest log. B has been applied to the master as the latest commit. You can see that commitHash is not the same as before, but the commit time remains the same.

Copy multiple

This is a copy of a single commit, so let’s look at how multiple cherry picks work.

  • Move multiple commits at once:
git cherry-pick commit1 commit2
Copy the code

The above command applies commit1 and COMMIT2 commits to the current branch.

  • Multiple consecutive commits, or interval replication:
git cherry-pick commit1^.. commit2Copy the code

The above command applies all commit1 through COMMIT2 commits to the current branch (commit1, COMMIT2), commit1 being the earliest commit.

Cherry-pick code conflicts

Code conflicts can occur when cherry-pick has multiple commits, at which point cherry-pick stops and lets the user decide how to proceed. Here’s how to solve this scenario.

Copy c, D, and e to the master branch. Write down commitHash at start C and end E.

To cut to the master branch, use the cherry-pick of the interval. You can see that C is copied successfully, and when you go to D, you find a code conflict and cherry-pick breaks. The code conflicts need to be resolved and recommitted to the staging area.

Then use cherry-pick –continue to let cherry-pick continue. Finally, e is copied in, and the whole process is complete.

The above is the complete process, but sometimes it may be necessary to abandon or exit the process after code conflicts:

  • To give upcherry-pick:
gits cherry-pick --abort
Copy the code

Go back to the way it was before the operation, like nothing ever happened.

  • exitcherry-pick:
git cherry-pick --quit
Copy the code

Don’t go back to the way it was before the operation. That is, retain the cherry-pick successful commit and exit the cherry-pick process.

revert

The official documentation

describe

Given one or more existing commits, restore the changes introduced by the related commits and record some new commits of those changes. This requires that your working tree be clean (no modifications from the header).

Restores an existing commit, restores what was committed, and generates a restore record.

Application scenarios

Application scenario: One day, the test suddenly tells you that there is a problem with the function you developed online and you need to withdraw it immediately, otherwise the system will be affected. If you look at the branch’s latest commit and other colleagues’ code, reset will undo that code as well. Reset reset reset reset reset reset reset reset reset reset reset reset reset reset reset reset reset

Command to use

Revert Common Submission

Learning to revert can save the day in no time.

Now the master record is as follows:

git revert 21dcd937fe555f58841b17466a99118deb489212
Copy the code

Revert a COMMIT you made yourself.

Because Revert generates a new commit record, it will ask you to edit the commit. After editing, :wq will save and exit.

Take a look at the latest log, which generates a revert record. While your previous commit will remain, the code you changed has been removed.

Merge submit

There is another type of Git commit that you can use a little differently to revert a merge commit.

There are now merge commits in the Master branch.

Using the same revert method you just used, you get an error on the command line.

Why is that? This is explained in the official documentation.

Often you cannot revert a merge because you don’t know which side of the merge should be considered the main line. This option specifies the parent number of the main line (starting at 1) and allows revert to reverse changes relative to the specified parent number

Git doesn’t know which branch to undo. You need to add the -m parameter to specify the main branch, keep the code for the main branch, and undo the other branch.

-m is followed by a parent number to identify the “main line”, usually using 1 to preserve the main branch code.

git revert -m 1 <commitHash>
Copy the code

After a merge commit, merging branches becomes invalid again

As in the above scenario, the Master branch fails to incorporate the existing changes into the Master branch after deleting them from the feature branch to fix the bug.

Because a commit from the feature branch remains in the master branch, Git ignores the commit changes when you merge it again, judging that it has the same commitHash.

In this case, you need to revert the merge commit from the previous REVERT.

Now the master’s record looks like this.

Use Revert again, and the changes that were previously revert come back.

reflog

The official documentation

describe

This command manages the information recorded in the rerecord.

If you use “reset” or “soft”, you use “reflog”. It records all commit operations so that it can be retrieved after an error.

Application scenarios

Application scenario: One day, you find yourself committing code from another branch and pushing it to a remote branch. Because the branch only has your latest commit, you want to use reset –hard, and remember commitHash. [bug Mc-10862] – reset -hard is mandatory, you can’t find commitHash, you have to ask your colleague to repress it from local branch. And then your tech image took another nosedive.

Command to use

Branch record above, want to reset to B.

Wrong operation reset too much, B is gone, the latest only a.

Git reflog to check the history and make a note of the commitHash error committed.

If you reset it again, you’ll find that B is back.

Set Git short commands

For me, who likes to type commands rather than use graphical tools, setting short commands is a great way to improve efficiency. The following describes two ways to set the short command.

Methods a

git config --global alias.ps push
Copy the code

Way 2

Open the global configuration file

vim ~/.gitconfig
Copy the code

Write content

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

use

Git cherry-pick 
      
git cp <commitHash>
Copy the code

conclusion

This article focuses on five Git commands that are useful for development and ways to set up short commands.

  • stash: Stores temporary code.
  • reset --soft: Soft traceback, in which the modification is retained while the commit is rolled back.
  • cherry-pick: Copy commit.
  • revert: Revokes the modification of commit.
  • reflog: Records the history of the commit operation.

Some of the application scenarios listed in the article are not appropriate, but I just want to facilitate students to understand, the most important thing is to understand the role of the command, live learning and use can give full play to the effect.

If you have some useful Git commands, please share them in the comments section