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

This article will explain in detail the example analysis on the use of tips in Git. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

Git is a very powerful version control system, but Git is different from the conventional file-based VCS system architecture, and the functions based on the pure command line are involved, which makes it difficult for beginners to find out and cause fear.

1. Your ~ / .gitconfig file

When you first try to submit a change to the warehouse using the git command, you may receive a welcome message like this:

* * Please tell me who you are.Run git config-- global user.email "you@example.com" git config-- global user.name "Your Name" to set your account's default identity.

You may not realize that these commands are modifying the contents of ~ / .gitconfig, which is where Git stores global configuration options. You can do a lot of things through ~ / .gitconfig files, including defining aliases, permanently turning on (or off) specific command options, and modifying how Git works (for example, which diff algorithm git diff uses, or what type of merge strategy is used by default). You can even conditionally include other configuration files according to the path of the warehouse! Please refer to man git-config for all details.

2. The .git / config file in your warehouse

In the previous technique, you might want to know what the-global flag is for in the git config command. It tells Git to update the "global" configuration in ~ / .gitconfig Of course, having a global configuration also means that there will be a local configuration. Obviously, if you omit the-global flag, git config will update the repository-specific configuration instead, which is stored in .git / config.

Options set in the .git / config file override all settings in the ~ / .gitconfig file. So, for example, if you need to use a different email address for a specific warehouse, you can run git config user.email "also_you@example.com". Then, any submission in the warehouse will use the email address that you configured separately. This is useful if you are working on an open source project and want them to display your email address while still using your own work mailbox as the main Git configuration.

Almost anything you can set in ~ / .gitconfig, you can also set it in .git / config to make it work on a specific warehouse. In the following tips, when I mention adding something to ~ / gitconfig, just keep in mind that you can also add it to the. git/config of a specific warehouse to set that option.

3. Alias

An alias is another thing you can do in gitconfig. It works like shell on the command line-- they set a new command name and can invoke one or more other commands, usually with a specific set of options or flags. They are very effective for long and complex commands that you often use.

You can use the gitconfig command to define aliases-- for example, running gitconfig-global-add alias.st status will make running git st do the same thing as running git status-- but when I define aliases, I find it's usually easier to edit the ~ / .gitconfig file directly.

If you choose to use this method, you will find that the ~ / .gitconfig file is an INI file. INI is a key-value pair file format with specific paragraphs. When adding an alias, you will change the [alias] paragraph. For example, when defining the same git st alias above, add the following to the file:

[alias] st = status

(if you already have a [alias] paragraph, just add the second line to the existing section. )

4. Aliases in the shell command

Aliases are not limited to running other Git subcommands-you can also define aliases to run other shell commands. This is a great way to deal with a recurring, rare, and complex task: once you've determined how to accomplish it, you can save the command under an alias. For example, I have some repositories of open source projects that replicate fork and make some local modifications. I want to keep up with the ongoing development work of the project and save my local changes. To achieve this, I need to periodically merge changes from the upstream repository into my replicated project-- I do this by using an alias I call upstream-merge. It is defined as follows:

Upstream-merge =! "git fetch origin-v & & git fetch upstream- v & & git merge upstream/master & & git push"

The beginning of the alias definition! Tell Git to run this command through shell. This example involves running some git commands, but aliases defined in this way can run any shell command.

Note that if you want to copy my upstream-merge alias, you need to make sure that you have a Git remote repository named upstream that points to the upstream repository you have assigned, and you can add one by running git remote add upstream. )

5. Visual submission map

If you are developing on a project with many branch activities, it may sometimes be difficult to grasp all the work that is happening and the correlation between them. Various graphical user interface tools allow you to take pictures of different branches and submit them in the so-called "submit chart". For example, the following is part of one of my repositories that I visualized using the GitLab submit Chart Viewer:

13 practical Git skills 13 practical Git skills

GitLab commit graph viewer

If you are a command-line focused user or find the branch switching tool distracting, you can get a similar submission view from the command line. This is where the-graph parameter of the git log command appears:

13 practical Git skills 13 practical Git skills

Repository visualized with-graph command

The following command visualizes the same warehouse to achieve the same effect:

Git log-graph-pretty=format:'%Cred%h%Creset -% C (yellow)% d%Creset% s% Cgreen (% cr)% C (bold blue)% Creset'-- abbrev-commit-- date=relative

The-graph option adds the diagram to the left side of the log,-abbrev-commit shortens the submitted SHA value,-date=relative represents the date in a relative manner, and-pretty handles all other custom formats. I have a git lg alias for this function, which is one of my 10 most commonly used commands.

6. More elegant forced push

Sometimes, the more you want to avoid it, the more you can't avoid it, and you will find that you need to run git push-force to overwrite the history on the remote copy of the warehouse. You may get some feedback that requires you to change the base of rebase interactively, or you may have screwed up and want to hide the "evidence of guilt".

The danger of forced push occurs when others make changes on the same branch of the remote copy of the warehouse. When you force a rewritten history to be pushed, these submissions will be lost. This is why git push-force-with-lease appears-if the remote branch has been updated, it will not allow you to force push, which ensures that you will not lose someone else's job.

7. Git add-N

Have you ever used git commit-a to commit all outstanding changes in one operation, but only to find that git commit-an ignored the newly added files after you pushed the submission? You can use git add-N (think "notify") to solve this problem, telling Git that you want to include new files in the submission before actually submitting them for the first time.

8. Git add-p

The best practice when using Git is to ensure that each commit contains only one logical change-- whether it's fixing bugs or adding new functionality. However, sometimes when you are working, changes in your warehouse should end up using multiple commits. How can you manage to separate things so that each submission contains only the appropriate changes? Git add-patch is coming to save you!

This flag will let the git add command view all changes in your working copy and ask for each change if you want to submit it, skip it, or postpone the decision (you can choose after running the command? To see other more powerful options). Git add-p is an excellent tool for generating well-structured submissions.

9. Git checkout-p

Similar to git add-p, the git checkout command also accepts the-patch or-p option, which causes it to display each "chunk" of changes in the local working copy and allows it to be discarded-simply to restore the local working copy to the state it was before the change.

This is really great. For example, when you trace a bug and introduce a bunch of debug log statements, after correcting the bug, you can first use git checkout-p to remove all new debug logs, and then git add-p to add bug fixes. Nothing is more satisfying than combining an elegant, well-structured submission!

10. Execute orders when changing bases

Some projects have a rule that every commit in the repository must be working-- that is, with each commit, the code should be compiled, or the test suite should be run without failure. This is not difficult when you are working on a branch, but if you eventually need to change the base rebase for some reason, you need to step through the commit of each change base to ensure that you do not accidentally introduce an interrupt, and the process is tedious.

Fortunately, git rebase has overridden the-x or-exec options. Git rebase-x will run the command after each submission is applied in the change base. So, for example, if you have a project in which you use npm run tests to run your test suite, git rebase-x npm run tests will run the test suite after each submission during the rebase period. This allows you to see if the test suite fails in any rebasing submission, so that you can confirm that the test suite still passes each commit.

11. Time-based revision references

Many Git subcommands accept a revision parameter to determine which part of the repository the command acts on. It can be the SHA1 value of a specific submission, the name of a branch, or even a symbolic name such as HEAD (representing the last commit of the currently checked-out branch). In addition to these simple forms, you can also attach a specified date or time as a parameter to indicate "reference to this time".

This feature can be very useful at some point. When you deal with the latest bug, you say to yourself, "this feature was fine yesterday, what has changed?" instead of staring at the full screen of git log output to try to figure out when the submission was changed, just run git diff HEAD@ {yesterday} and see all the changes since yesterday. This also applies to longer periods of time (for example, git diff HEAD@ {'2 months ago'}) and an exact date (for example, git diff HEAD@ {'2010-01-01 12).

You can also use these date-based revision parameters with any Git subcommand that uses the revision parameters. More information about which format to use is available in the gitrevisions man pages.

12. Omniscient reflog

Have you ever tried to kill a submission during a change of base and find that you need to keep something in that submission? You may think that this information will never be found and will have to be recreated. But if you submit in your local working copy, the submission will be added to the reference log (reflog) and you can still access it.

Running git reflog will display a list of all activities in the current branch in the local working copy and provide you with the SHA1 value for each submission. Once you find the submission you abandoned when you changed the base, you can run git checkout to jump to the submission, copy any information you need, and then run git checkout HEAD to return to the branch's most recent submission.

This is the end of this article on "sample Analysis of Git Tips". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

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.