Shulou(Shulou.com)06/02 Report--

In this issue, the editor will bring you what are the practical skills about Git. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

1. Use git blame to find out who touched a line of code.

After locating the line of code that went wrong, you can use git blame to further find out who moved the relevant code, or find the historical background of the change, as an example:

$cd linux-stable$ git blame-L 50 init/main.c78634061 (Frederic Weisbecker 2017-10-27 04:42:28 + 0200 50) # include

two。 Obtain the submission time of a commit or tag through git log

When analyzing a recession, if you find a change, and then you want to further determine which version (Tag) the change was introduced, you can find the time of the commit first, and then compare the revision time of the Tag. So how do you check the introduction time of commit and tag? An example of the commit of HEAD is as follows:

$date-d @ `git log-1-- format=%ct head` +% Y%m%d-%H%M%S20190719-172216

The corresponding time can be obtained by replacing HEAD with specific commit and tag numbers. For Linux, it usually doesn't need to be so complicated, and after finding a change, you can use the following method to determine the kernel major version corresponding to that change:

$git show HEAD:Makefile

Because the version number of the kernel is recorded in Makefile.

3. Fast location of problems by git bisect automatic dichotomy

Some system, in the development process has not been tested a problem, suddenly one day, found Bug. This is a lot of cases of recession, if the probability of recurrence of this Bug is very high, it can be quickly located directly by dichotomy. Git bisect can assist with automatic dichotomy.

To put it simply, keep telling git bisect which is good and which is bad. If there is a fixed reproduction script, then after getting the first pair of commit of bad and good, you can directly let git bisect automatically dichotomy. Examples are as follows:

$git bisect start$ git bisect bad efa5cf$ git bisect good b6fcf0 $git bisect run grep-q UCONFIG Makefile

Description:

Efa5cf: the first version found to have a problem b6fcf0: a confirmed version of grep-q UCONFIG Makefile: it's good to find UCONFIG, but there's a problem if you can't find it.

After setting bad and good, git bisect will automatically cut out an intermediate version, and then for this version, you can configure, compile, run, and then set the version to bad or good according to the test results, for example: git bisect bad HEAD, and so on, git bisect will keep cutting out the intermediate version until you can determine the first version of bad, which introduces decaying changes.

If this complete testing process can be automated, it can be scripted as a parameter to git bisect run, so that manual running of the test can be avoided. The above grep command is a simplification strategy found after a preliminary analysis. If you can determine the problem by retrieving the code changes in this way, you can really save a lot of effort.

4. Update the remote warehouse address of git submodule with git submodule sync

Some time ago, we moved a lot of warehouses from github to gitee. After moving, both .gitmodules and .git / config under Linux Lab have to update the url address, but they cannot be used directly after the update, and we have to synchronize them with git submodule sync:

Step 1, replace url in .gitmodules and .git / config with sed, step 2, execute `git submodule sync "`5. Configure different ssh key for different Git repositories

In order to optimize download efficiency, Linux Lab has recently been migrated to Code Cloud, configuring different ssh private / public keys. To avoid having to specify different parameters on the command line each time, you can add a configuration file.

For example, name the private key file of Code Cloud gitee.id_rsa, put it in the ~ / .ssh directory and modify the permissions.

$chmod 600 ~ / .ssh/gitee.id_rsa$ chmod 700 ~ / .ssh

After that, add a new ~ / .ssh / config and add the following configuration:

$cat ~ / .ssh/configHost giteeHostName gitee.comIdentityFile ~ / .ssh/gitee.id_rsaUser git

This can be directly similar to downloading and uploading below, without having to enter a password or specify a key each time, and omitting git@.

$git clone gitee:aaaa/yyyy.git$ cd cloud-lab$ touch xxxx$ git add xxxx$ git commit-s-m "add xxxx" $git push gitee:aaaa/yyyy.git master

6. Using git fetch instead of git clone to realize breakpoint continuation

When downloading a large code warehouse with git clone, once the network is interrupted, the result will be crying for father and mother, but it won't help.

Because git clone does not implement breakpoint continuation, I don't know what's going on in the developer's mind? Linus asked for scolding.

It doesn't matter, a similar effect can be achieved with git fetch, and it's extremely simple.

First create an empty directory with git init:

$mkdir test-repo$ cd test-repo$ git init

Then use git fetch to ask for clone's warehouse:

$git fetch https://gitee.com/tinylab/cloud-lab.git$ git checkout-b master FETCH_HEAD

Git fetch can only be done one by one, and the FETCH_HEAD checkout can be created to create a new branch. If git fetch interrupts the network midway, git fetch,git fetch can continue to pass it again, so that all previous efforts will not be wasted as soon as the network is cut off.

These are the practical skills of Git shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.