git

GIT

版本控制

• 集中式版本控制

集中式版本控制系统的版本库是集中存放在中央服务器的,工作时需要首先从中央服务器取得最新的版本,必须联网才能工作.

• 分布式版本控制

分布式版本控制系统没有中央服务器,版本库在每个人的电脑上,不需要联网就能工作.分布式版本控制系统通常有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”用户的修改，没有这个服务器也一样可以工作，只是交换修改不方便。

常用命令

git init   初始化文件夹,将其变成Git可以管理的仓库

git add <file>   将文件添加到暂存区

git commit -m "注释"    将暂存区的文件提交到分支并添加注释

git log    显示从最近到最远的提交日志

git status    查看当前状态

git switch 分支名  切换分支

git branch (参数)   查看本地分支(加参数可以对分支作其他操作)

git merge 分支名   合并分支到master分支

git push origin 分支名  推送本地分支到远程仓库

git pull <远程主机名> <远程分支名>:<本地分支名>  从远程获取代码并合并本地的版本,如果远程分支是与本地当前分支合并，则冒号后面的部分可以省略

在Git中，用HEAD表示当前版本,HEAD^表示上一个版本,HEAD^^表示上上个版本,HEAD~100表示前100个版本.

在Git中, commit ID表示版本号,是一个SHA1计算出来的一个非常大的数字，用十六进制表示.每个用户的commit ID都不相同,以自身的为准.每提交一个新版本，实际上Git就会把它们自动串成一条时间线。

版本回滚

git reset --hard HEAD^  回滚到上一个版本

版本回滚后再返回较新的版本

git reset --hard commit ID(版本号)

版本号没必要写全，保证唯一即可,Git会自动寻找符合的版本号。

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针.当你回退版本的时候，仅仅更改HEAD指针指向的版本号,再将工作区的文件更新.

git reflog      记录每次操作的命令以及对应的commit ID

工作区和暂存区

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

git diff  对比工作区(git add之前)和暂存区(git add之后)的区别
git diff --cached  对比暂存区(git add之后)和版本库(git commit之后)的区别
git diff HEAD  对比工作区(git add之前)和版本库(git commit之后)的区别

Git跟踪并管理的是修改，而非文件。

git checkout -- file可以丢弃工作区的修改,将这个文件回到最近一次git commit或git add时的状态。

git checkout切换到另一个分支

命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。从来没有被添加到版本库就被删除的文件，是无法恢复的！

远程仓库

把一个已有的本地仓库GitHub仓库关联，然后将本地仓库的内容推送到GitHub仓库。

在本地仓库下运行命令：

git remote add origin git@github.com:github仓库地址(.git)

添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的。把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。

如果远程库为空，第一次推送master分支时，可以加上-u参数，Git不但会把本地master分支的内容推送到远程新的master分支，还会把本地master分支和远程master分支关联起来，在以后的推送或者拉取时就可以简化命令。

$ git clone git@github.com:github仓库地址(.git)  克隆仓库到本地

Git clone支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。使用https除了速度慢以外，还有个最大的缺点是每次推送都必须输入口令，但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

分支管理

每次提交内容时，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分支：

git switch -c 分支名     创建新分支并切换

不同分支对同一个文件进行修改提交后,若要进行合并则会发生冲突,此时Git无法自动合并分支,必须要手动解决冲突。解决冲突后，再提交，合并完成。手动解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

用git log --graph命令可以看到分支合并图。

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容.

通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

在合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并操作.

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

首先，master分支应该是非常稳定的，仅用来发布稳定的新版本，平时不直接在上面进行操作；

开发者进行开发都在dev分支上，当发布稳定版本的时候，再把dev分支合并到master上，在master分支上发布版本；

开发者在dev分支上工作时，每个人都有自己的分支，合并时与dev分支合并。

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

git stash save "save message"  : 执行存储时，添加备注，方便查找，只有git stash 也要可以的，但查找时不方便识别。

git stash list  ：查看stash了哪些存储

git stash show ：显示做了哪些改动，默认show第一个存储,如果要显示其他存贮，后面加stash@{$num}，比如第二个 git stash show stash@{1}

git stash show -p : 显示第一个存储的改动，如果想显示其他存存储，命令：git stash show  stash@{$num}  -p ，比如第二个：git stash show  stash@{1}  -p

git stash apply :应用某个存储,但不会把存储从存储列表中删除，默认使用第一个存储,即stash@{0}，如果要使用其他个，git stash apply stash@{$num} ， 比如第二个：git stash apply stash@{1} 

git stash pop ：命令恢复之前缓存的工作目录，将缓存堆栈中的对应stash删除，并将对应修改应用到当前的工作目录下,默认为第一个stash,即stash@{0}，如果要应用并删除其他stash，命令：git stash pop stash@{$num} ，比如应用并删除第二个：git stash pop stash@{1}

git stash drop stash@{$num} ：丢弃stash@{$num}存储，从列表中删除这个存储

git stash clear ：删除所有缓存的stash

新增的文件，直接执行stash是不会被存储的

git cherry-pick <commit>   将指定的提交（commit）应用于当前分支

commit参数，不一定是提交的哈希值，分支名也是可以的，表示转移该分支的最新提交。

变基

适用情况:

1. 有时对于一个简单的需求提交了多次，这样非常不利于code review，所以需要将多次提交合并成一次提交。（即多次commit合并成一次commit）
2. 当从master创建一个分支开发，然后其他开发者又从master创建新的分支开发并且先提交，导致远程的master分支比本地master分支有很多不同，因此现在要将本地分支代码基于最新的远程master分支来实现提交

重点:如果提交存在于你的仓库之外，而别人可能基于这些提交进行开发，那么不要执行变基。

git rebase -i   将本地的多次提交合并为一个，以简化提交历史。本地有多个提交时,如果不进行这一步,在git rebase master时会多次解决冲突(最坏情况下,每一个提交都会相应解决一个冲突)

git rebase master   将master最新的分支同步到本地，这个过程可能需要手动解决冲突(如果进行了上一步的话,只用解决一次冲突)

标签管理

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

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

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

• git tag <tagname>用于新建一个标签，默认为HEAD，也可以指定一个commit id；

• git tag -a <tagname> -m "标签说明"可以指定标签信息；

• git tag可以查看所有标签。

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

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

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

• git push origin :refs/tags/<tagname>可以删除一个远程标签。