git Concise tutorial

• • • The birth of Git
    • Centralized vs Distributed
    • Install Git
    • Create a repository Repository
    • Add files to the GIT library
      • 1 adding readmetxt file contents to Repository
      • 2 First Step
      • 3 Step Two
      • 4 git status
    • Version fallback
      • Representation of the 1 version
      • 2 Summary
    • 7 working area and staging area
      • 1 undo Changes
      • 2 Summary
    • deleting files
    • Remote Warehouse
    • associating with remote libraries
      • 1 Push the contents of the local repository to the GitHub repository

1. The birth of Git

Linus created the open source Linux in 1991, before 2002, volunteers from all over the world sent the source code files to Linus by diff, and then Linus himself merged the code by hand! Because the centralized version control system is not only slow, but also must be networked to use, paid, and the Linux open source spirit does not match.
BitKeeper's owner, BitMover, has granted the Linux community free access to this version control system in the spirit of humanitarianism. Andrew, who developed samba, tried to crack BitKeeper's agreement and was discovered by BitMover (BitKeeper reverse engineering).
So Linus spent two weeks writing a distributed version control system in C, which is git! Within one months, the Linux system's source code has been managed by Git! The GitHub website was launched in 2008 and provides free git storage for open source projects. Git is based on the DAG structure (Directed acyclic Graph) and is the fastest SCM (software configuration Management) system.

2. Centralized vs Distributed

Centralized version control system, the repository is centrally stored in the central server, and work, with their own computers, so the first from the central server to obtain the latest version, and then began to work, finished work, and then put their own live push (push) to the central server. Centralized version control system The biggest problem is the need to network to work, Git commits no need to network, and finally push to the remote server is required.
As the earliest open source and free centralized version control system, CVS has been used by many people until now. Due to the problem of the design of CVS, the file is incomplete and the repository is inexplicably corrupted. Also open source and free SVN fixes some of the stability issues of CVS, which is currently the most used centralized repository control system.
Distributed version control system does not have a "central server", everyone's computer is a full version of the repository. Compared with centralized version control system, the security of Distributed version control system is much higher, because everyone's computer has a complete version of the library, a person's computer is broken do not matter, casually from other people to copy one. Centralized version control system central server if there is a problem, everyone can not work. Distributed version control system usually also has a "central server" of the computer, but the role of this server is only to facilitate "exchange" everyone's changes, without it everyone also work, just exchange changes inconvenient.

3. Install git

Mac: Install git via homebrew, please refer to Homebrew's documentation: http://brew.sh/.
Windows:msysgit is a Windows version of Git, downloaded from http://git-scm.com/, and then installed by default. When the installation is complete, find Git Bash in the Start menu, enter

$ "Your Name"$ git config --global user.email email@example.com

The –global parameter of the git config command uses this parameter to indicate that all of your git repositories on this machine will use this configuration, but you can also specify a different user name and email address for a particular repository.

4. Create a version library repository

Choose a suitable place to create an empty directory (do not include Chinese, write files in plain text, UTF-8 encoding)

$ mkdir learngit$ cd learngit$ pwd$ git init

The git init command turns this directory into a repository that git can manage, with one more. Git directory under the directory that tracks the management repository.

5. Add file to git Library 5.1 add Readme.txt file in Repository, content:

Git is a version control system.
Git is free software.

5.2 First Step

Use the command git add, note that can be used repeatedly, add multiple files;

add readme.txt

Execute the above command without any display, that's right, the Unix philosophy is "No news is good news", stating add success.

5.3 Step Two

Use the command git commit to tell git to commit the file to the repository:

$ "wrote a readme file"

-M followed by the instructions for this submission
Commit can submit many files at once, so you can add different files multiple times

5.4 Git status

The git status command allows us to keep track of the current state of the repository. Specifically modified what content, you need to use Git diff this command to see, after reading the changes, submit files to the GIT library:

$ git add readme.txt$ git status$ "add distributed"$ git status

To keep track of the status of your workspace, use the git status command.
If Git status tells you that a file has been modified, use Git diff to see what's changed.

6. Version fallback

Use the git log command to view the history in the repository, showing the commit log from the most recent to the farthest. Plus –pretty=oneline parameter: summary information

log--pretty=oneline

Ea34578d5496d7dd233c827ed32a8cd576c5ee85 Add distributed
cb926e7ea50ad11b8f9e909c05226233bf755030 wrote a readme file
A large string similar to 3628164 ... 882E1E0 is the commit ID (16 binary version number).
Use the Git GUI diagram to submit the history.

Representation of the 6.1 version

In Git, the current version is represented by head, which is the latest commit 3628164 ... 882E1E0 (Note that my submission ID and your affirmation is not the same), the previous version is head^, the last version is head^^, of course, to 100 versions write 100 ^ more easy to count, so written head~100.

Fallback version using the git reset command:

$gitreset--hardHEAD^

Back to the previous version.
Using git log has not been able to see the latest version, can't Go back, method: Through the Commit ID, you can specify back to a future version:

$gitreset--hard3628164

Git's version fallback is very fast because git has a head pointer to the current version inside, and when you roll back the version, git simply points the head from the append GPL to the add distributed and then updates the workspace file.

When you head^ back to the Add distributed version with $ git reset–hard, you'll have to find the append GPL's commit ID if you want to revert to the append GPL. git provides a command git reflog is used to record every command you make.

6.2 Summary

The version that head points to is the current version, so git allows us to navigate between versions of history, using the command git reset–hard commit_id. Before the shuttle, use git log to view the commit history to determine which version to fallback to. To return to the future, use Git reflog to view the command history to determine which version to go back to in the future.

7. Work area and staging area

Workspaces: Directories You can see on your computer. Repository (Repository): Hidden directory (. git) in the workspace. Git has a lot of stuff in its repository, the most important of which is the staging area called stage (or index), and the first branch master that git automatically creates for us, and a pointer to master called head.

Adding files to the Git repository is done in two steps: The first step is to add the file to git add, which is actually to add the file to the staging area, and the second step is to commit the change with git commit, which is actually to commit all staging area content to the current branch at once.

For example, to modify Readme.txt in Respository, add the Readme.md file. After executing git add two times, the file was backed up from the workspace to staging area and not in the repository. Then, execute git commit to commit all the staging area changes to the branch at once.

Add a lot of files, but there is one that does not want to add: first put a large number of files once add in:
git add *.py, for example, added 1.py, 2.py, 3.py, 4.py. To exclude one of the files, use: Git reset HEAD 1.py then with git status, 1.py becomes untracked, the rest can be submitted.

7.1 Undo Changes

Git checkout–file can discard changes to the workspace:

$gitcheckout--readme.txt

Readme.txt files in the work area of the changes are all revoked, there are two cases: one is Readme.txt since the modification has not been put to staging area, now, undo changes back to the same state as the repository, one is the Readme.txt has been added to the staging area, and modified, now, undo the changes back to The state after adding to the staging area. All in all, let this file go back to the state of the last git commit or git Add. The git checkout–file command – very important, no – becomes the "Create a new branch" command, and we will encounter the git checkout command again in later branch management.

If you add the modified readme git to staging area, there is no commit. Use the command git reset HEAD file to undo the staging area modification (unstage) and re-put it back in the workspace.

7.2 Summary:

Scenario 1: When you mess up the contents of a file in your workspace and want to discard changes to the workspace directly, use the command git checkout–file. Scenario 2: When you not only changed the contents of a file in the workspace, but also added to the staging area, want to discard the changes, two steps, the first step with the command git reset HEAD file, back to scene 1, the second step by scene 1 operation. Scenario 3: When an inappropriate modification to the repository has been submitted, you want to revoke this commit, refer to the version fallback section, but only if it is not pushed to the remote library.

8. deleting files

First add a new file Test.txt to Git and commit:

$ git add test.txt$ "add test.txt"

Delete the unused files directly in the File Manager, or delete them with the RM command:

$ rm test.txt

Git knows that you deleted the file, so the workspace and repository are inconsistent, and the git status command immediately tells you which files were deleted. Now that you have two options, one is to remove the file from the repository, delete it with the command git rm and git commit:

$ git rm test.txt$ "remove test.txt"

The other is wrong, because the repository is still there, so it is easy to restore the deleted files to the latest version:

$gitcheckout--test.txt

Git checkout is actually replacing the workspace version with the version in the repository, which can be "one-click Restore", regardless of whether the workspace is modified or deleted.

9. Remote Storage

1th step: Create SSH Key. In the user home directory, see if there is no. ssh directory, if there is, then look at this directory there are no Id_rsa and id_rsa.pub these two files, if already have, can jump directly to the next step. If not, open the shell (open git Bash under Windows) and create SSH Key:

$ ssh-keygen-t-C [email protected].com

You need to change your email address to your own email address, then return to the default value, so you don't have to set a password. If all goes well, you can find the. SSH directory in the user's home directory, there are Id_rsa and id_rsa.pub two files, these two are SSH key key pair, Id_rsa is the private key, can not be leaked out, Id_rsa.pub is the public key, can be assured to tell anyone.

2nd step: Login to GitHub and open the "Account Settings", "SSH Keys" page. Then, click "Add SSH Key", fill in any title, paste the contents of the Id_rsa.pub file in the Key text box. Because GitHub needs to recognize that your push submission is actually pushed by you, not someone else impersonating it, and Git supports the SSH protocol, so if GitHub knows your public key, you can confirm that only you can push it.

10. associating with remote libraries

Add new repo to GitHub and name it. An empty warehouse can clone a new warehouse, or you can associate an existing local warehouse with it.

10.1 Push the contents of the local repository to the GitHub repository

Run the command under the local Learngit warehouse:

...or Create a NewRepositoryOn the    command l Echo# test >> readme.mdGit initgitAddReadme.mdgit commit-m"First Commit"Git remoteAddOriginHTTPS://github.com/yllziv/test.gitgit push-u Origin Master ...orPush anExisting repository from  the  command   LineGit remoteAddOriginHTTPS://github.com/yllziv/test.gitgit push-u Origin Master

When you first push the master branch with the-u parameter, git will not only push the local master branch content to the remote new Master branch, but also associate the local master branch with the remote Master branch and simplify the command at a later push or pull: $ Git push Origin Master

1. Cloning from a remote library

$ git clone  [email protected].com:yllziv/test.gitOr$ git clone  https://github.com/yllziv/test.git

In addition to the slow use of HTTPS, the biggest trouble is that each push must enter a password, but in some only open the HTTP port of the company can not use the SSH protocol and can only use HTTPS. But the native GIT protocol supported by SSH is the fastest.

Reference: Git tutorials-Liaoche's official web

git Concise tutorial