Git the birth of
a lot of people know, 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), was found in the company BitMover (monitoring job well done!), So the company BitMover anger, to recover the Linux community is free to make
use rights.
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, Linux system
source code 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.
Centralized vs distributed
Linus has always hated CVS and SVN are centralized version control system, Git is a distributed version control systems, centralized and distributed version control systems What difference does it make?
Let me talk a centralized version control system, the repository is centrally stored in a central server, while the work time, are used in your computer, it must first get the latest version from a central server, and then start to work, it did live, then his job on to the central server. The central server is like a library, a book you want to change, you must take it out first from the library, and then returned home to change yourself, change over, then back into the library
The biggest problem is a centralized version control systems must be networked to work, if good, bandwidth is large enough in LAN, fast enough, if available on the Internet, encountered Suman, it may submit a document on the need 10M 5 minutes, that's not the people to suffocate ah.
Distributed version control system and centralized version control systems different? First, the distributed version control system there is no "central server" on everyone's computer is a complete repository, so when you work, you do not need networking, because the repository is on your own computer . Since there is a complete repository on everyone's computer, and that more than one person how collaborative it? Let's say you change a file on your computer A, your colleagues also changed the file on his computer A, then, between the two of you just need to modify their respective pushed to the other side, we can see each other's edited. And centralized version control systems compared to the security of distributed version control system is much higher, because everyone has a complete computer repository, a personal computer is broken does not matter, just a copy from someone else on it. The central server centralized version control system becomes a problem, the owner no law at work.
When in actual use distributed version control system, in fact, rarely push changes from the repository on the computer between the two, because the two of you may not within a local area network, two computers can not visit each other, your colleagues might today ill, I have not even turned on his computer. Therefore, the distributed version control systems usually have to act as a "central server" computer, but the role of this service is only used to facilitate the "exchange" Everybody changes, without it we all work the same, just not convenient to modify the exchange only.
当然， Git 的优势不单是不必联网这么简单，后面我们还会看到 Git 极其强大的分支管理，把 SVN 等
远远抛在了后面。
CVS 作为最早的开源而且免费的集中式版本控制系统，直到现在还有不少人在用。由于 CVS 自身设
计的问题，会造成提交文件不完整，版本库莫名其妙损坏的情况。同样是开源而且免费的 SVN 修正了
CVS 的一些稳定性问题，是目前用得最多的集中式版本库控制系统。
除了免费的外，还有收费的集中式版本控制系统，比如 IBM 的 ClearCase（以前是 Rational 公司的，
被 IBM 收购了），特点是安装比 Windows 还大，运行比蜗牛还慢，能用 ClearCase 的一般是世界 500
强，他们有个共同的特点是财大气粗，或者人傻钱多。
微软自己也有一个集中式版本控制系统叫 VSS，集成在 Visual Studio 中。由于其反人类的设计，连微
软自己都不好意思用了。
分布式版本控制系统除了 Git 以及促使 Git 诞生的 BitKeeper 外，还有类似 Git 的 Mercurial 和 Bazaar
等。这些分布式版本控制系统各有特点，但最快、最简单也最流行的依然是 Git！
安装git
最早 Git 是在 Linux 上开发的，很长一段时间内， Git 也只能在 Linux 和 Unix 系统上跑。不过，慢慢地有人把它移植
到了 Windows 上。现在， Git 可以在 Linux、 Unix、 Mac 和 Windows 这几大平台上正常运行了。
在 Linux 上安装 Git
yum -y install git
一．创建版本库
20 mkdir /xgp 创建所需目录
21 git init git初始化
创建用户名邮箱
26 git config --global user.name "admin"
27 git config --global user.email "admin@admin"
把文件添加到版本库
现在我们编写三个xgp.txt 文件，内容如下
23 vim xgp1.txt #xgp1
24 vim xgp2.txt #xgp2
25 vim xgp3.txt #xgp3
第一步，用命令 git add 告诉 Git，把文件添加到仓库：
28 git add xgp1.txt xgp2.txt xgp3.txt
第二步，用命令 git commit 告诉 Git，把文件提交到仓库：
29 git commit -m "第一次提交"
查看提交信息
52 cd ./git
53 ls -a
57 cat logs/refs/heads/master
58 cat HEAD
小结
现在总结一下今天学的两点内容：
初始化一个 Git 仓库，使用 git init 命令。
添加文件到 Git 仓库，分两步：
• 第一步，使用命令 git add <file>，注意，可反复多次使用，添加多个文件；
• 第二步，使用命令 git commit，完成。
二．时光机穿梭
我们已经成功地添加并提交了一个 readme.txt 文件，现在，是时候继续工作了，于是，我们继续修改 xgp.txt 文件，改成如下内容：
xgp1
回退测试
现在，运行 git status 命令看看结果：
git status 命令可以让我们时刻掌握仓库当前的状态，上面的命令告诉我们， readme.txt 被修改过了，但还没有准备提交的修改
虽然 Git 告诉我们 xgp1.txt 被修改了，但如果能看看具体修改了什么内容，自然是很好的。比如你休假两周从国外回来，第一天上班时，已经记不清上次怎么修改的 readme.txt，所以，需要用 git diff 这个命令看看：
git diff 顾名思义就是查看 difference，显示的格式正是 Unix 通用的 diff 格式，可以从上面的命令输出看到，我们第一行添加了一个”回退测试”
知道了对 readme.txt 作了什么修改后，再把它提交到仓库就放心多了，提交修改和提交新文件是一样的两步，第一步是 git add：
git add xgp1.txt
同样没有任何输出。在执行第二步 git commit 之前，我们再运行 git status 看看当前仓库的状态：
git status 告诉我们，将要被提交的修改包括 xgp.txt，下一步，就可以放心地提交了：
git commit -m "第二次提交"
提交后，我们再用 git status 命令看看仓库的当前状态：
小结
要随时掌握工作区的状态，使用 git status 命令。
如果 git status 告诉你有文件被修改过，用 git diff 可以查看修改内容。
四。管理修改
为什么说 Git 管理的是修改，而不是文件呢？我们还是做实验。第一步，对 xgp1.txt 做一个修改，比如加一行内容：
[root@localhost xgp]# cat xgp1.txt
xgp1
回退测试
xgp666
xgpniubi
然后，添加：
93 git add xgp1.txt
94 git status
然后，再修改 readme.txt：
[root@localhost xgp]# cat xgp1.txt
xgp1
回退测试
xgp666
xgpniubi
1
提交：
[root@localhost xgp]# git commit -m "第四次提交"
[master 31cb090] 第四次提交
1 file changed, 1 insertion(+)
提交后，再看看状态：
咦，怎么第二次的修改没有被提交？
别激动，我们回顾一下操作过程：
第一次修改 -> git add -> 第二次修改 -> git commit
你看，我们前面讲了， Git 管理的是修改，当你用 git add 命令后，在工作区的第一次修改被放入暂存区， 准备提交，
但是，在工作区的第二次修改并没有放入暂存区，所以， git commit 只负责把暂存区的修改提交了，也就是第一次的
修改被提交了，第二次的修改不会被提交。
提交后，用 git diff HEAD -- readme.txt 命令可以查看工作区和版本库里面最新版本的区别：
可见，第二次修改确实没有被提交。
那怎么提交第二次修改呢？你可以继续 git add 再 git commit，也可以别着急提交第一次修改，先 git add 第二次修
改，再 git commit，就相当于把两次修改合并后一块提交了：
第一次修改 -> git add -> 第二次修改 -> git add -> git commit
好，现在，把第二次修改提交了，然后开始小结。
小结
现在，你又理解了 Git 是如何跟踪修改的，每次修改，如果不 add 到暂存区，那就不会加入到 commit 中。
五。撤销修改
自然，你是不会犯错的。不过现在是凌晨两点，你正在赶一份工作报告，你在 readme.txt 中添加了一行：
[root@localhost xgp]# cat xgp1.txt
xgp1
回退测试
xgp666
xgpniubi
1
22222
在你准备提交前，一杯咖啡起了作用，你猛然发现了“stupid boss”可能会让你丢掉这个月的奖金！既然错误发现得很及时，就可以很容易地纠正它。你可以删掉最后一行，手动把文件恢复到上一个版本的状态。如果
用 git status 查看一下：
你可以发现， Git 会告诉你， git checkout -- file 可以丢弃工作区的修改：
git checkout -- xgp1.txt
[root@localhost xgp]# cat xgp1.txt
xgp1
回退测试
xgp666
xgpniubi
1
庆幸的是，在 commit 之前，你发现了这个问题。用 git status 查看一下，修改只是添加到了暂存区，还没有提交：
Git 同样告诉我们，用命令 git reset HEAD file 可以把暂存区的修改撤销掉（unstage），重新放回工作区：
[root@localhost xgp]# git reset HEAD xgp1.txt
重置后撤出暂存区的变更：
M xgp1.txt
git reset 命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用 HEAD 时，表示最新的版本。
再用 git status 查看一下，现在暂存区是干净的，工作区有修改：
还记得如何丢弃工作区的修改吗？
整个世界终于清静了！
现在，假设你不但改错了东西，还从暂存区提交到了版本库，怎么办呢？还记得版本回退一节吗？ 可以回退到上一个版本。不过，这是有条件的，就是你还没有把自己的本地版本库推送到远程。还记得 Git 是分布式版本控制系统吗？我们后面会讲到远程版本库，一旦你把“stupid boss”提交推送到远程版本库，你就真的惨了……
小结
又到了小结时间。
场景 1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令 git checkout -- file。
场景 2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令 git reset
HEAD file，就回到了场景 1， 第二步按场景 1 操作。
场景 3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程
库。
六。删除文件
在 Git 中，删除也是一个修改操作，我们实战一下，先添加一个新文件 test.txt 到 Git 并且提交：
[root@localhost xgp]# vim test.txt
[root@localhost xgp]# cat test.txt
qqqqqqqqqqqq
[root@localhost xgp]# git add test.txt
[root@localhost xgp]# git commit -m "第一次"
[master f9688d7] 第一次
1 file changed, 1 insertion(+)
create mode 100644 test.txt 
一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用 rm 命令删了：
这个时候， Git 知道你删除了文件，因此，工作区和版本库就不一致了， git status 命令会立刻告诉你哪些文件被删除了：
现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令 git rm 删掉，并且 git commit：
现在，文件就从版本库中被删除了。
另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：
$ git checkout -- test.txt
git checkout 其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。
小结
命令 git rm 用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只
能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
七。Git远程仓库
第1步：创建SSH Key。在用户主目录下，看看有没有.ssh目录，如果有，再看看这个目录下有没有 id_rsa 和 id_rsa.pub 这两个文件， 如果已经有了，可直接跳到下一步。如果没有，打开 Shell （Windows 下打开 Git Bash），创建 SSH Key：
ssh-keygen -t rsa -C [email protected]
你需要把邮件地址换成你自己的邮件地址，然后一路回车，使用默认值即可，由于这个 Key 也不是用于军事目的，
所以也无需设置密码。
如果一切顺利的话，可以在用户主目录里找到.ssh 目录，里面有 id_rsa 和 id_rsa.pub 两个文件，这两个就是 SSH Key
的秘钥对， id_rsa 是私钥，不能泄露出去， id_rsa.pub 是公钥，可以放心地告诉任何人。
第 2 步：登陆 GitHub，打开“Account settings”， “SSH Keys”页面：
然后，点“Add SSH Key”，填上任意 Title，在 Key 文本框里粘贴 id_rsa.pub 文件的内容：
为什么 GitHub 需要 SSH Key 呢？因为 GitHub 需要识别出你推送的提交确实是你推送的，而不是别人冒充的，而Git 支持 SSH 协议，所以， GitHub 只要知道了你的公钥，就可以确认只有你自己才能推送。
从远程库克隆
现在的情景是，你已经在本地创建了一个 Git 仓库后，又想在 GitHub 创建一个 Git 仓库，并且让这两个仓库进行远程同步，这样， GitHub 上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。
首先，登陆 GitHub，然后，在右上角找到“Create a new repo”按钮，创建一个新的仓库
目前，在 GitHub 上的这个 learngit 仓库还是空的， GitHub 告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到 GitHub 仓库。
现在，远程库已经准备好了，下一步是用命令 git clone 克隆一个本地库：
git clone [email protected]:xgp666/xgp.git
注意把 Git 库的地址换成你自己的，然后进入 gitskills 目录看看，已经有 README.md 文件了。
如果有多个人协作开发，那么每个人各自从远程克隆一份就可以了。
你也许还注意到， GitHub 给出的地址不止一个，还可以用 https://github.com/michaelliao/gitskills.git 这样的地
址。实际上， Git 支持多种协议，默认的 git://使用 ssh，但也可以使用 https 等其他协议。
使用 https 除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令，但是在某些只开放 http 端口的公司内
部就无法使用 ssh 协议而只能用 https。
测试：在远程库创建一个文件
[root@localhost xgp]# vim index.html
[root@localhost xgp]# cat index.html
Qqqqq
[root@localhost xgp]# git add index.html
[root@localhost xgp]# git commit -m "123"
[master 65e2ec7] 123
1 file changed, 1 insertion(+)
create mode 100644 index.html
[root@localhost xgp]# git push origin master （默认是master）
浏览器查看
小结
要克隆一个仓库，首先必须知道仓库的地址，然后使用 git clone 命令克隆。
Git 支持多种协议，包括 https，但通过 ssh 支持的原生 git 协议速度最快。
八。将本地链接远程库
现在的情景是，你已经在本地创建了一个 Git 仓库后，又想在 GitHub 创建一个 Git 仓库，并且让这两个仓库进行远
程同步，这样， GitHub 上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。
目前，在 GitHub 上的这个 learngit 仓库还是空的， GitHub 告诉我们，可以从这个仓库克隆出新的仓库，也可以把一个已有的本地仓库与之关联，然后，把本地仓库的内容推送到 GitHub 仓库。
现在，我们根据 GitHub 的提示，在本地的 learngit 仓库下运行命令：
git remote add origin [email protected]:xgp666/xgp.git
Next, we can put all the contents of the local repository pushed to the remote repository:
1.git Branch --set-upstream-to = Origin / Master Master 
2.git FETCH 
3. execute git branch --set-upstream-to again Origin = / Master Master 
4.git Push Origin Master 
5.git pull 
6. The
[XHP the root @ localhost] # Vim aa.txt
[XHP the root @ localhost] # Git the Add *
[XHP the root @ localhost] # Git the commit -m " 4 "
[Master 2f77003] 4
[root @ localhost XHP] # git Status
! Located at the branch Master
! Your branch leading 'origin / master' total of three submitted.
! (Use "git push" to publish your local commit)
!
No document to be submitted, a clean work area 
7.git push origin master 
browser to view 
From now on, as long as the local made a submission, it can command:
$ git the Push Origin master
the latest modification of the local master branch pushed to GitHub, now and you have a truly distributed repository!