GIT版本控制

 版本控制：

         在公司中，一般以团队的形式进行项目的开发．在一个团队中,每一个团队成员都需要一份相同的代码,而大家又都基于那一份代码进行开发不同的功能,过程中就会产生相当多的问题,针对这些问题,我们可以采用版本控制的方式来解决,也因此诞生了很多版本控制工具,常见的有cvs/svn/git等等.

 团队开发中的问题:

         代码分散:多人开发,不同模块的代码都在不同负责人的电脑上

         备份: 电脑如果出现问题,之前的代码没有保存,之前的代码不在了,

          代码还原:

          协同修改:共同修改了同一份代码,之前修改的被后面的覆盖了

          多版本项目文件管理:

           追溯问题代码的编写人和编写 时间: 出现问题不知道到底是谁出现的,找不到罪魁祸首

            权限控制:没有权限,其他人也能修改你的代码,万一有仇家就完了

版本控制概述:

        版本控制( Revision control ) 是维护工程蓝图的标准做法，能 追踪工程蓝图从诞生一直到

定案的过程 。是一种记录若干文件内容变化过程，以便将来查阅特定版本修订情况的系统。

版本控制深入程序员在团队配合中,如果你的项目没有版本控制：

        一、 代码管理混乱。

        二、 解决代码冲突困难。

        三、 在代码整合期间引发BUG 。

        四、 无法对代码的拥有者进行权限控制。

        五、 项目不同版本发布困难。

Git

  功能强大,使用广泛,

难点: 命令/分支        

        集中式和分布式版本控制:

                

 

          先说集中式版本控制系统，版本库是 集中存放在中央服务器 的，而干活的时候，用的都是自己的电脑， 所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。

        中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完 了，再放回图书馆。

缺点 :

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

        那分布式版本控制系统 与集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本 没有 “ 中央 服务器 ” ，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就 不需要联网 了，因为版本 库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在 自己电脑上改了文件A ，你的同事也在他的电脑上改了文件 A ，这时，你们俩之间只需把各自的修改推送 给对方，就可以互相看到对方的修改了。

        和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多 ，因为每个人电脑里都有完整的版 本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的 中央服务器要是出了问题，所有人都没法干活了。

        在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改 ，因为可能你 们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开机。

        因此，分布式版本控制系统通常也有一台充当 “ 中央服务器 ” 的电脑 ，但这个服务器的作用仅
仅是用来 方 便 “ 交换 ” 大家的修改 ，没有它大家也一样干活，只是交换修改不方便而已。

  Git的优势

         分布式/分支

  Git的安装

        Git (git-scm.com)官方网站下载

        下载之后,双击打开,一顿无脑式安装

        打开之后是

 在命令行中进行初始化

git config --global user.name "Your Name"
git config --global user.email "email@example.com"

在自己的目录下打开命令行,执行git init  初始化一个仓库.

第一步：用命令 git add 告诉 Git ，把文件交给 Git 进行管理：

执行上面的命令，没有任何显示，这就对了， Unix 的哲学是 “ 没有消息就是好消息 ” ，说明添加成功。

第二步：用命令 git commit 告诉 Git ，把文件提交到本地仓库：

简单解释一下 git commit 命令， - m 后面输入的是本次提交的说明，可以输入任意内容，当然 最好是有 意义 的，这样你就能从历史记录里方便地找到改动记录。

git add 可以多次操作,只需要一次commit就好了.

git add . 就是将当前目录下的所有文件交给git追踪.

 add 就是将工作区的内容添加到暂存区,commit就是将暂存区中的内容添加到本地仓库中.

 commit只能将暂存区中的内容提交到本地仓库中,如果工作区的内容没有add到暂存区中,不会被提交到本地仓库中.

 4之后只会将a.txt提交到本地仓库,b.txt不会改变.

查看版本库状态

使用git   status  查看版本库的状态,如果是工作区与本地仓库一样的话就会出现

On branch master
nothing to commit, working tree clean
这样的提示信息,如果不一样将会提示

使用git  restore  fileName 将会还原状态,会把我们之前的修改取消,改成没有修改时的状态.

修改是以上的显示,如果是被删除的话

 上面的那一块是已经在版本库中,下面的还没有被放入版本库中.

也就是说,如果文件只在工作区,显示的文件颜色将会是红色,如果在暂存区,将会是绿色,在本地仓库中存在就没有了.

查询提交日志,

git log

如果嫌显示的内容太多了,可以加上 --pretty=oneline

git log --pretty=oneline

 

 输入Q就可以退出查看日志窗口

查看差异

        如果一个文件知道被人修改了，但如果能看看具体修改了什么内容，自然是更好的 比如你休假两周从国外回来，第一天上班时，已经记不清上次怎么修改的 readme.txt ，所以，需要用

git diff 这个命令看看：

        

git diff # 查看不同版本之间的文件差异

 红色区域是原先的内容,绿色区域的内容是现在新的内容

比较的是工作区和暂存区的内容(就近原则),如果暂存区中没有,那么就跟本地仓库中的进行比较

 版本回退

        我们不断修改文件，不断的往版本库中提交文件。就好比玩 RPG 游戏时，每通过一关就会自动把游戏状 态存盘，如果某一关没过去，你还可以选择读取前一关的状态。有些时候，在打 Boss 之前，你会手动 存盘，以便万一打 Boss 失败了，可以从最近的地方重新开始。 Git 也是一样，每当你觉得文件修改到 一定程度的时候，就可以“ 保存一个快照 ” ，这个快照在 Git 中被称为 commit 。一旦你把文件改乱了， 或者误删了文件，还可以从最近的一个 commit 恢复，然后继续工作，而不是把几个月的工作成果全部 丢失。

git reset --hard HEAD^ // 回退到上一个版本
git reset --hard <commit id>  // 回退到指定的版本

管理修改:

操作方式 1:

第一次修改 - > git add - > 第二次修改 - > git commit

 

操作方式 2 ：推荐使用

第一次修改 - > git add - > 第二次修改 - > git add - > git commit

PS ：建议在每次 commit 之前先检查是否有文件没有被 add

撤销修改:

git checkout -- filename 可以丢弃工作区的修改： -- 后面是一个空格

命令 git checkout -- readme.txt 意思就是，把 readme.txt 文件在工作区的修改全部撤销，这里

有两种情况：

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

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

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

注意 :

git checkout -- file 命令中的 -- 很重要，没有 -- ，就变成了 “ 切换到另一个分支 ” 的命令，我们在

后面的分支管理中会再次遇到 git checkout 命令

删除文件

一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用 rm 命令删了：

这个时候， Git 知道你删除了文件，因此，工作区和版本库就不一致了， git status 命令会立刻告诉 你哪些文件被删除了：

删除完成后需要 commit 如果删除了想恢复, 可以使用 reset 版本恢复

步骤1：本地删除没用的文件（查看状态）

步骤 2 ：先 add 以下（查看状态与步骤1进行比较）

步骤3：提交删除文件

 

分支管理

Git分支管理模式:

        1.主分支:存放稳定发布版本的代码,项目上线就是基于该分支的代码进行上限

        2.开发分支:团队中的开发人员频繁变动的分支,代码比较不稳定,容易出现bug

        3.测试分支:当一部分功能开发完成之后,开发人员自测没问题,将开发分支的代码合并到测试分支,并基于该分支的代码部署到测试环境,交给测试人员进行测试

        4.功能分支:在已有的功能开发中间加入新的功能,通常是基于上一个稳定版本,从主分支的最后一个稳定版本合并出来的,在此基础上进行新功能开发,测试完成通过后,会将新功能你合并到开发分支中.

        5.bug修复分支:主要用于修复线上环境Bug,当主分支功能出现bug时,切换到bug修复分支,修复后再合并到测试分支最终测试完成再合并到主分支以及开发分支

 

分支相关命令：

        查看分支：git branch

        创建分支：git branch

        切换分支：git checkout

        创建 + 切换分支： git checkout -b

        将某分支合并到当前分支：git merge

        删除分支：git branch -d

git 文件冲突 :

分支 1 中有个文件跟其他分支文件一样，如果同时发生修改了，进行合并，就出现文件冲突问题。