12 advanced Git commands you need to know

12 advanced Git commands you need to know

As we all know, Git is already a leader in the field of distributed version control and forms a complete ecosystem around Git. To learn about Git, you must first learn the basic workflow of Git. Compared with traditional version control systems such as SVN, Git is a powerful tool designed for distributed version control. Commands commonly used by Git include pull, commit, and push, which seem simple. However, sometimes you may encounter merge conflicts. Git will mark the conflicts and you need to solve them manually. Sometimes, you accidentally submit the code to the wrong branch and push it to the remote repository. Sometimes you need to switch to different branches, but Git won't let you do this, because there are unsaved changes. What should I do if I need to patch the code by submitting another branch? This article introduces 12 advanced Git commands. Using these commands can greatly improve the efficiency of Git application.

1. Use rebase instead of merge to pull upstream modifications

Branch merge is recorded as a merge commit, which makes sense. For example, you can use this method to identify that a new feature is merged into the production branch. However, when multiple team members work in a project and use the regular git pull to synchronize branches, the submitted timeline will be contaminated by unnecessary merge submissions. A better way is to use git rebase to base a feature branch to the master Branch:

$ git checkout feature$ git rebase master

In this way, the entire feature branch will be moved to the starting point of the master branch, and it will merge all new submissions on the master branch. However, compared with the combined commit, the variable commit overwrites the project history by creating a new commit for each commit in the original branch. The main benefit of changing the base is that you will get a more clean project history. In addition, there are some discussions about the trap of changing the base.

2. After git rebase is executed, merge conflicts are resolved.

The larger the capability, the greater the responsibility. When executing git rebase, you may encounter merge conflicts. Merge Conflicts indicate that the two submitted and modified the same row of the same file, and Git does not know which modification of the application. This will cause the following error message:

Git provides you with three options to fix the submission that causes the conflict (fa39187 ):

• You can run git rebase-abort to completely cancel the baseline change. In this way, the modification will be canceled, and the branch will be set back to the status before git rebase is executed.

• You can run git rebase-skip to ignore the commit completely. In this way, changes introduced by problematic submissions will not be added to history.

• You can use the same standard steps as merge conflicts to resolve conflicts.

3. Save temporary changes

Some things are often messy during work. What if we need to switch to different branches? Git does not allow you to do this because there are still unsaved changes. In other words, you do not want to submit the semi-finished products, and then modify them later. The solution to this problem is to use the git stash command. Stash will receive the current status of the working directory (for example, modifications to the modified Tracing file and the temporary storage area) and save it to the unfinished modification stack, in this way, you can modify it at any time. Run the following command to save your work:

$ git stashSaved working directory and index state WIP on feature: 3fc175f fix race conditionHEAD is now at 3fc175f fix race condition

Now, the working directory is clean:

$ git status# On branch featurenothing to commit, working directory clean

In this case, you can switch the branch securely to do other things. But don't worry, the temporary submission is still in:

$ git stash liststash@{0}: WIP on feature: 3fc175f fix race condition

Later, after returning to the feature branch, you can retrieve all temporary changes:

$ git stash popOn branch featureChanges not staged for commit:  (use "git add ..." to update what will be committed)     modified:   index.htmlDropped refs/stash@{0} (ac2321cc3a33ba712b8e50c99a99d3c20da9d6b8)

There are other options available for temporary storage, as shown below:

$ git stash save "describe it"   # give the stash a name$ git stash clear                # delete a stashed commit$ git stash save --keep-index    # stash only unstaged files

4. clone a specific remote Branch

What should I do if I want to get a specific branch from the remote warehouse? You usually use git clone, but this will clone all other branches. A convenient way is to use git remote add:

$ git init  $ git remote add -t  -f origin $ git checkout

5. Merge the remote submission of cherry-pick to your branch

What's more, what should I do if I only want to merge a specific commit of the remote warehouse into my own branch? You can use git cherry-pick to select the submission of the given SHA value and merge it into the current branch:

$ git cherry-pick

6. Patches for applications from irrelevant local warehouses

What should I do if I need to apply the patch submitted by another unrelated local repository to the current repository? The answer is the following command:

$ git --git-dir=/.git format-patch -k -1 --stdout  | git am -3 -k

7. Ignore Changes in the tracking File

If you and your colleagues manipulate the same branch, you may need to execute git merge or git rebase frequently. However, this may reset some environment-related configuration files so that they need to be modified after each merge. In contrast, you can use the following command to permanently tell Git not to manage a local file:

$ git update-index --assume-unchanged

8. Run git pull once every X seconds

Generally, a merge conflict occurs because the local repository you are working on does not reflect the current status of the remote repository. That's why we need to execute git pull once every morning. In addition, you can call git pull once every X seconds through scripts (or GNU Screen) in the background:

$ screen$ for((i=1;i<=10000;i+=1)); do sleep X && git pull; done

9. Separate subdirectories into new warehouses.

Sometimes you may need to convert a specific directory in the Git repository into a brand new repository. This can be achieved through git filter-branch:

$ git filter-branch --prune-empty --subdirectory-filter  master# Filter the master branch to your directory and remove empty commitsRewrite 48dc599c80e20527ed902928085e7861e6b3cbe6 (89/89)Ref 'refs/heads/master' was rewritten

The repository now contains all the files in the specified subdirectory. Although all previous files will be deleted, they still exist in the Git history. Now you can push the new local repository to the remote.

10. Clean up

Sometimes, Git prompts "untracked working tree files" and "overwritten by checkout ". There are many reasons for this situation. However, we can use the following command to keep the work tree clean and tidy to prevent this situation:

$ git clean -f     # remove untracked files$ git clean -fd    # remove untracked files/directories$ git clean -nfd   # list all files/directories that would be removed

11. Pack the project file into a tar package and exclude the. git directory.

Sometimes, you need to provide a copy of the project to external members who cannot access the GitHub repository. The simplest way is to use tar or zip to package all the project files. However, if you are not careful, hide it. the git directory will be included in the tar file, which will lead to a larger file size. At the same time, if the files in it are mixed with the recipient's own Git repository, it will be even more troublesome. The easy way to do this is to automatically remove the. git directory from the tar file:

$ tar cJf .tar.xz / --exclude-vcs

12. Find the Modifier

Finally, in case of chaos, you must find out who caused it. If the production server goes down, it is easier to find the culprit: simply execute git blame. This command displays the author of each row in the file. When hash is submitted, the last modification of the row is found, and the submitted timestamp is displayed:

$ git blame

Of course, there are many Git commands. Apart from the 12 important commands described above, I believe that InfoQ readers also have some preferred and useful commands in their daily work, share Comments with other readers.

Git Tutorials:

GitHub tutorials

Git tag management details

Git branch management

Git remote repository details

Git local Repository (Repository) Details

Git server setup and Client installation

Git Overview

Share practical GitHub tutorials

How to Build and use Git servers in Ubuntu

Git details: click here
Git: click here

This article permanently updates the link address: