一、版本控制
版本控制，通过文档控制记录各个模块的改动，并给每次改动添加序号，用于存储、追踪目录和文件的修改历史。
二、版本控制软件
-
GIT 分布式版本控制系统
每个人的电脑都是一个完整的版本库；
团队中，张三修改文件1，李四修改文件2，项目整合就只需要各自修改的推送给对方即可；实际中，很少两人间互相推送，为了通常也会有一个'中央服务器'；服务器仅仅提供服务，方便交换大家修改的内容；
-
SVN 集中式版本控制系统
版本库是集中存放在中央服务器中；
在每次操作时，都需要从服务器获取最新的版本；
在操作完之后，都需要把自己做的推送到服务器中；问题:
必须联网才能工作；
网络不好时； -
GIT和SVN区别
相对于集中式版本控制系统，分布式版本控制系统的安全性要高很多，因为每个人电脑都有完整的版本库，假如有人电脑坏了，也不会影响到其他的人工作。集中式版本控制系统，当服务器奔了，全部人都不需要干活了。
三、GIT的由来
很多人都知道，Linus在1991年创建了开源的Linux，从此，Linux系统不断发展，已经成为最大的服务器系统软件了。
Linus虽然创建了Linux，但Linux的壮大是靠全世界热心的志愿者参与的，这么多人在世界各地为Linux编写代码，那Linux的代码是如何管理的呢？
事实是，在2002年以前，世界各地的志愿者把源代码文件通过diff的方式发给Linus，然后由Linus本人通过手工方式合并代码！
你也许会想，为什么Linus不把Linux代码放到版本控制系统里呢？不是有CVS、SVN这些免费的版本控制系统吗？因为Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。
不过，到了2002年，Linux系统已经发展了十年了，代码库之大让Linus很难继续通过手工方式管理了，社区的弟兄们也对这种方式表达了强烈不满，于是Linus选择了一个商业的版本控制系统BitKeeper，BitKeeper的东家BitMover公司出于人道主义精神，授权Linux社区免费使用这个版本控制系统。
安定团结的大好局面在2005年就被打破了，原因是Linux社区牛人聚集，不免沾染了一些梁山好汉的江湖习气。开发Samba的Andrew试图破解BitKeeper的协议，被BitMover公司发现了，于是BitMover公司怒了，要收回Linux社区的免费使用权。
Linus可以向BitMover公司道个歉，保证以后严格管教弟兄们，嗯，这是不可能的。实际情况是这样的：
Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！牛是怎么定义的呢？
Git迅速成为最流行的分布式版本控制系统，尤其是2008年，GitHub网站上线了，它为开源项目免费提供Git存储。
四、GIT的安装
-
windows安装
1、git下载 - https://git-scm.com/downloads - https://pan.baidu.com/s/1kU5OCOB#list/path=%2Fpub%2Fgit - 360软件管家 2、安装git(不要出现中文路径和空格) 3、配置环境变量(我的电脑 — 右键属性 — 高级系统设置 — 高级 — 环境变量) - git命令是bin目录下 4、检测git是否安装成功 - cmd 打开命令行 - 查看git版本 $ git - -version - 查看帮助 $ git helpMac中直接下载对应的xxx.dmg安装，在终端中使用，使用方式基本操作都是一致的。
-
Linux安装
- 安装 $ sudo apt-get install git - 检测是否安装成功 $ git --version
五、GIT操作 【本地仓库】
-
什么是版本库
版本库又被称为仓库repository，初期可以理解为一个目录，这个目录里面管理的文件都可以被称为被git管理起来的，每个文件的修改，删除等的操作git都能进行跟踪。 -
设置GIT
// 后续代码是托管到GitHub中的，所以这里直接设置成GitHub的用户名和GitHub邮箱 $ git config --global user.email "zyz@1000phone.com" $ git config --global user.name "zyz" -
创建版本库
- 切换到需要添加版本控制的目录中 $ cd dir/ - 初始化本地仓库 $ git init会在对应目录中会看到
.git目录，就是用来跟踪管理的版本库，千万不要手动修改该目录的文件。 -
添加本地git忽略清单
.gitignore【说明哪些文件是不需要被管理的】
忽略规则是一行一个(根目录和其他目录，目录名相同时，即加上对应路径，如果是根目录则是“/”);在项目开发中，有时候想把某些目录或文件加入忽略规则中，但在清单中添加之后发现是无效的。即是某些文件已经被纳入了版本管理中，则修改. gitignore是无效的。解决方法:
git add .
$ git commit -m '更新gitignore忽略清单'
最好是在项目开始时，创建好. gitignore文件！ -
查看本仓库的变更状态
$ git status // 查看仓库当前的状态 $ git status -s // 输出简要的变更日志 文件状态说明: ' ' 没有修改 'A' 被添加到本地代码仓库 【add】 'C' 冲突 【clash】 'D' 被删除 【delete】 'I' 被忽略 【ignore】 'M' 被修改 【modification】 'R' 被替换 【replace】 'X' 外部定义创建的版本目录 '?' 文件没有被添加到本地版本库内 '!' 文件丢失或者不完整（不是通过git命令删除的文件） '~' 受控文件被其他文件阻隔 -
添加本地托管(暂存)文件
- 添加指定文件名的文件 $ git add index.html - 添加通配符匹配的文件 $ git add *.js - 添加所有未托管的文件(忽略.gitignore清单中的列表) $ git add . // 或使用 $ git add - -all
-
提交被托管的文件变化到本地仓库(版本库)
$ git commit -m "提交代码对应的版本说明" 备注: 自动创建的一个分支master
注1: -m后面输入的是本次提交的说明【就是所谓的日志】，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录
注2: 再次修改文件，则重复git add和git commit命令
注3: 为什么GIT添加文件需要add、commit两步操作？因为commit可以一次提交很多文件，所以你可以多次add不同的文件 -
对比差异
$ git diff filename // 对比当前版本和存储在本地仓库中最后一个版本的差异 -
查看提交日志
$ git log $ git log --pretty=oneline -
版本回退
工作原理： 每当修改一个文件，并且使用commit提交之后，其实就相当于保存了一个快照 // 回退到上一版本 $ git reset --hard HEAD^ // 回退到上上版本 $ git reset --hard HEAD^^ // 回退到上100个版本 $ git reset --hard HEAD~100 // 指定版本回退 $ git reset - -hard xxxxxx // xxx是对应版本的hash值前6位 // 重返未来(从上往下寻找第一个commit的操作，则是未来的最新的版本) $ git reflog // 查看历史执行过的git操作 $ git reset --hard xxx // 对应的hash值在git中，用HEAD表示当前版本。git在历史的版本之间来回切换，使用git reset --hard commit id
-
撤销操作
a.修改了文件内容，但是还没有添加到暂存区 $ git checkout // 查看可撤销文件 $ git checkout -- xxx // 撤销对应文件，即回到最新版本
六、GIT操作 【远程仓库】
-
GitHub和Git概念区分
- git是一个工具 - github是一个网站 - github网站提供的是git服务(即可以将代码托管到github服务器中) - github服务是"免费的"，但免费服务的前提是开源(如果代码需要闭源服务，即是要收费的) -
github创建代码管理仓库
拷贝对应仓库的地址(注意HTTPS或SSH方式) -
关联远程仓库
- 添加远程仓库并起名叫origin $ git remote add origin https://github.com/cxy/Git.git - 查看现有的服务器列表 $ git remote -v -
删除远程仓库的关联
// 远程仓库的名字 $ git remote rm origin -
推送本地仓库内容到远程仓库
$ git push -u origin master // 提交到服务器中的master分支 -
拉取(获取)远程仓库内容到本地仓库
取回远程仓库的变化，并与本地分支合并。$ git pull origin master // 从master分支中获取代码 -
克隆(下载远程仓库)
从零开发，先有远程仓库，之后从远程仓库克隆。// 将远程服务器中代码克隆一份到本地 $ git clone https://github.com/userName/projectName test // 没有指定每次，默认即是仓库名 $ git clone https://github.com/userName/projectName
七、HTTPS和SSH认证方式
-
HTTPS方式
- git remote add origin https://github.com/iphone3.test.git - git push -u origin master 或 git pull origin master 【每次操作都需要输入账号密码】与远程仓库交互时，可以是HTTPS和SSH方式两种，更多建议使用SSH方式，操作更加简单!
-
SSH方式(要进行了SSH认证)
- git remote add origin git@github.com:iphone3/test.gti - git push -u origin master 或 git pull origin master创建的仓库中，操作可以是HTTPS和SSH的选择
八、GitHub中SSH认证
- 创建 .ssh 目录
$ mkdir ~/.ssh
- 切换到.ssh目录中
$ cd ~/.ssh
- 配置全局的name和email(如果已经设置，即忽略该操作，这是用于标示一个人)
$ git config --global user.name "zyz" // 两个横杆，中间不需要空格
$ git config --global user.email "zyz@1000phone.com"
- 生成key
$ ssh-keygen -t rsa -C "zyz@1000phone.com" // 与上面填写的邮箱与之对应
备注: 连续三次回车，密码是设置为空
- 复制.ssh目录中的id_rsa.pub文件内容，即是key (当前用户的目录下)
例如: home/atom/.ssh/id_rsa.pub
- 在github中添加key
View profile and more -> settings -> SSH and GPG keys -> New SSH key
备注:
不要最后的邮箱!!
ssh-rsa和KEY之间就一个空格，后面都不能出现空格，即是一行!
- 检测是否添加成功
$ ssh git@github.com
提示: Hi xxx! You've successfully authenticated, but GitHub does not provide shell access. 说明设置成功
九、分支管理
-
分支的作用
开发中，准备一个新的功能，但需要2周时间才能完成。第一周已经写了50%，如果立即提交，由于代码没有写完，不完整的代码会导致其他人也不能干活了。如果等代码全部写再提交，又会存在丢失每天进度的巨大风险。
有了分支，可以避免此类问题。创建一个属于自己的分支，别人看不到，还继续在原来的分支上正常工作。而我们在自己的分支上干活，想提交就提交，直到开发完毕后，在一次性合并到原来的分支上。这既安全，又不会影响到别人工作。 -
特点
Git分支是与众不同的，无论创建、切换和删除分支，Git在非常短的时间呃逆就能完成，无论版本库是1个文件还是1万个文件。 -
master主分支
在版本管理中，每次提交，Git都把他们串成一条时间线(沿着时间轴添加)，在Git中这个分支叫主分支，即master分支。
每次提交，master分支都会向前移动一步，这样不断的提交，master分支线也越来越长。 -
Git分支操作(版本库其实就是一个时间轴)
- 查看分支(当前分支前面会有一个*) $ git branch - 查看分支的日志信息 $ git branch -v - 新建分支 $ git branch version2 // 新的分支version2(主分支是master) - 切换分支(不同分支中，就会显示不同分支下的内容) // 切换分支 $ git checkout version2 // 推送分支 $ git push origin verion2 - 创建与切换同时进行 $ git checkout -b version3 // 创建version3分支，并切换到version3 - 合并分支 // 假如此时操作的是在version2分支中 $ git checkout master // 再进行合并，即将version2中内容合并到master分支中 $ git merge version2 // 将version2分支的工作成果合并到master分支上 // 合并完之后，再推送到GitHub $ git push origin master - 删除分支 $ git branch -d version2 // 删除分支version2 -
分支策略
master主分支应该是非常稳定的，一般都是用于发布新版本，平时此分支上不干活。
干活都在dev分支上，也就是说dev分支是不稳定的，到某个时候，例如1.0版本时，再把dev分支合并到master上，在master分支发布1.0版本。
而你和小伙伴每个人都在dev分支上干活，每个人都有自己的分支，时不时的往dev分支上合并即可。
-
多人协作
- 推送分支 $ git push origin master $ git push origin dev - 抓取分支 从远程库中clone时，默认只能看到master分支内容； 想要在dev分支上开发，就必须克隆origin的dev分支到本地; $ git checkout -b dev origin/dev实际的工作流程：先pull[抓取]，后push[推送]
作者：西门奄
链接：https://www.jianshu.com/u/77035eb804c3
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
网友评论