12 + git Advanced commands

As is known to all, Git is now a leader in distributed versioning, creating a complete ecosystem around git. Learning Git is, of course, the basic workflow of learning git. Compared to traditional version control systems like SVN, Git is a powerful tool for distributed version control. The commands that are commonly used when using Git are pull, commit, push, and so on, seemingly simple. However, there are times when you encounter merge conflicts, and GIT will flag the conflict and require you to fix it manually. Sometimes, you accidentally commit the code to the wrong branch and push it to the remote repository. There are times when you need to switch to a different branch, but Git won't let you do it because there are unsaved changes. What if you need to patch the code through the submission of another branch? This article will introduce the 12 git advanced commands, and the proper use of these commands can greatly improve the efficiency of git application.

1. Use rebase instead of merge to pull upstream modifications

It makes sense for a branch merge to be recorded as a single merge submission. For example, it is possible to identify a new feature that has been incorporated into the publishing branch in this way. However, when multiple team members work in a project and use regular git pull to synchronize branches, the commit timeline is contaminated with unnecessary merge submissions. A better approach would be to use Git rebase to base a feature branch on the master branch:

$ git checkout feature$ git rebase master

Doing so moves the entire feature branch to the start of the master branch, which merges all the new commits on the master branch. However, instead of using merge submissions, the variable overrides the project history by creating a new commit for each commit in the original branch. The main benefit of a variable is that you get a cleaner project history. In addition, there are some discussions about the traps of the variable base.

2. Resolve merge conflicts after executing git rebase

Just as the greater the capacity, the greater the responsibility. When you execute Git rebase, you may encounter merge conflicts. Merge conflict indicates that two commits modified the same line of the same file, and git does not know which one to apply. This causes the error message to resemble the following:

Git will give you 3 choices to fix the commit that caused the conflict (fa39187):

You can run git rebase--abort to completely de-base the variable. Doing so cancels the change-base modification and resets the branch back to the state it was before executing git rebase.

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

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

3. Temporary Save changes

Some things tend to be messy when the work is in progress. What if you need to switch to a different branch at this point? Git doesn't allow you to do this because there are unsaved changes. Frankly, you do not want to submit the semi-finished products, and then to revise. The solution to this problem is to use the git stash command. Stash will receive the current status of the working directory (for example, modified tracking files and staging area changes, etc.) and save them to the unfinished modification stack, so that they can be modified at any time later. You can temporarily save your work by using the following command:

$ git stash
Saved working directory and index state WIP on feature:3fc175f fix race condition
HEAD is now at 3fc175f Fix race condition

Now, the working directory is clean:

$ git status# on branch featurenothing to commits, working directory clean

Then it's safe to switch branches to do something else. But don't worry, the staging submission still remains:

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

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

$ git Stash popon branch featurechanges not staged for commit:  (use "git add ..." To update what would be committed) 
  modified:   index.htmldropped refs/stash@{0} (AC2321CC3A33BA712B8E50C99A99D3C20DA9D6B8)

There are several other options available for staging, as follows:

$ 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. Cloning a specific remote branch

What if you want to clone a specific branch from a remote repository? Usually you will use Git clone, but doing so will clone all the other branches. One convenient way is to use git remote add:

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

5. Merging Cherry-pick remote commits into their own branch

What's more, what if you just want to merge a specific commit from a remote repository into your own branch? You can use Git cherry-pick to select a commit for a given SHA value and then merge it into the current branch:

$ git Cherry-pick

6. Apply patches from unrelated local repositories

What if you need to apply a commit patch from another unrelated local repository to the current warehouse? The answer is the following command:

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

7. Ignore changes in the trace file

If you and your coworkers are manipulating the same branch, you probably need to do git merge or git rebase frequently. However, doing so may reset some of the environment-related configuration files so that they need to be modified after each merge. Instead, you can permanently tell git to leave out a local file with the following command:

$ git update-index--assume-unchanged

8. Run git pull once every x seconds

Typically, a merge conflict occurs because the local warehouse you are working on no longer reflects the current state of the remote warehouse. That's why we have to do git pull first thing every morning. In addition, you can invoke git pull in the background via scripting (or using GNU screen) every x seconds:

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

9. Separating subdirectories into new warehouses

Sometimes, you might need to convert a specific directory in a git repository into a completely new repository. This can be done with git filter-branch:

$ git filter-branch--prune-empty--subdirectory-filtermaster# filter The master branch to your directory and remove empty Commitsrewrite 48dc599c80e20527ed902928085e7861e6b3cbe6 (89/89) Ref ' Refs/heads/master ' was rewritten

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

10. Cleaning up

Sometimes, Git will prompt "untracked working tree Files" to "overwritten by checkout". There are many reasons for this situation. However, in general, we can use the following command to keep the work tree neat, thus preventing this from happening:

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

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

Sometimes, you need to make a copy of the project available to external members who cannot access the GitHub repository. The simplest way to do this is to use tar or zip to package all the project files. However, if you are not careful, the hidden. Git directory will be included in the tar file, which will make the file size larger, and it will be even more frustrating if the files in it are confused with the recipient's own Git repository. The easy way to do this is to automatically exclude the. git directory from the tar file:

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

12. Find a modified person

Finally, if there is a situation of confusion, you will want to find out who caused it. If the production server goes down, it's easier to find the culprit: just git blame. The command displays the author of each line in the file, commits the hash, finds the last modification of the row, and sees the timestamp of the commit:

$ git blame

Of course, the git command is very much, in addition to the 12 important commands described above, I believe that Infoq readers in the daily work process also have their own preferred and useful commands, it may be in the form of comments and other readers to share.

