从根上学习 Git

什么是git？

Git是目前世界上最先进的分布式版本控制系统

什么是版本库？

版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”

SVN是集中式版本控制系统，Git是分布式版本控制系统，集中式和分布式区别？

集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆

集中式版本控制系统最大的毛病就是必须联网才能工作，如果在局域网内还好，带宽够大，速度够快，可如果在互联网上，遇到网速慢的话，可能提交一个10M的文件就需要5分钟，这还不得把人给憋死啊

分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上

既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了

如何创建一个版本库？

很简单，创建一个空的文件夹，进入到文件夹中执行git init，即，将该文件夹变成Git可管理的仓库

Git基本操作

添加一个文件

提示：添加的文件必须放在你初始化的这个目录或其子目录下

将一个文件添加到仓库需要两步：

git add filename
git commit -m '备注'

查看当前工作区状态

git status

查看修改内容

git diff filename

查看提交日志（是按时间的由近到远的顺序）

git log



如果觉得显示的结果太长，可以在后边添加--pretty=oneline参数，最前边的一长串是git的版本号

git中的版本回退

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交，上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100

比如要回退到上一个版本

git reset --hard 版本号

查看每一次执行过的命令，即查看历史命令

git reflog

工作区和暂存区的概念

工作区：就是你在电脑上能看见的目录

版本库：在我们的工作区中会有一个隐藏的目录.git，这个就是git的版本库

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD

前面提到我们把文件往Git版本库里添加的时候，是分两步执行的

• 第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区

• 第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支

因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改

你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改

假设现在我修改了readme文件，并添加了一个LICENSE文件，也就是执行完了git add，但是还没执行git commit

现在暂存区就是这个状态

所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支

执行完git commit之后，版本库就变成了下边这样

撤销修改

场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file（这里的--一定要加上，不加上就表示切换分支了）

场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场景1操作

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，可以使用上边说到的版本回退，不过前提是没有推送到远程库

删除一个文件

删除一个文件也分两步：

git rm filename
git commit -m

分支管理

创建与合并分支

每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上

Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支

命令总结

创建dev分支并切换
git checkout -b dev
查看当前分支
git branch
git branch命令会列出所有分支，当前分支前面会标一个*号
分支合并
git merge 分支名
git merge命令用于合并指定分支到当前分支
创建分支：git branch 分支名
切换分支：git checkout 分支名
创建并切换分支：git checkout -b 分支名
合并某分支到当前分支：git merge 分支名
删除分支：git branch -d 分支名

分支管理策略

在实际开发中，我们应该按照几个基本原则进行分支管理

• 首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活

• 那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本

• 你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了

所以，团队合作的分支看起来就像这样

多人协作

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin

要查看远程库的信息，用git remote或者查看更详细的信息，使用git remote -v，会显示出可以抓取和推送的origin地址，如果没有推送权限，就看不到push地址

推送分支

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上

git push origin master

如果要推送其他分支，比如dev，就改成

git push origin dev

抓取分支

多人协作时，大家都会往master和dev分支上推送各自的修改

现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆

当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支

现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支

git checkout -b dev origin/dev

现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程

你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送

推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送

git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接

这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push

因此，多人合作的工作模式通常是这样

1. 首先，可以试图用git push origin branch-name 推送自己的修改；

2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

3. 如果合并有冲突，则解决冲突，并在本地提交；

4. 没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to branch-name origin/branch-name

小结

• 查看远程库信息，使用git remote -v；

• 本地新建的分支如果不推送到远程，对其他人就是不可见的；

• 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；

• 在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；

• 建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；

• 从远程抓取分支，使用git pull，如果有冲突，要先处理冲突

标签管理

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照

Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的

创建标签

首先切换到要打标签的分支上，然后使用git tag tagName命令

查看分支上有哪些标签：git tag

查看标签信息：git show 标签名

默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？

方法是找到历史提交的commit id，然后打上就可以了

比方说要对add merge这次提交打标签，它对应的commit id是f52c633，敲入命令

git tag v0.9 f52c633

注意：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签

git tag -a tagname -m "blablabla..."可以指定标签信息

管理标签

• 命令git push origin tagname可以推送一个本地标签；

• 命令git push origin --tags可以推送全部未推送过的本地标签；

• 命令git tag -d tagname可以删除一个本地标签；

• 命令git push origin :refs/tags/tagname可以删除一个远程标签

参考：

https://www.liaoxuefeng.com/wiki/896043488029600