Git 一个强大的版本控制工具

前言

一什么是分布式 什么是集中式

1 分布式就是文件在每台参与开发的机器中都是完整包 当你修改开发相关的内容 你的修改会被推送到其他的机器上

2 集中式就是所有的完整文件在一台公用的服务器上 你想做开发可以 你得先从服务器上 下载文件 做完修改你再返回到这台公共服务器上

两者的区别 分布式是不需要联网的 集中式在网速比较慢的情况下 每次都需要从服务器上下载文件非常的不方便

二 git的安装

1输入git来询问你的Linux有没有安装git

如果提示没有安装 则

先从Git官网下载源码，然后解压，依次输入：./config，make，sudo make install这几个命令安装就好了。

2 win下的git安装

https://git-for-windows.github.io/

下载 安装一直下一步

最后打开git bash来自爆一下家门

$ git config –global user.name “Your Name” $ git config –global user.email “[e-mail]”

三 git仓库的创建与添加文件

1 仓库的创建

首先你得需要mkdir相应的目录

然后使用git init 来告诉git这是个仓库（执行的时候你得在这个仓库目录下）

2 把文件添加到仓库

使用git add 文件名来添加文件（但前提是这个文件必须在仓库目录下）

之后使用git commit -m “说明” 来解释这个文件的作用

为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：

$ git add file1.txt $ git add file2.txt file3.txt $ git commit -m “add 3 files.”

这样就是以上这次提交的共有说明

部分总结

初始化一个Git仓库，使用git init命令。

添加文件到Git仓库，分两步：

第一步，使用命令git add <file>，注意，可反复多次使用，添加多个文件；

第二步，使用命令git commit，完成。

四 查看git的状态

git status命令可以让我们时刻掌握仓库当前的状态

git diff可以查看修改内容

五 版本回退 从你的仓库里拿出历史文件

其实commit就是一个快照 一个存储点 他存储了整个版本 你下次可以通过这个commit去回述历史版本

git log就可以查看拿到历史的版本

git log –pretty=oneline 简化信息

Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交3628164…882e1e0（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100

使用git reset –hard HARD^ 来回溯上个版本+

那么回溯了之后又想回到之前的版本怎么办呢 前提是不关闭这个窗口 然后使用下来的命令

hard后面的是之前的commit号

$ git reset –hard 3628164 HEAD is now at 3628164 append GPL

为什么回溯的速度这么快呢 因为这个HEAD其实只是一个指针 改一下指向的东西就可以了

那么如果要是我们关闭了计算怎么回去呢

$ git reflog

里面记录了我们最近的操作

这里面的排列方式是从下网上 时间排序

六 git中的暂存区和工作区

之前我们说了 在git中添加文件会有两部 第一步 add 第二部 commit

其实在git中 工作区就是我们实际的文件区域 保存区域 而.git文件夹里面就是git的版本库

版本库里有暂存区和head指向的master

可以这样理解 你使用add命令 添加你的所有更改 把这些更改去保存到暂存区 而commit则一次把你的更改创造一个快照

把你的更改去写入一个真正的树中

所以在git中 所谓的干净 clean的意思就是 暂存区中没有文件

工作区的文件其实就是映射自版本库的head指向master

一旦改变head的指向 那么你这个工作区的文件也会改变

七 git中的

Git是如何跟踪修改的，每次修改，如果不add到暂存区，那就不会加入到commit中。

每次的commit都是从暂存区去获取的 你不add就肯定不会commit

两者密不可分

八 撤销修改

1 git checkout — file可以丢弃工作区的修改：

$ git checkout — readme.txt

命令git checkout — readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

总之，就是让这个文件回到最近一次git commit或git add时的状态。

2 Git同样告诉我们，用命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区

所以如果你的文件修改了并且放到了暂存区里面 你得先用reset 去踢出暂存区 然后用checkout 去还原工作区的改动

九 删除与还原

git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

我们如果在工作区中不小心删除了文件 那么git可以帮我们使用checkout从版本控制区还原这个文件

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

10 连接你的github

origin为远程端的名字

要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；

关联后，使用命令git push -u origin master第一次推送master分支的所有内容；

此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；

可能会出现publickey不匹配的情况 可以在本地生成 key 具体方法如下

ssh-keygen

然后系统提示输入文件保存位置等信息，连续敲三次回车即可，生成的SSH key文件保存在中～/.ssh/id_rsa.pub

接着拷贝.ssh/id_rsa.pub文件内的所以内容，将它粘帖到github帐号管理中的添加SSH key界面中。

打开github帐号管理中的添加SSH key界面的步骤如下：

1. 登录github

2. 点击右上方的Accounting settings图标

3. 选择 SSH key

4. 点击 Add SSH key

在出现的界面中填写SSH key的名称，填一个你自己喜欢的名称即可，然后将上面拷贝的~/.ssh/id_rsa.pub文件内容粘帖到key一栏，在点击“add key”按钮就可以了。

添加过程github会提示你输入一次你的github密码

添加完成后再次执行git clone就可以成功克隆github上的代码库了。

十一 git中的分支

首先 一个主master是不适合多人共同去开发的 因为你做的事情很容易干扰其他人的开发 所以一般开分支 在开分支的情况下 你的库是你分支的库 你的工作文件夹也是从这个分支去映射出来的 比如你再分支下创建了个文件夹 然后添加进库中 切换你的分支成master 你的那个文件夹会消失

当然一开始创建分支的时候 文件还是从master里面的克隆了文件

Git鼓励大量使用分支：

查看分支：git branch创建分支：git branch <name>切换分支：git checkout <name>创建+切换分支：git checkout -b <name>合并某分支到当前分支：git merge <name>删除分支：git branch -d <name>

十二 分支的合并

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

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

先找到冲突文件 然后修改文件 重新提交 最后删除 分支

十三 分支管理策略

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

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

首先，仍然创建并切换dev分支：

$ git checkout -b dev Switched to a new branch ‘dev’

修改readme.txt文件，并提交一个新的commit：

gitaddreadme.txt git commit -m “add merge” [dev 6224937] add merge 1 file changed, 1 insertion(+)

现在，我们切换回master：

$ git checkout master Switched to branch ‘master’

准备合并dev分支，请注意–no-ff参数，表示禁用Fast forward：

$ git merge –no-ff -m “merge with no-ff” dev Merge made by the ‘recursive’ strategy. readme.txt | 1 + 1 file changed, 1 insertion(+)

因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。

合并后，我们用git log看看分支历史：

$ git log –graph –pretty=oneline –abbrev-commit * 7825a50 merge with no-ff |\ | * 6224937 add merge |/ * 59bc1cb conflict fixed …

本来是吸收完然后删除分支 你不知道添加了什么

但是这样家 -no-ff 就可以创建新的commit

给他写个-m 就有了相应的信息

十四 分支策略

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

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

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

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

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

小结

Git分支十分强大，在团队开发中应该充分应用。

合并分支时，加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。