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

This article mainly explains "what are the skills of using Git". Friends who are interested may wish to have a look. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "what are the skills for using Git?"

1. Your ~ / .gitconfig file

When you use the git command to submit changes to a repository in *, you may first see something 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 be aware that those commands are modifying the contents of the ~ / .gitconfig file, which is the file where Git stores global configuration options. You can do a lot of things through your ~ / .gitconfig file, including defining aliases, turning * * on (or off) specific command options, and modifying aspects of 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 to a repository based on the path! Use "man git-config" to see all the details.

two。 The .gitconfig file of your warehouse

In the previous tip, you might want to know what the-global flag does in the git config command. It tells Git to update the "global" configuration, which is the configuration found by ~ / .gitconfig. Of course, having a global configuration represents a local configuration, and to be sure, if you omit the-global option, git config will update the repository's own configuration, which is stored in .git / config.

The option set in .git / config overrides the corresponding setting in the ~ / .gitconfig file. So, for example, if you need to use a different email address in a particular warehouse, you can run "git config user.email" also_you@example.com ". Then, if you submit it in this warehouse, you will use the email address that you configured separately. This is useful if you use a working computer to work in an open source project, but want to use a personal email address in this project, while others still use a working mailbox in the main Git configuration.

Anything that can be set in ~ / .gitconfig can be set in .git / config to make specific settings for this repository. In the following tips, when I mention what to add to your ~ / .gitconfig file, it also indicates that you can 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 your ~ / .gitconfig file. It works like an alias on the shell command line-setting a new command name to invoke one or more other commands, which usually include specific options or identities. Aliases are very effective for long and complex command lines that you often use.

You can use the gitconfig command to define aliases-for example, executing the "gitconfig-global-add alias.st status" command makes executing git st do the same thing as executing git status-however, I find that when defining aliases, it is usually easier to edit directly in the ~ / .gitconfig file.

If you choose to do this, you will find that the ~ / .gitconfig file is an INI file, and INI is a basic key-value file format with specific paragraphs. When adding an alias, you will change the [alias] paragraph. For example, for the git st alias with the same definition mentioned above, you need to add the following code:

[alias] st = status

(if you already have the paragraph [alias], you only need to add it to the second line in this paragraph)

4. Aliases in the shell command

Aliases don't just run other shell subcommands-you can also define aliases that run other Git commands. This is a good way to handle a repetitive, rare, complex task: once you've figured out what to do, save the command with an alias. For example, I have several repositories that I fork an open source project and make some changes locally that do not need to be contributed to the project. I want to keep the version of the project during the continuous development of the project, while keeping my local changes. To accomplish this idea, I need to periodically merge these changes from the upstream repository into my fork-- I define an alias "upstream-merge" to do this. The definition is as follows:

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

Alias definition begins with this "!" Is to tell Git to run this command through shell. This example includes running some git commands, but defining aliases in this way allows you to run any shell command.

Note: if you want to copy my upstream-merge alias, you will need to make sure that you have a Git remote named upstream to specify the upstream repository of your fork. You can add one through "git remote add upstream".)

5. Visual submission map

If you are working 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 GUI tools allow you to get an overview of the different branches and submit records in the so-called "submit diagram". For example, here is a partial screenshot of a memory card that I used the GitLab submission Viewer to visualize:

John Anderson, CC BY

If you are a command-line focused user, you can avoid distractions from switching between multiple tools, which implement a graphical interface-like submission view on the command line. Get the record of git through the-- graph parameter:

John Anderson, CC BY

The following command can get the same visual fragment of the warehouse:

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 chart to the left side of the log,-- the abbrev-commit storage submission uses the SHA method,-- the date=relative expression represents the date in relative terms, and-- pretty handles the custom format in bit format. I know the alias for git lg, which is one of the 10 commands I run most often.

6. More elegant forced push (force-push)

Sometimes, just as difficult as you try to avoid using it, you will find that you need to run git push-force to overwrite the history on the remote copy of your repository. You may have received some feedback that will ask you to make an interactive rebase, or you may have screwed up and want to hide the evidence.

The risk 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, some 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 perform a forced push, which will ensure that you do not throw away other people's work.

7. Git add-N

Have you ever used git commit-a to submit all your outstanding changes in one action, and only after you push your submission did you find that git commit-an ignored the newly added files? To solve this problem, you can use git add-N ("notification") to tell Git that you want to include the newly added file in the submission before your actual submission.

8. Git add-p

The practice of * is to ensure that each commit contains only one logical change when using Git-whether it's fixing a bug or (implementing) a new feature. However, sometimes when you are working, there will be more than one change submission in your warehouse. How do you separate things so that each submission contains only the appropriate changes? git add-patch to save!

This flag will cause the git add command to view all changes in your working copy, asking if you are willing to commit, skip, or postpone the decision (there are other more powerful options that you can choose after running this command? To check). Git add-p is a magical tool to produce well-structured submissions.

9. Git checkout-p

Similar to git add-p, the git checkout command uses the-- patch or-p option, which causes git to show each "chunk" of changes in the local working copy and allows the corresponding changes to be discarded-simply restore the local working copy to the state it was before you changed it.

This is useful in some scenarios, for example, when you introduce a bunch of debug log statements when tracking a bug, after correcting the bug, you can first use git checkout-p to delete all newly added debug logs, and then use git add-p to add bug fixes. There is nothing more satisfying than combining an excellent, well-structured submission!

10. Rebase with command execution

Some projects have a rule that every commit in the repository must be workable-that is, the code should be compilable at each commit, or running the test suite should not fail. When you work long hours on a branch, but if you end up needing rebase for some reason, it can be tedious to skip each rebased commit to make sure you don't accidentally introduce an interrupt.

Fortunately, git rebase already supports the-x or-- exec option. Git rebase-x will run the command after each submission applied to rebase. So, for example, if you have a project in which npm run tests will run your test suite, git rebase-x npm run tests will run the test suite after each submission of the application during rebase. This allows you to see if the test suite has failed in any rebased commit, so you can make sure that the test suite still passes each commit.

11. Guidelines for time-based modification

Many Git subcommands accept a modified parameter to determine which part of the warehouse the command acts on, which may be the sha1 value of a particular commit, or the name of a branch, or a symbolic name such as HEAD (which represents a commit of the current checked-out branch). In addition to these simple forms, you can also attach a specified date or time as a parameter. Stands for "reference to this time".

This feature can be very useful at some times, for example, when you deal with bug that appears, you say to yourself, "this function is obviously fine yesterday, but what has changed?" instead of staring at the output of the full screen of git logs to try to figure out when the submission was changed, you just run git diff HEAD@ {yesterday} and you will 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 modification parameters with any Git subcommand that uses the correction parameters. More information about which format to use is available in the gitrevisions man pages.

twelve。 Omniscient reflog

Have you ever tried to kill a submission on rebase and then found out that you need to keep something from this submission? You may think that these submitted things will never be found and will have to start all over again. This is not true, but if you submit in a local working copy, the submission will go to the "reference log" and you can still access it.

Running git reflog displays a list of all activities in the current branch in the local working copy and provides you with the SHA1 value for each submission. Once you find the submission that was abandoned when you rebase, you can run git checkout to check out the submission, copy the information you need, and then run git checkout HEAD to return to the branch * submission.

At this point, I believe you have a deeper understanding of "what are the skills for the use of Git?" you might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.