前言
最近看到很多文章都在说写文档的重要性，从今天开始也要注意培养自己的总结能力，不断写些文档，为了别人入门，同时也为了自己很久不用之后更快的复习。
公司里一直用的SVN，但是感觉市面上用Git的更多一点，便找一些文章入门，正好廖雪峰大神的主页里有教程，这篇文章便来源于此。
1、为什么要用Git
在我大学期间，开发过一个程序来计算基因的相似度，首先试用A方案计算，后来又改为B方案，再后来又想在A方案的基础上进行改进。但是这时候A方案的代码已经删了，没办法，只能重写，写完之后觉得还是改进B方案可能更好一点。。。
当时就很苦恼，后来想个办法把代码存很多份，但是这样有很多问题，第一，很难同步；第二，你需要有很强的记忆力。
其实我当时缺的就是一个版本控制工具，通过版本控制工具，我们可以
- 知晓每次修改的内容和目的
- 创建分支，每个分支按照不同的方案解决问题，同时可以方便的同步
版本控制分为分布式与集中式。
集中式是指代码放在服务器，所有功能都是通过服务器实现，产品有SVN。
分布式是指每个人的电脑上都有一套完整代码，并可以使用各种功能，如果不联网知识多人协作代码合并比较困难，产品有Git。
本文就是简易的Git教程，git下载地址 下载安装不必多言。
2、git版本库创建
- 将一个文件夹变为git可以管理的仓库
git init - 将一个文件上传到缓冲区，提交时这些代码将要放到仓库里
git add <file> - 将缓冲区的文件上传到仓库
git commit -m <message>
参数：-m 文件修改说明
3、版本管理
- 显示仓库当前的状态，比如那些文件修改了
git status - 显示文件变化，比较本地文件与仓库里文件的不同
git diff <file> - 显示提交日志
git log
参数：--pretty=oneline显示简单的日志 - 版本回退
git reset --hard <commitid>特殊版本号：- HEAD表示当前版本
- HEAD^表示当前的上一个版本
- HEAD~100便是距离当前的第100个版本
- 当版本回退到旧版时，通过
git log无法获取此版本之后的提交日志，这时候要用git reflog - 将工作区的修改删除，使用
git checkout -- <file>，这里分两种情况
- 修改未上传到缓存区，这时文件将会与版本库的文件一致。
- 修改已上传到缓存区，之后又做了修改，这时文件将与暂存区的文件保持一致。
- 删除某个文件
git rm <file>
4、分支管理
项目开发过程中中一般使用5种分支
| 分支 | 位置 | 来源 | 作用 | 合并到 |
|---|---|---|---|---|
| master | server | 主分支 | ||
| dev | server、local | master | 开发分支 | |
| feature | local | dev | 开发新功能 | dev |
| release | server、local | dev | 提测并修复bug | dev、master |
| hot fix | local | master | 修复紧急bug | dev、master |
下面是经典的分支控制图
- 创建分支
git branch dev - 切换到分支
git checkout dev或git switch master - 创建并切换
git checkout -b dev或git switch -c dev。 - 查看当前项目有哪些分支
git branch，当前分支前会有一个*号。 - 分支合并
git merge <branch>。
不使用参数是快速提交，直接将Head指向分支的最后一个节点。
使用--no-ff此时会多出一次commit，commit日志显示分支合并信息。 - 删除分支
git branch -d dev。 - 你现在有一个master分支，在此基础上新建了dev分支来开发新特性，dev分支有文件修改后，如果此时你切换到master分支，你会发现文件都发生了相应的修改。
当你开了一个dev分支，修改了某些内容，但是还未完成无法提交。此时突然有一些紧急bug需要修复，假设你需要在master分支修改，当你切换到master分支时，你会发现文件是被改过的（同上一条），此时运行git status会显示dev分支里的修改，这时候你就需要保存工作现场。在dev分支使用git stash，这样执行git status就不会显示更改内容了 git stash list显示储存列表git stash pop恢复储存内容，相当于git stash apply git stash drop- 当你需要使用过去的提交记录修改当前分支，使用
git cherry-pick <commit>
5、关联远程库
将你的代码上传到Github这样如果本地电脑硬盘出了问题，还能从Github上下载，另外别人也可以访问你的代码。
- 首先你需要提供连接凭证，可以使用SSH连接，在本地打开Git Bash，输入
ssh-keygen -t rsa -C "youemail@example.com"，这样在C://user/username/.ssh目录下有id_rsa和id_rsa.pub两个文件。id_rsa是私钥，不能泄露，id_rsa.pub是公钥，需要提供给Github。然后登录Github，找到SSH keys添加，填写任意title，在key文本框中粘贴id_rsa.pub文件中的内容。 - 将本地仓库与Github仓库相关联
git remote add origin git@github.com:yourname/xxx.git - 将本地内容推送到远程库
git push origin master
第一次推动服务器时需要加参数 -u，另外第一次会得到一个警告，选择yes - 在本地创建与远程分支对应的分支
git checkout -b <branchname> origin/<branchname> - 将本地分支与远程分支关联
git branch --set-upstream <branchname> origin/<branchname> - 同步远程代码到本地
git pull - 将远程库复制到本地
git clone git@github.ccom:yourusername/xxx.git - 查看远程库信息
git remote -v
6、多人协作
多人协作也是主要参考上面的分支管理图，这里主要讨论一下涉及服务器端的项目管理。
- 项目负责人在Github服务器上创建master分支。
- 在Github上建dev分支用于开发。
- 开发人员在本地同步Github上的dev分支与master分支。
- 在本地创建feature分支开发新特性。
- 在本地将feature分支合并到本地的dev，然后删除该分支。
- 将本地dev分支的修改提交到Github上的dev分支。提交之前需要获取最新修改，如果有冲突解决冲突，使用
git rebase将log转换为一条直线（可选）。 - 重复4-6直到迭代开发完成。
- 项目负责人在Github上通过dev分支创建release分支，并提交测试。
- 开发人员在本地同步Github上的release分支。
- 在release分支修复测试人员提出的bug。并提交到Github上，提交之前的操作与dev提交之前的操作一致。
- 如果有需要可以先把代码合并到dev分支。
- 重复13，14直到版本稳定。
- 项目负责人在Github上将release代码合并到dev分支与master分支。然后删除release分支，并通过
git tag v1.0给master分支打上1.0,2.0这种大版本的标签。 - 当线上出现需要紧急修复的bug时，
开发人员首先同步Github上的master分支， 然后在本地通过master分支创建hot fix分支，修复bug， 并同步到本地的dev分支与master分支。 然后提交到Github上，提交之前做一套拉取、解决冲突的操作。 项目负责人给master打上1.1,1.2这种小版本的标签。
