Git study notes

Git study notes

A good scenario-based Git best practice manual (multilingual): github.com/k88hudson/g...

Git version control and storage model

What is Git and why use Git

Imagine a scenario: you have written a file whose version is 1.0. Now you need to modify and optimize the content. You are afraid of losing the original file, so you copy the 1.0 version of the file and make changes on this copy.

The two files can't cause too much trouble. However, in actual study and work, we often encounter multiple files in a project, and each file has been modified a lot. When working in a team, everyone needs to update the progress synchronously. , In order to ensure that the update and communication parts of each will not go wrong. This makes version management very difficult, resulting in a lot of brainpower and labor costs.

Git was born to solve this problem. Git is a version control system that will help workers to record every update submitted, without the workers having to manually create copies, merge updates, and manage version history. In team collaboration, there is no need for a manager to actively distribute history records and new versions to other members. Project members can directly copy, Pull a copy of the same record, create your own work branch, and push your own updates back. After each member completes their tasks and pushes them, the manager checks these branches through Git, merges them, and completes the version update of the total project.

Distributed system, localized storage

Git is designed as a distributed management system. Each machine participating in the project has a complete version library. The submission and modification of the version history is also done locally. For users of this machine, you can quickly switch versions and branches without having to obtain version information through the network.

You need to interact with the version history of other machines, such as cloning, remote push, and unified summary and merge. The network is only needed.

As for the so-called "central server", just for convenience, setting up a server with a clean and complete version history is easy to publish, manage, and standardize. It does not mean that Git is not a distributed system.

Store a snapshot of changes over time (snapshot)

Every time an update is submitted/save the project status, Git will create a snapshot of all the files at that time and save the index/pointer. Of course, there is no need to recreate the snapshot and store the unmodified file, as long as the link is kept and points to the previous file. Therefore, when changing and viewing files of different versions, Git can replace them by changing the index/pointer without recalculating the difference. This is the reason why Git version switching is faster.

3.states

Git divides the folders/files to be version controlled into three parts: workspace, temporary storage area, and version library.

  • Work area, which represents the files that we are currently compiling and modifying, but have not yet submitted to the temporary storage area
  • Staging area, through
    git add
    Save the current state of the workspace as preliminary information that may be submitted to the version library in the future, and you can add coverage multiple times
  • Repository, or Git repository, is through
    git commit
    Save the information in the temporary storage area as the final and official version record and add it to the version library. The content of the version library cannot be modified at will (version rollback is index/pointer rollback and does not really delete the content).

Get started

Install Git

git-scm.com/book/en/v2/...

Configure user information after installation

Set the user name and email address, this setting is necessary . Every Git commit needs a source record in order to work properly.

$ Git config --global user.name "John Doe" $ git config --global user.email "johndoe@example.com" Copy the code

--global
Represents the global configuration. By default, the submission of this machine is run according to this configuration. If you want to change the configuration under a specific project, just run it under that project.
--global
Configuration.

Check the configuration information through the following command, and other configuration parameters can be viewed on the official website document.

$ Git config --list copy the code

View help

$ Git Help config $ git the Add -h copy the code

The above instructions can view the help information of specific instructions in the console,

help
For instructions, see the complete manual, and the examples indicate viewing
git config
instruction of.
-h
It s more concise and is used for quick reference to view the optional parameters of the command.
git add
Parameters. In the content of subsequent learning, many command parameters can be consulted through the above commands.

In addition, it is also very convenient to search for instructions through Git official website, technical forums, search engines, etc.

Git basics

Get the Git repository

There are two ways to create a Git repository locally, either by initializing it locally or by cloning someone else's repository:

Initialize a warehouse in an existing project directory

Enter your project directory and enter the following command to let Git take over the files in the current directory and its subdirectories.

$ git initCopy code

This step will create a

.git
Hidden folders, used for Git work, do not change the contents of this directory at will.

Clone a warehouse from another server

$ Git clone https://github.com/libgit2/libgit2 mylibgit copy the code

by

git clone
, Put on github
libgit2
The warehouse, cloned to our local area, with a custom name
mylibgit
In the directory, we now have the complete version information of the warehouse saved on github, which is the same as the initial warehouse
.git
Folders can be developed directly on this basis.

apart from

https
In addition to the protocol, Git also supports
git://
Agreement, or
SSH
The transmission protocol and specific links will be supported by options on github, gitlab and other remote repositories. In order to clarify users and ensure security, these websites generally require the configuration of the hash authentication key of the local machine, which is used for security verification during communication, and the relevant content will be supplemented later.

Basic operation

The following figure shows the state change cycle of the file:

  • Untracked is not tracked, usually occurs when a new file is created, or the file is removed from the temporary storage area and the version library record
  • Unmodified, literally, the file has not been modified
  • Modified has been modified, as above, after the workspace file has been modified, it has not been submitted to the staging area or version library
  • Staged has been temporarily stored and has not been submitted to the repository

View file status

$ git status On branch master Your branch is up-to-date with'origin/master'. nothing to commit, working directory clean Copy code

git status
Can check which files are newly created/untracked (untracked files, need to pass
git add
Tracking), which files are being modified and have not been temporarily stored, which files have not been submitted in the temporary storage area, etc. It is strongly recommended to check before each submission .

The sample information indicates that the workspace is "clean", which means that no new or modified files have been created or modified. Note that the word master, master refers to the branch we are currently in, and is also the default master branch. The concept of branch can be seen later.

File tracking/adding to staging area

$ Git the Add * .c $ git the Add LICENSE copy the code

If a file is not tracked, then in Git

git status
In the prompt message, it does not indicate that it is modified, and the writing of the new file is always untracked.

by

git add
,Add the untracked or modified work area files to the temporary storage area. A convenient way to add all files is:

$ Git the Add --all copy the code

Submit to the repository

$ Git the commit -m 'Initial Project Version' duplicated code

-m
And the following string, used to mark the description of this submission. Through the above instructions, the contents of the temporary storage area will be submitted, and a new record will be added to the Git repository. Git will automatically generate a hash check value for each submission as a unique identifier for the submission. For subsequent differentiation, switching, etc., you can pass
git log
View ( view history ).

If you want to submit directly from the workspace in one step, you can use

-a
Option to complete temporary storage and submission at the same time, but it is generally not recommended to use this.

Ignore file gitignore

There are some files, such as temporary files, toolkits during development, log files, etc., which generally do not need to be included in Git management. At this time, you can create one in the project root directory

.gitignore
File, in which the mode (ie regular) of the file to be ignored is listed, for example:

*.[oa] *~ Copy code

*
Match all strings, the first line means ignore all
.o
or
.a
The end of the file, the second line is ignored
~
The ending file. More examples are as follows

# Ignore all .a file *.a # But keep track of all lib.a, even if you ignore the .a file in front !lib.a #Ignore only TODO files in the current directory, not subdir/TODO /TODO # Ignore any directory named build folder build/ # Ignore doc/notes.txt, but do not ignore doc/server/arch.txt doc/*.txt # .Pdf files under ignored doc/directory and all subdirectories doc/**/*.pdf Copy code

View modification

$ git diffCopy code

The above command compares the difference between the current work area and the current staging area snapshot, that is, the current file, and

git add
Time file difference

$ Git diff --staged copy the code

plus

staged
Parameter, compare the difference between the current temporary storage area and the latest version library, that is
git add
with
git commit
Differences between files. (You can also use
cached
Parameter, synonymous)

Remove file

$ Git RM filename copy the code

The above command will delete files from the work area and temporary storage area,

git status
Will show that the file has been
deleted
, Provided that the file has not been modified or submitted to the staging area. After the next submission, Git will no longer include the file in version management.

If the file to be deleted has been modified or has been placed in the temporary storage area, give

git rm
plus
-f
Parameter, which means forced deletion.

If you want to remove a file from Git management, but still need to remain in the current working directory, add

--cached
Parameters, subsequent pass
.gitignore
To ignore the file

Move/rename files

Git cannot directly track file movement. Simply renaming a file will be treated as a new file. To rename a file in Git, you can do this:

$ Git mv README.md the README copy the code

Equivalent to the following three commands

$ Mv README.md the README $ git RM README.md $ git the Add the README copy the code

Through this

git mv
, Git can infer that this is a rename, in
git status
, It will display:

$ git status On branch master Your branch is up-to-date with'origin/master'. Changes to be committed: (use "git reset HEAD <file>..." to unstage) renamed: README.md -> README Copy code

View history

by

git log
To view:

$ git log commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon <schacon@gee-mail.com> Date: Sat Mar 15 16:40:33 2008 -0700 removed unnecessary test commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon <schacon@gee-mail.com> Date: Sat Mar 15 10:31:28 2008 -0700 first commit Copy code

In chronological order, the new submission is on the top, listing the hash checksum of each submission, author information, and submission instructions (

git commit -m xxx
)

If you want to display the submitted information in one line, you can use

--pretty=oneline

$ git log --pretty=oneline 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch'experiment' a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 0d52aaab4479697da7686c15f77a3d64d9165190 one more thing Copy code

The more common way is to use

--pretty
Parameters and
--graph
Parameters, you can view historical checksums, branch merge diagrams, etc. more conveniently

$ git log --pretty=format: "%h %s" --graph * 2d3acf9 ignore errors from SIGCHLD on trap * 5e3ee11 Merge branch'master' of git://github.com/dustin/grit |\ | * 420eac9 Added a method for getting the current branch. * | 30e367c timeout code and tests * | 5a09431 add timeout protection to grit * | e1193f8 support for heads with slashes in them |/ * d6016bc require time for xmlschema * 11d191e Merge branch'defunkt' into local Copy code

--pretty=format:
Is a syntax for formulating the output format,
%h
Represents the hash of the output abbreviation,
%s
Indicates output submission instructions.

For specific parameters, please check the official document: git-scm.com/book/en/v2/...

Undo operation

Modification submission

If once due to a mistake, some files are found to have errors after submission, or some files have forgotten to be submitted to the temporary storage area, at this time, you can execute the following command after modifying and adding to the temporary storage area:

$ Git the commit --amend copy the code

use

--amend
Parameters can be resubmitted, so after correct modification, use this command to modify the last wrong submission, for example:

$ Git the commit -m 'Initial the commit' $ Git the Add forgotten_file $ Git the commit --amend duplicated code
Unstaged files

Suppose you pass

git add *
Or other operations, some files have been submitted to the temporary storage area, and now you want to withdraw the operation of a certain file from the temporary storage area, such as README.md, you can use the following methods:

$ Git the HEAD README.md the RESET copy the code

Used here

reset
with
HEAD
Two identifiers, the former represents reset, and the latter is a pointer representing the latest commit currently. It means to change the current file status to the last submitted state, so that the temporary storage area will be restored, and the modification of the work area has not been submitted. on
HEAD
You can view the HEAD pointer

Use now

git status
Check, you will find that README.md is already in
Changes not staged for commit
Classification.

Undo the modification of the workspace

If you want to undo the modification to the workspace file through the Git command, you can overwrite it with the most recently submitted version, which is equivalent to resetting the modification. The command is as follows.

$ Git Checkout - README.md copy the code
Version rollback

If we make a wrong commit, or some solutions are abandoned, we need to go back to a previous version to re-develop, then we need to perform a version rollback:

$ git reset --hard HEAD^ copy code

Here is one

--hard
Parameter, which means to directly reset all work content to the submission corresponding to a certain pointer.
HEAD^
Represents the last submission of the latest submission, one
^
Is just one time in advance, such as
HEAD^^
It means going back twice.... In addition, you can also pass
git log
Check the hash checksum corresponding to different submissions to specify. For example, the first 6 digits of a submitted hash value are
a721c9
, Then you can go back to this submission through the following instructions.

$ Git the RESET --hard a721c9 copy the code

Note here that it does not have to be a 6-digit hash, Git will automatically find the same hash at the beginning based on the value we enter. For example, if there is no repetition, it is possible to enter the first 4 digits. If there are repetitions, it is time to enter a few more digits.

Tag the submission

What is the label?

Generally speaking, the tag (ie Tag) represents the tag, name, version number and other content of a certain submission, such as v1.0, v2.0-beta. with

git commit -m
Different, the latter is generally a general description of the content of this submission, such as what has been modified and what has been added. This difference must be clearly distinguished.

View tag history

Very simple, the example is as follows:

$ git tag v0.1 v1.0 v1.1 Copy code
Create label

Git has two types of tags, lightweight and annotated.

The former is a submitted citation, and the latter has more information than the former, such as the name of the tagger, email address, date and time, etc. The official website recommends creating a note label because it has more traceable information.

  • An example of creating a note label is as follows:
$ Git V1.4 Tag -a -m "My Version 1.4" Copy the code

The above instructions passed

-a
created
v1.4
The tag passed
-m
Added label description.

by

git show v1.4
You can see the submission information of the label and the submission information of the corresponding commit.

  • An example of creating a lightweight label is as follows
$ git tag v1.4Copy code

It is a lightweight label without any parameters, in

git show v1.4
In, there is only the submission information of commit, but the submission information of no tag.

  • An example of tagging historical submissions is as follows
$ Git Tag -a v1.2 9fceb02 copy the code

Just add a submitted hash afterwards.

Push label

By default, tags will not be transmitted to the remote warehouse server, so you need to push tags manually. The instructions for pushing tags are as follows:

$ Git the Push Origin V1.4 copy the code

The above instructions push the v1.4 label to the remote origin repository (the concept of origin will be described in the remote server later).

If you want to push multiple tags, you can use the following command:

$ Git the Push the --tags Origin copy the code

The above command pushes all tags that are not on the remote server

Remove label

Delete local label:

$ Git Tag -d V1.4 copy the code

Delete remote tag

$ Git the Push Origin --delete 1.4 Copy the code

Git branch

Perceptual cognition

The branch function of Git is the core that needs to be mastered.

In the theoretical part at the beginning of the document, we mentioned that Git creates snapshots for different versions of files, and uses indexes/pointers to point to different snapshots to achieve rapid version switching.

So the concept of [branch] is actually very simple. Suppose we have the original version of a file, called V0, and use the default pointer master to point to this version. When we submit the update to V1, V0 -> V1 will form an ordered reference relationship. V0 points to V1. Now visit the master, the V1 version of the file will be displayed.

At this time another member came, so the two decided to develop a part of each and then merge, so each cloned a project from the central server. Suppose you update the V1 version of the file to V2-1, which is represented by the pointer dev1, and he updates the file to V2-2, which is represented by the pointer dev2. At this time, there is a bifurcation relationship between V1 and V2, that is, the master pointer of V1, there are two paths to go forward, but the results of these two paths are incomplete, how to merge into the real V2, and then let Does the master point to V2?

Now the two have adopted the following scheme: a new pointer called pre is created to point to the master, which is V1, to indicate the meaning of pre-release. Now the two have merged their respective parts into pre, and pre has now become V2. At this time, we review the changes in all pointers:

pointerChange path
masterV0 -> V1
dev1master -> V2-1
dev2master -> V2-2
premaster -> V2 (Merge the contents of the files of dev1 and dev2)

It can be seen that the version changes of the entire file are called [branch], which is very vivid. After checking that there is no problem, we let the master pointer follow the path of the pre pointer, and now the master points to V2! If you want to continue to update the version, pull the master file again, and then repeat the previous idea.

The above content involves operations such as branch creation, switching, and merging.

Basic operation

HEAD pointer

The HEAD pointer is a concept, which can be intuitively understood as that HEAD always points to the latest commit under the current branch.

In the previous operation, we have to switch between different branches. We [see] different versions of files under different branches. To [see] master, dev1, dev2, we need an [eye], This [eye] is the HEAD pointer, which is the active pointer that we often use when we write some data structure algorithms, such as trees and linked lists.

For example, when HEAD points to dev1, what we see is the latest file snapshot of dev1, and when it points to master, what we see is the file snapshot of master.

Create branch

$ Git Branch dev1 copy the code

The above instruction creates a branch named dev1 with a pointer to the current file, which is HEAD.

View branch

$ git branch dev1 * master Copy code

*
Indicates which branch is currently in.

Switch branch

$ Git Switch dev1 copy the code

If you want to switch branches while creating, you can use

-c
parameter.

When you submit a new version under the dev1 branch, both the dev1 and HEAD pointers will move forward, but the original master branch will not move forward.

Branch merge without divergence

Now suppose that the development under the dev1 branch has been completed and submitted, and now we need to modify the second requirement on the basis of the master, we first switch back to the master branch:

$ git switch masterCopy code

At this time, the HEAD pointer returns to the position of the master, and the content of the work area is also restored to the state of the master. We create the dev2 branch to modify and submit, the steps are the same as dev1.

Now we merge the newly added content of dev2 to master:

$ git switch master $ git merge dev2 Updating f42c576..3a0874c Fast-forward index.html | 2 ++ 1 file changed, 2 insertions(+) Copy code

merge
It is a merge command to merge the contents of the target branch into the current branch. We found that the output information has
Fast-forward
This word means fast forward. This is due to the changing relationship between dev2 and master, which is a straight line. You can directly move the master pointer to dev2 to complete the update.

Delete branch

Now dev2 is useless, we delete it.

$ Git Branch -d dev2 copy the code

Divergent branch merge

Now we want to add the work content of dev1 to the master. Obviously, there are some differences between this and the merging of dev2: the content of dev1 comes from earlier history, and there is no modified part of dev2. If you directly move the current master pointer to dev1, the content of dev2 will be lost. At this time, you will encounter some additional conditions:

The contents of files changed by different branches have cross-conflict parts

For example, two branches change the same part of the same file. This situation is very common. For example, dev1 puts a function at the top, and dev2 also adds a function to the top. Our idea is to have both functions There are at

git merge
When, the following will happen:

$ git switch master $ git merge dev1 Auto-merging Test1.txt CONFLICT (content): Merge conflict in Test1.txt Automatic merge failed; fix conflicts and then commit the result. Copy code

These prompts indicate that there is a conflict in the merge. At this time, open the file, there will be the following conditions:

Git automatically performed special processing on the file, and at the same time there were modifications to dev1 and dev2,

<<<<<< HEAD
with
======
Between represents the current master's changes to the historical files, that is, the result of dev2 (we merged dev2 to master first). and
>>>>>> dev1
with
======
Between represents the changes of dev1 that are now to be merged.

At this point we can manually process the two parts, such as deleting

<
with
=
These conflict prompt information, and then organize the format, proceed
git add
with
git commit
That's it.

There are no cross conflicts between changes in different branches

This situation is also very common. When multiple people write code, they will always be divided into file modules, and different people will write different files. The merge at this time will proceed normally , and the snapshots of the two branches and the nearest common root node of the two branches will be merged into a new commit .

For example, the change of dev2 is to create a new file, not to modify the source file. At this point, we repeat the previous process and merge the master pointing to dev2 with dev1:

$ git switch master $ git merge dev1 Merge made by the'recursive' strategy. Test1.txt | 1 + 1 file changed, 1 insertion(+) Copy code

Although the master and dev1 are in different branch routes at this time, the previous conflict will not occur at this time, but the respective parts are directly superimposed to form a new commit.

Rebase of branch management

As we mentioned before, the common way to merge branches is to use

git merge
, The principle is to merge the contents of the two branches and the nearest public root node into a new commit:

So what does Rebase mean?

Common Rebase examples

According to the above picture, logically, we can also not perform violent merge, but first compare the difference between C4 and C2, record the changes, and then add to C3 to form a new submission, experiment redirection After confirming that the submission (the meaning of the word Rebase is to change the benchmark) is correct, we can let the master go one step further. This is the function of Rebase:

$ git checkout experiment $ git rebase master 1. rewinding head to replay your work on top of it... Applying: added staged command Copy code

It can be seen that the experiment has been transferred from the original C4 to C4', and the content of the file is equivalent to the original C5. At this time, pass

git merge
, Let the master step forward.

$ Git Checkout Master $ git Merge Experiment copy the code

Some people may ask, what use does such an operation seem to be useful for? In fact, from the perspective of results, natural and

git merge
The final result is the same, but the advantage is that the submission history is more tidy and beautiful, from
git log --graph
You can see that multiple bifurcations become a straight line. Developers can first branch their dev developers locally and rebase to behind the master. At this time, the dev is already in the merged state, and the master has not changed. In this way, project managers can quickly merge code directly, reducing the pressure of integration, and also meet the needs of code cleanliness and obsessive-compulsive disorder, especially for Git repositories with multiple members and multiple branches.

More complex Rebase example

The example in the figure can be assumed as the following situation: At C2, the project is split into two parts, one of which is the underlying backbone code of the master, the other is the specific application development started by C3, and C3 is divided into two parts , Namely server server and client client.

If the client has been developed at this time and wants to join the master, but the server has not been completed yet, it cannot be merged with the client and the C3 root node. It can be used at this time

git rebase
, Let the changes of C8 and C9 be added to the snapshot of the file where the master is located, the picture becomes the following effect:

The specific code is as follows:

$ Git rebase the --onto Master Server Client copy the code

The meaning of this command is to use the root node when the client and server start to diverge as the benchmark (C3), compare with the client, obtain the changes of C8 and C9, and then add them to the branch where the master is located to form a new path, and then the client The pointer points to the final result.

Then just move the master pointer as before:

$ Git Checkout Master $ git Merge Client copy the code

The new submission history is as follows:

Now that the server server has been developed, we need to rebase its updated content to the master branch. Our previous steps are to switch to the branch to be rebase, such as client, and then specify the target branch. Now we can use a more complete syntax to directly rebase the branch without switching branches:

$ Git rebase Master Server Copy the code

The meaning of the above instructions is very clear, which means that the changes of the server branch are submitted to the snapshot of the master branch. The submission history becomes the following picture:

Then let the master branch move on, and delete the server and client branches:

$ Git Checkout Master $ git Merge Server $ git Branch -d Client $ git Branch Server -d Copy the code

The submission history finally becomes a clean straight line, amazing!

Don't use Rebase arbitrarily

The shortcomings of Rebase are also obvious. If you pay attention to it, you will realize that Rebase will destroy the previous branch history, such as the original path of client and server in the above example, so if others may develop based on certain branches, then don't use it. Rebase destroys these branches!

If you follow this golden rule, there will be no mistakes. Otherwise, the people will hate you, and your friends and family will laugh at you and spit on you.

In fact, in the original example, it is very unwise to destroy the client and server branches. Because the client and server in the actual project will also be a relatively independent topic branch, they are often version controlled in the central Git repository. Front-end and back-end personnel will develop on the client and server respectively, and the project is constantly iterating. These topic branches should Is reserved.

For more puzzling and painful negative examples, please refer to the Rebase chapter of the Git official website.

Rebase VS Merge best practices

Before we get the answer, we need to rethink what Merge and Rebase mean to commit history.

The Merge operation itself is a record of history, which can trace the changes of various branches. Even though the submission history may seem complicated and confusing, the value and significance of tracing history is eternal.

Rebase destroys the process of change, leaving only the version judged to be "officially published". As for the "draft" in the middle, it is discarded. The advantage is that as users, we can focus on the most necessary research. No need to waste time and energy elsewhere.

The official Git website gives a principle, which I think is more accurate:

The general principle is to only perform rebasing operations to clean up the history of local modifications that have not been pushed or shared with others, and never perform rebasing operations on commits that have been pushed elsewhere. In this way, you can enjoy the convenience brought by the two methods.

The Git submission that needs to be pushed elsewhere means that it will be developed and researched by others, which is in line with the reason for not using Rebase indiscriminately.

Remote Git repository

Now we have mastered most of the common local operations of Git, enough to deal with the general problems in version control, and manage our own projects. Now comes the last step, that is, how to collaborate with others, how to use remote warehouses for development, and know how

clone
,
push
,
pull
,
remote
Concepts such as GitHub, GitLab and other well-known remote Git warehouse hosting services.

In addition, remote Git warehouses can also be built by themselves, but in most cases, developers will use existing hosting services, so this part will not be emphasized. If necessary, please refer to the official documentation.

Transfer Protocol

The first step of network communication is to determine a communication protocol. Here we don t talk about the too principled part. We use

git clone
The command is the entry point to illustrate the role played by the protocol during actual development.

$ Git clone git@github.com: xxxx/xxxx.git $ git clone https://github.com/xxxx/xxxx.git copy the code

The above two statements are common examples of clones of remote projects saved on GitHub. The first is the url under the SSH protocol, and the second is the url under the HTTPS protocol. The actual content they cloned is the same, but the protocol Different. Other remote Git services such as GitLab are similar. The URL representation method may be different, but the essence is the same.

Generate SSH public key

In order to ensure security, many Git servers use SSH keys for authentication to distinguish, authenticate, and trace specific development machines, control permissions, and so on. Taking GitHub as an example, you need to do two things:

  • Generate the local SSH key pair locally, generally by entering system commands through the console to generate
  • Find the local key file and add the public key in the key pair to the trust list of GitHub

After completing the above work, you can download and upload the project normally. For specific operations, please refer to the SSH key guide on GitHub: help.github.com/articles/ge...

Basic operation of remote interaction

Associate with remote warehouse

There are two cases of [association] here, one is that there is no existing project locally and it needs to pass

git clone
To download a project to the local, in this case, the local warehouse and the remote warehouse will be automatically associated. Another situation is that there are ready-made projects locally, and the remote associated warehouse needs to be added or changed. Now suppose we have a local warehouse named learngit, now we create a warehouse with the same name on GitHub, and then execute the following instructions locally:

$ Git the Add Remote git@github.com Origin: yourname/learngit.git copy the code

We can analyze the above instructions like this:

remote
On behalf of remote,
add
Is to increase the order,
origin
It is the name of the remote warehouse. The word origin is usually used in practice, and the following URL is the address of your git warehouse, here
yourname
It's just an example. It's actually your GitHub account name. This is easy to check. After you create a Github repository, its url address can be viewed. Both SSH and HTTPS versions of the url can be viewed.

If you want to modify the URL of the remote warehouse, you only need to execute the following commands:

$ Git Remote git@github.com the SET-url Origin: yourname/learngit.git copy the code

Use here

set-url
To make changes.

To view remote warehouse information, you can use the following command:

$ git remote -v origin git@github.com:yourname/learngit.git (fetch) origin git@github.com:yourname/learngit.git (push) Copy code

-v
The parameter executes the information view of the remote library, the following
fetch
with
push
Indicates that the remote warehouse can perform acquisition or push behaviors.

If you want to remove the association with the remote warehouse, you can use

rm
instruction:

$ Git Remote RM Origin copy the code

View/track other remote branches

by

git clone
Download to the local warehouse, use
git branch
You will find that there is only one
master
Branch, if you need to develop based on other remote branches, you need to use
-a
Parameter view:

% Git Branch -a copy the code

-a
Parameter will list local and all remote
remote/origin/XXX
Branch, at this time we need to create a new branch locally and establish an association with a remote branch:

$ Git Checkout -b mydev Origin/mydev copy the code

Created here

myDev
Branch and synchronize the content with the remote warehouse of the same name. At this time, you can develop and push to the corresponding remote branch. Similarly, local
master
The branch defaults to
origin/master
Branch correspondence.

To view the remote branch corresponding to a local branch, you can use the following command:

$ Git Branch -vv copy the code

Push to remote warehouse

$ Git the Push -u Origin Master Copy the code

The above command pushes the local master branch to the remote origin warehouse, which uses

push
Command and
-u
Parameters, the former means remote push, the latter means to associate the local master with the remote master, and use it directly when pushing in the future
git push
Simply simplify the command. Of course, under normal circumstances, in order to prevent mistakes, it is recommended to write the name of the local branch and remote warehouse, reminding yourself not to submit the wrong branch.

If you are developing based on other remote branches as described earlier, just follow the steps below:

$ Git Checkout Origin -b dev/dev copy the code

Associate the local branch with the remote branch, so that you can develop based on the dev branch, and then push:

$ Git the Push Origin dev copy the code

Pull the remote branch update to the local

The actual development is multi-person collaboration. When you develop locally, there may be some updates in the remote warehouse, so you need to merge the latest content first, organize it and then submit it for upload.

$ git pull copy code

The above command will try to get the branch of the origin remote warehouse to the local, and proceed

merge
operating. Sometimes it may fail because the local branch and the remote are not exactly the same. At this time, the relationship between the specified local branch and the remote branch to be pulled needs to be displayed. For example, the current local is
dev
Branch, nothing with remote
origin/dev
Branch association, then it cannot be identified and pulled, and needs to be set manually:

$ Git Branch the --set upstream-to-Origin =/dev dev duplicated code

Proceed again

git pull
That's it.

As mentioned earlier,

git pull
The second step is
merge
, The operations required at this time are the same as the previous branch management. After the merged content is processed, updated, and submitted to the local repository, proceed
git push
To:

$ Git the commit -m "FIX env Conflict" $ git the Push Origin dev copy the code