我们有哪些版本控制的工具？

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常用手册之-提交规范