You should be aware of the basics of Git

the basics and principles of git using git for version managementGit is a distributed version management system that was created to better manage the development of Linux kernels. Git can save the status of the document as an update record at any point in time. As a result, you can restore the edited document to its previous state, or you can show the difference in content before and after editing. When you edit an old file, when you try to overwrite a newer file (that is, when you upload a file to the server), the system warns you, so you can avoid inadvertently overwriting someone else's edits. figure out a few concepts Repository

A database (Repository) is a place where the state of a file or directory is recorded and the history of the content modification is stored. Under the management of the database, the history of file and directory modification is placed in the corresponding directory. local and remote repository remote databases: A dedicated server, a database created for multi-person sharing. Local database: A database configured on your own machine for the convenience of your personal use. to modify a record's submission

To save the file or directory additions and changes to the database, you need to commit.
After the commit is executed, a discrepancy record (also known as revision) for the state of the last commit and the current state is generated in the database.
The commit is in chronological order and the state is saved to the database. With this submission and the latest file status, you can know the history of past changes and the content.
The system calculates 40 digits in English and numbers that are not duplicated according to the modified content to give the submission a name. Given this name, you can find the corresponding commit work tree and index in the database

Under Git management, the directory that you actually work with is called the working tree.
There is an index between the database and the work tree, which is the area in which to prepare the database for submission.

Database – Index – Work tree

Instead of saving the state of the working tree to the database directly when it executes the commit, Git saves the state set in the intermediate index area to the database. Therefore, to submit a file, you first need to add the file to the index area.
So, with an intermediate index, you can avoid unnecessary file submissions in the work tree, and you can add part of the file modification to the index area and submit it. Install git command line install git

Download the git installer from the GIT website and install it, http://git-scm.com/the initial settings

$ git config--global user.name "< username >"
$ git config--global user.email "< e-mail >"

local new git Repository

$ mkdir Tutorial
$ cd Tutorial
$ git init

So we can create a new local git Repository to create a new file in the database .

Create a new file in the Tutorial directory, and then add the file to the database.
First create a new text file named "sample.txt" in the Tutorial directory, enter the following in the file:

Hello World

View the status of work trees and indexes in a working database

$ git status

Return information:

# on Branch Master
#
# Initial Commit
#
# untracked files:
#   (use "git add <file> ..." to Inc Lude in what would be committed)
#
#     Sample.txt Nothing
added to commit but untracked files present (use "G It add "to track)

From the status response we can see that ' sample.txt ' is not currently a History object. Please add ' sample.txt ' to the index first to track its changes.
To add a file to the index, use the Add command. Specifies the file to which the index is added. You can specify multiple files by separating them with spaces.

$ git add <file>.

Adding sample.txt from the working directory to the Index

$ git Add sample.txt

submit files to local data

In the last step, we have added the file to the index, and then we need to submit the indexed file to the database.

$ git commit-m "summary"

View Commit record

$ git log

share a local database

Usually developed in the time, is generally collaborative development of a project, therefore, the need to share the team of everyone's code base, that is, our previous steps of the local database to establish a connection to the remote database

Create a new database, for example we can create a new database on GitHub and get to the remote database address

    $ git remote add <name> <url>

Enter a name for the remote database where you specify the URL of the remote database.
Is the alias of the remote database the next time you push, you do not need to enter a long string of remote database address, directly using the name push
Such as:
$ git Remote add Origin https://[your_space_id].github.com/git/[your_project_key]/tutorial.git push the local database to the remote database

$ git push <repository> <refspec>

Use the push command to push changes to the database. Enter a destination address at which to specify the branch to push.
With the-u option specified, the branch name can be omitted at the next push. However, when you push the first run directive to an empty remote database, you must specify the remote database name and the branch name.
Such as:

$ Git push-u Origin Master

cloning a remote database to a local database

Use the Clone directive to copy the database, specifying the URL of the remote database,
Specifies the name of the new directory.

$ git clone <repository> <directory>

Note: After cloning to local, we can operate as a cost database, such as new file, add to index, submit to database->push to remote database
When committing to a remote database, you do not need to connect to the remote database because the remote database has been specified by clone to pull the remote database to the local database

Get data updates to a remote database

$ git pull <repository> <refspec>

Use the pull command to push changes to the database. Enter a destination address at which to specify the branch to push. Merging modification Records

After pull is executed, your push will be rejected if someone else pushes the content to the remote database before the next push.
In this case, your push will be rejected until you read the changes from someone else's push and perform the merge operation. This is because if you try to overwrite an existing change record without merging it, the other person's push changes (commit C in the diagram) are lost.

Therefore, each time you commit the code, you need to pull it, merge the change record, and then commit. When merging, Git automatically merges existing change points. However, there is also a case that cannot be merged automatically to resolve merge modification conflicts

If the remote database and the local database are modified in the same place, there will be a conflict because there is no way to automatically determine which modification to use.
Workaround, locate the conflicting file, the file, = = above the split line is the contents of the local database, after the modification, the execution of the submission

The original text has also been published to a personal station