10 tips for developers to quickly improve their Git level (1)

10 tips for developers to quickly improve their Git level (1)

Recently we have released two Tutorials: getting familiar with the basic features of Git and letting you use Git skillfully in the development team. The commands we have discussed are enough for a developer to use Git. In this article, we try to find out how to effectively manage your time and fully use the features provided by Git.

Note: In this article, some commands contain part of square brackets, for example:Git add-p [file_name]In these examples, you will insert necessary numbers, identifiers, and so on, if there is no square brackets.

1. Git auto-completion

If you use the command line tool to run Git commands, it is annoying to manually enter various commands each time.

To solve this problem, you can enable the Git auto-completion function. It takes only a few minutes to complete this task.

To get this script, run the following command on Unix:

 
 

  
  
cd ~  
  
  
curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.bash 
 
 

Then, add the following lines to your ~ /. Bash_profile file:

 
 

  
  
if [ -f ~/.git-completion.bash ]; then  
  
  
    . ~/.git-completion.bash  
  
  
fi 
 
 

Although we mentioned this earlier, the emphasis is not sufficient. If you want to use all the features of git,

You should definitely switch to the command line interface!

2. Ignore files in Git

Are you bored with those compiled files (such as. pyc) appearing in your Git repository? Or have you gotten enough of them all added to the Git repository? Well, there is a way for you to tell Git to ignore those specific files and folders. You only need to create a file named. gitignore and list the files and folders that you do not want Git to trace. You can also add exceptions by using an exclamation point (!).

 
 

  
  
*.pyc  
  
  
*.exe  
  
  
my_db_config/  
  
  
   
  
  
!main.pyc 
 
 

3. Who messed up my code?

When something goes wrong, it is human nature to blame others first. If your product server crashes, you can easily find out the culprit by using the git blame command. This command displays the author of each row in the file, the latest change submission time, and the submission time.

 
 

  
  
git blame [file_name] 
 
 

In the following example, you can see how the command is searched in a larger directory.

4. View Warehouse history

We have learned how to use git log in the previous section. However, there are three options you should know.

• -- Oneline-compression mode. The submitted hash code and submission information are displayed next to each submission in one row.

• -- Graph-graph mode. This option is used to draw a historical graph based on text format on the left of the output. This option is invalid if you are viewing the history of a single branch.

• -- All-display historical records of all branches

After combining these options, the output will look like this:

5. Never lose tracking of Commit

If you accidentally submit something you don't want, you have to perform a force reset to restore it to the previous state. Then, you realize that you have lost some other information and want to get them back, or at least glance. This is exactly what git reflog can do.

A simple git log command can show you the last commit, its father, its father, and so on. While git reflog lists a series of commit that head once pointed. You must understand that they exist only in your local machine, not part of your version repository, and are not included in the push and merge operations.

If I run the git log command, I can see some commit, which are part of my Repository:

 

However, a git reflog command shows a commit (b1b0ee9 & #8211; HEAD @ {4}), which is exactly what I lost during a force Reset: