GIT Foundation II

Xxxxxxxxxxxxxx version Fallback xxxxxxxxxxxxxxxx
Each git commit stores the current state of the file, which is called a snapshot;
Easy fallback to different version status;

git log
View different versions of the repository, log information

git log--pretty=oneline
Simplifying log information
Return information structure:
The ID number (version number) of the commit is interpreted at commit

Git reflog
More useful than the last two commands, as well as returning information from different versions of the repository
Return information structure:
Simplified version number [email protected]{number} operation type: information when the operation

Note: The type of operation, typically Commit,reset (a command returned to a repository)

Note: The head and the simplified version number are the same, the version number, the form is different

Note: This command differs from git log in that when you return to a version,
Git log does not display all of the log information and is displayed to the current version location;

Git reflog will record every time

Fallback to a version
Git reset--hard version number
Or
git reset--hard [email protected]{number}-------through Git reflog view

Version number via git log;git reflog; view

Note: Understanding the keyword Head, equivalent to a pointer, points to a different repository where the repository resides

How easy is the version to fallback to the latest version location?
1. First step, see through Git reflog
2. Step two, return to the specified version via git reset--hard version number

How do I see which version I'm currently in?
1. The first method:
With Git log, only the logs from the original version to the current version will be displayed.

2. The second method:
git reset--hard HEAD
Head is a pointer to the version that is currently in place
Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Modify Undo

1. Undo the changes in staging area
Git reset HEAD file name
This is staging area without the file, the file returns to the workspace

Note: Git reset not only can be rolled back, but it can also undo the changes in staging area
Head indicates the latest version

2. Git checkout--file name
2.1 If the file is in the workspace, will be modified to undo, back to the latest version status
In this case, directly open the file modification can
2.2 Files in staging area, nothing changed

Attention:
Even if the file is in staging area, it is not always possible to undo all the changes, this is the file that can be opened again in the workspace,
After the modification, add again, and it is staging area that the file is the file that was just changed

**********************************
deleting files

*********************************
Remote Warehouse

Set up the warehouse in the server, each client can clone the warehouse to local;
Git local repository and GitHub warehouse transfer requires SSH encryption

The local repository interacts with the GitHub repository, why do I configure the ssh file?
The communication between the client and GitHub follows the SSH protocol, so it needs to be set on the client, server side
1. Set SSH keys locally in git
2. Fill in the appropriate settings for the GIT local key in GitHub
This way, GitHub knows which user to interact with

Other people can clone your warehouse, but can't submit changes, etc., read-only and do not write

To set up a git ssh file locally
1. Set SSH key
In the Home/xubiao directory, see if the. ssh file exists
". SSH indicates that the file is hidden and needs to be used when displaying the Ls-a"

Is there a id_rsa id_rsa.pub file in the. SSH directory

If it does not exist, create these two files, which are the files that store the secret key
Create statement: SSH-KEYGEN-T rsa-c Mailbox

The next step is that you don't need to enter anything;
The command statement is entered in the. SSH directory, which generates the above two files in the. SSH directory

2. Fill in the keys in Id_rsa.pub into GitHub
After completing the key in GitHub, verify the GitHub password

Connect to a remote repository?
Prerequisite: SSH must be configured

1. Remote repository exists, cloning directly on the client
git Clone remote Warehouse address

At this point the client-cloned repository has been linked to the remote repository;
When committing, the following statements can be executed directly:
Git push-u Origin Master
-U indicates that the client Master branch is merged with the remote Master branch when the first commit

2. Create the warehouse locally, the server is an empty warehouse
First, the local warehouse, the remote warehouse to establish contact
Git remote add origin repository address

Second, submit
Git push-u Origin Master

There are two ways to connect a remote repository:
1. Address via SSH Protocol 2. Address via HTTPS protocol
SSH protocol is not required to enter GitHub username/password when mentioned

Attention:
Whether the local warehouse is a cloned remote repository, a new local warehouse, and a connection to the remote warehouse,
You don't need to enter GitHub's account/password at the time of submission, as long as it is via the SSH protocol.
With the HTTPS protocol, you need to enter GitHub's account/password

There are two protocols for interacting with the remote repository: HTTPS,SSH
It is recommended to use SSH with fast speed

GIT Foundation II