1. git Introduction
1.1 generates history
git is the world's most advanced distributed version control system.
Linus created the open-source Linux in 1991. Since then, the development of Linux systems, has become the largest server system software. Although Linus created Linux, but Linux is to grow by enthusiastic volunteers around the world to participate, so many people write code for Linux around the world, and that Linux code is how to manage it? The fact is that, by 2002, volunteers from around the world to source code files sent by Linus diff way, then by Linus himself by manually merge code!
You may be thinking, why not put Linus Linux code into version control system do? Not a CVS, SVN these free version control system? Because Linus firmly opposed to CVS and SVN, these centralized version control system is not only slow, but also must be networked to use. There are some commercial version control system, although the ratio of CVS, SVN easy to use, but it is paid for, does not match the spirit of Linux and open source. However, by the year 2002, Linux systems have been developed for a decade, a large code base of hard to let Linus continue to manage through manually, community brothers also expressed strong dissatisfaction in this way, so Linus chose a business version control system, BitKeeper, BitKeeper's owner BitMover company out of humanitarian spirit, the authorization to use the free Linux community version control system. Excellent situation of stability and unity in 2005 was broken, because the Linux community gathered cattle, inevitably tainted with some of the Liangshan heroes of rivers and lakes habits. Samba developed by Andrew trying to crack BitKeeper protocols (so dry in fact, not only him), it was found in the company BitMover (monitoring job well done!), So the company BitMover anger, to recover the right to use the free Linux community. Linus can apologize to BitMover companies to ensure strict discipline after the brothers, ah, this is impossible.
The reality is this: Linus spent two weeks own use C to write a distributed version control system, which is Git! Within a month, the source Linux system has been managed by Git up! Cattle is how to define it? You can taste. Git quickly became the most popular distributed version control system, especially in 2008, on the site GitHub line, and it is an open source project to provide free storage Git, many migrated to GitHub open source project started, including jQuery, PHP, Ruby, and so on. History is such a chance, if not the year the company BitMover threat Linux community, and now we may not have free and super easy to use Git up.
Two features of 1.2 git
- Version control : people can solve the problem at the same time developing the code, you can also solve the problem of code to retrieve history.
- Distributed : Git is a distributed version control system, with a Git repository, it can be distributed to different machines. First, find a computer acting as a server role, 24 hours a day, everyone else from this "server" Warehouse cloned copy to your own computer, and each of the respective push submitted to the server in the warehouse, but also from the warehouse server pulls submit someone else's. This can set up your own server, you can use the site GitHub.
2. Installation and Configuration
2.1 manner 1: yum install command follows
(This installation of 1.8, the version is too old, you can learn, build environment is recommended to use the second way):
2.2 Method 2: compile and install (production environment is recommended in this way)
(3) the installation is successful, run the following command:
3. Create a repository
New Directory git_test, create a repository in git_test directory, the command: git init
You can see creates a hidden directory under git_test .git directory, which is the repository directory.
4. Create a version with rollback
Works of 4.1 git
① when the file was created in the repository, there is a first version of a file, this will also generate a pointer to this version
② When you modify the contents code.txt in the future, they generate a second version, but this version is dependent on a version, in this version will only modify the file record that has occurred. After the birth of a new version, it will point the latest version.
③ may be achieved by modifying the position of the pointer back to an versions, represented in two ways, one is to use ^ A ~ used, as follows
l HEAD ^ or HEAD ~ 1: represents a version of the
l HEAD ^^ or HEAD ~ 2: represents the two versions
Following the adoption of the above ways to fall back to the first version, the pointer points to a version 1
4.2
(1) Create a file code.txt in git_test directory, writes a line reads as follows:
(2) using the following two commands to create a version, the version created in two steps:
① git add code.txt
② git commit -m 'Version 1'
(3) View version record, the command is git log:
(4) continue to edit code.txt, add a line in there.
(5) Use the following command to re-create a version and check the version record:
(6) Now if you want to return to a version, you can use the following command:
git reset --hard HEAD^
HEAD which represents the current latest version, HEAD ^ represents the current version of the previous version, HEAD ^^ represented before the former version of the current version, you can also use HEAD ~ 1 represents the current version of the previous version, HEAD ~ 100 represents the current version of the the first 100 version.
Now, if it feels like to return to version 1, you can use the following command:
After executing the command to view the version using git log records and found that now only see the records version 1, cat code.txt view the contents of the file, now only one line, which is the first version code.txt content.
(7) If we now want to return to version 2, this time how to do?
You can use the following command:
git reset --hard version number
From the above you can see the version number 2 is:
(8) were selected based on the query to the version number:
Discovery version 2 now has come back. Cat code.txt can view the inside reads as follows:
(9) If we say that the above change how the terminal has been shut fallback version.
We execute the following command will fall back to version 1 release.
Below the terminal off, and then open the terminal, the version number found in version 2 of the see before.
So how do go back to version 2? git reflog command to view our operating record.
You can see the version number 2, we then use the following command version rollback, version back to version 2.
4.3 work area and staging area
4.2.1 workspace (Working Directory)
Computer directory, such as our git_test, is a work area.
4.2.2 repository (Repository)
l work area has a hidden directory .git, this is not the work area, but git repository.
L git version of the library saved a lot of things, most important of which is called the stage (or called index) staging area, and the first branch master git automatically created for us, and point to a master pointer called HEAD.
l because we created git repository, git automatically creates a master branch is the only one we have, so, now, git commit is to commit the changes to the master branch.
l You can simply understood as the documents required to submit all changes into the staging area, and then, a one-time submission of all the changes in the temporary area.
Speaking in front when we put the file to the git repository added, is performed in two steps:
The first step is to use git add to add into the file, the file is actually added to modify the staging area;
The second step is to submit changes with git commit, in fact, is to submit all the contents of the staging area to the current branch.
(1) below and then create a file code2.txt in git_test directory, and then edit the content as follows:
(2) Then again code.txt edit content, to which a line, the edited contents are as follows:
(3) Use the following command to view the current working state of the tree:
git status
The above tips we code.txt be modified, but code2.txt not being tracked.
(4) We use the following command to code.txt and code2.txt added to the staging area, and then execute git status command, as follows:
All the git add command is to submit all changes to the temporary storage area.
(5) Then, you can git commit to a one-time submission of all modifications to the staging area to create a version branch.
(6) Once submitted, and if you do not make any changes to the work area, the work area is "clean". Run the following command can be found:
4.3 modify management
Git modified file management, it will only be submitted to modify the staging area to create a version.
(1) Edit code.txt, and use git add command to add it to the staging area.
Add to cache
Then add a line
(2) git commit to create a version,
Use git status to see this time and found that the state is not clean
This is because after the second revision code.txt content, and do not add workspace, so create a version of the time and has not been submitted.
4.4 undo changes
(1) Continuing the above operation, suggesting that we can use to undo the format, that is, discard your work area changes:
git checkout - <file>
Run the following command
Found work area clean,
The second change content is also gone.
(1) previously demonstrated is not added to the contents of the staging area to be rolled back, in fact, even if added to the staging area, also began to be rolled back.
We continue to edit code.txt, and add the following [img] (file:! /// C: / Users / sy / Documents / My Knowledge / temp / fc8918e9-6218-4de1-ae60-6e01447f1ea3 / 128 / index_files /ba216e8d1d4fdee2a99d4381557af131.png)
And add the staging area
(3) git also told us, use the command git reset [Options] HEAD file can modify the staging area of the revocation away, back into the work area.
There are three options
l --hard: content caching and working directory are rolled back to the state specified version
l --mixed: default option, and you specify a buffer submit sync, but the work will not be affected directory
l --soft: the contents of the cache, and the working directory is not changed (the specified version only content library rollback)
L When using these options, you can not specify a specific file
status
Here, only the content is stored in the staging area is deleted, then you can roll back the file to the state before the modification
(4) To discard modifications code.txt Now, the following command can be executed.
Now, if you make mistakes not only something from scratch also submitted to the repository, you need to version rollback.
summary:
l Scenario 1: When you change the contents of a file chaotic workspace want direct discard modify the workspace, use the command git checkout - file.
l Scenario 2: When you change not only upset the contents of a file workspace, also added to the staging area, to discard the changes in two steps, the first step with the command git reset HEAD file, returned to the scene 1, a second step of operation by scene.
l Scenario 3: have submitted improper modifications to the repository, you want to withdraw this submission, reference version rollback one.
To demonstrate the role of the three options
First to demonstrate the hard option
1 Edit a file in the repository 1, and add to the staging area
2 Edit another file (not saved to the staging area)
3 View state is not a trace state in a temporary area
4 with git reset --hard xxxx rollback to a state
5 again view the status (in this case found to be clean, what state are gone)
6 These two documents newly added content is gone
First to demonstrate the soft option
The front section slightly
1 execute reset, roll back to the first version
2 The contents of the staging area and the files are still
View version 3 is currently located, has returned to the first version, the other version is gone
4.5 Comparison of different file
Compare different workspaces and files in a version:
(1) continue to edit the file code.txt, add a line in which the content.
(2) now compare different workspace code.txt and previous versions of code.txt. Use the following command:
We can and repository of the second version than done
Comparison between two versions of different documents:
(1) now ^ HEAD HEAD and compare different versions code.txt using the following command:
4.6 Delete Files
(1) we delete the directory code2.txt.
This time, git know deleted files, so the workspace and repository on inconsistent, git status command will prompt immediately which files are deleted.
(2) Now you have two options, one sure you want to delete the file repository, then use git rm command to delete, and git commit:
Another case is deleting the wrong, you can directly use git checkout - code2.txt, this file code2.txt back.
summary:
- Git rm command is used to delete a file.
- If a file has been submitted to the repository, so you never have to worry about mistakenly deleted, but be careful, you can only restore files to the latest version, you will lose the contents of the most recent commit your changes.