Git: 说说我们的版本控制——实用干货篇
我们有哪些版本控制的工具？
SVN（集中式版本控制系统）
中央服务器是完整的，commit动作直接连接服务器执行
GIT（分布式版本控制系统）
都是完整的，功能更强大，自然而然操作更复杂一些。git在本地也是以git版本库的形式管理，可以在本地做一些修改，然后commit到本地的版本库，最后push到服务器。
还有啥呢，如CVS、VSS....但和SVN一样都是单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。（没用过，了解也不多）
还是说回我们的主角-GIT
工作原理
工作区间: 即我们创建的工程文件， 在编辑器可直观显示；
缓存区: 只能通过git GUI或git shell 窗口显示，提交代码、解决冲突的中转站；
本地仓库: 只能在git shell 窗口显示，连接本地代码跟远程代码的枢纽，不能联网时本地代码可先提交至该处；
远程仓库: 即保存我们代码的服务器，本文以公共版本控制系统：gitlab为例，登录gitlab账号后可直观显示；
浅谈下我们实际场景常用的命令吧
1、配置
#配置邮箱
git config --global user.email "你的邮箱"
#配置用户名
git config --global user.name "你的用户名"
#生成SSH秘钥
ssh-keygen -t rsa -C "你的邮箱"
#查看所有的配置信息
git config -l
#更针对性的
git config --system -l
git config --local -l
git config --global -l
#查看远程库信息
git remote -v
#移除远程地址信息
git remote remove origin
#添加新的地址：
git remote add origin 远程路径
#直接修改远程仓库指向地址
git remote set-url origin 远程路径
#编辑模式修改
git config -e
#设置记住密码（默认15分钟）
git config --global credential.helper cache
#设置记住密码时间
git config credential.helper 'cache --timeout=3600'
#永久保存密码
git config --global credential.helper store
#清除密码
git config --system --unset credential.helper
2、常用命令
#列一下容易遇到需要使用的吧
#拷贝一份远程仓库，也就是下载一个项目。
git clone
#添加文件到暂存区
git add
#将暂存区内容添加到仓库中
git commit
#想修改注释，输入以下命令，会进入默认vim编辑器，修改注释完毕后保存就好了
git commit --amend
#删除工作区文件。
git rm
#将文件从暂存区和工作区中删除
git rm <file>
#如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 -f
git rm -f <file>
#想把文件从暂存区域移除，但仍然希望保留在当前工作目录中
git rm --cached <file>
#移动或重命名工作区文件。
git mv [file] [newfile]
#从远程获取代码库
git fetch
#下载远程代码并合并
git pull
#拉取远程master和本地matser合并
git pull origin master
#拉取远程的master到本地的dev
git pull origin master:dev
#上传远程代码并合并
git push <远程主机名> <本地分支名>:<远程分支名>
#如果本地版本与远程版本有差异，但又要强制推送可以使用 --force 参数
git push --force origin master
#合并
git merge
#删除本地分支xxx 删除分支前先切换到其他分支
git checkout dev
git branch -D tmp
#删除远程分支XXX
git push origin --delete XXX
#查看仓库当前的状态，显示有变更的文件。
git status
#比较文件的不同，即暂存区和工作区的差异。
git diff
#显示暂存区和工作区的差异
git diff [file]
#显示暂存区和上一次提交(commit)的差异
git diff --cached [file]
git diff --staged [file]
#查看历史提交记录
git log #--pretty=oneline
#更简洁的查看
git reflog
#以列表形式查看指定文件的历史修改记录
git blame <file>
#回退版本。
#--soft 不删除工作空间改动代码，撤销commit，不撤销git add .
#--hard 删除工作空间改动代码，撤销commit，撤销git add .
git reset
#回退到上一个版本
git reset --hard HEAD^
#回退到上上一个版本（更多以此类推）
git reset --hard HEAD^^
#回退版本也可以写成HEAD~1、HEAD~2....
git reset --hard HEAD~2
#指定版本号回退
git reset --hard 930c4a7a
#查看分支列表
git branch
git branch -r
git branch -a
#挑拣提交
git cherry-pick
#误删怎么办
git checkout -- test.txt
#创建本地tag
git tag <tagName>
#推送到远程仓库
git push origin <tagName>
#一次全部推送本地未推送的标签
git push origin --tags
#执行存储时，添加备注，方便查找，只有git stash 也是可以的，但查找时不方便识别
git stash save "save message"
#查看stash了哪些存储
git stash list
#命令恢复之前缓存的工作目录
git stash pop
#应用某个存储,但不会把存储从存储列表中删除，默认使用第一个存储,即stash@{0}
git stash apply
#丢弃stash@{$num}存储，从列表中删除这个存储
git stash drop
#删除所有缓存的stash
git stash clear
3、一些辅助操作
git config --global alias.co checkout
git config --global alias.ci commit
.......
#这个我会用
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"
目录中新建了一个.gitignore文件,将想要忽略的文件或者目录保存即可
聊一聊分支设计的规范（良好习惯的养成）
明确一点：规范是死的，人是活的，再好的规范也要团队适合，并且需要团队成员去遵循，没有一成不变的规范
1、软件环境
- DEV 环境（Development environment）：用于开发者调试使用。
- FAT 环境（Feature Acceptance Test environment）：功能验收测试环境，用于测试环境下的软件测试者测试使用。
- UAT 环境（User Acceptance Test environment）：用户验收测试环境，用于生产环境下的软件测试者测试使用。
- PRO 环境（Production environment）：就是生产环境。
2、分支命名
| 分支 | 名称 | 环境 | 可访问 |
|---|---|---|---|
| master | 主分支 | PRO | 是 |
| release | 预上线分支 | UAT | 是 |
| hotfix | 紧急修复分支 | DEV | 否 |
| develop | 测试分支 | FAT | 是 |
| feature | 需求开发分支 | DEV | 否 |
master 分支
master 为主分支，用于部署到正式环境（PRO），一般由 release 或 hotfix 分支合并，任何情况下不允许直接在 master 分支上修改代码。
release 分支（一般在发布日由运维创建，我们公司目前是常驻的pre-production）
release 为预上线分支，用于部署到预上线环境（UAT），始终保持与 master 分支一致，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。
如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。
hotfix /repair 分支
hotfix 为紧急修复分支，命名规则为 hotfix- 开头。
当线上出现紧急问题需要马上修复时，需要基于 release 或 master 分支创建 hotfix 分支，修复完成后，再合并到 release 或 develop 分支，一旦修复上线，便将其删除。
develop 分支
develop 为测试分支，用于部署到测试环境（FAT），始终保持最新完成以及 bug 修复后的代码，可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发。（注：在我们公司不建议直接上面修改）
一定是满足测试的代码才能往上面合并或提交。
feature 分支(我们公司以迭代代号创建)
feature 为需求开发分支，命名规则为 feature- 开头，一旦该需求上线，便将其删除（但可以按照公司习惯，比如删除一个月以前的.....）。
commit提交规范
提交的信息很重要，可以方便我们查阅日志，建议大家认真填写，可以参考规范：（如下）
<type>(scope)：<subject>
type 表示 动作类型，可分为：
-
fix：修复 xxx Bug，有时可在相关commit上加上修复的bug的等级
Blocker (中断) : 客户端程序无响应，无法执行下一步操作 Critical (严重)：功能点缺失 Major (较严重)：功能点没有满足需求 Normal (普通)：数值计算错误，js错误 Minor (次要)：界面UI与需求不符 Trivial (轻微)：辅助描述说明不清楚，提示语句错误之类…
-
feat：新增 xxx 功能
-
test：调试 xxx 功能
-
style：变更 xxx 代码格式或注释
-
docs：变更 xxx 文档
-
refactor：重构 xxx 功能或方法
-
chore：构建过程或辅助工具的变动，比如项目新加了别的js插件之类的
scope 表示 影响范围，可分为：模块、类库、方法等。
subject 表示 简短描述，最好不要超过 60 个字。
如 git commit -m 'fix(购物车):满增满减活动返回结算价因浮点问题导致不精准问题'
往期更详细介绍：Git常用手册之-提交规范