GIT(分布式版本控制系统)的工作原理

SVN（集中式版本控制系统）

中央服务器是完整的，commit动作直接连接服务器执行

GIT（分布式版本控制系统）

都是完整的，功能更强大，自然而然操作更复杂一些。git在本地也是以git版本库的形式管理，可以在本地做一些修改，然后commit到本地的版本库，最后push到服务器。

还有啥呢，如CVS、VSS....但和SVN一样都是单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。（没用过，了解也不多）

工作原理

工作区间: 即我们创建的工程文件， 在编辑器可直观显示；

缓存区: 只能通过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 
#如果删除之前修改过并且已经放到暂存区域的话，则必须要用强制删除选项 -f
git rm -f 
#想把文件从暂存区域移除，但仍然希望保留在当前工作目录中
git rm --cached 


#移动或重命名工作区文件。
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 


#回退版本。
#--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 
#推送到远程仓库
git push origin 
#一次全部推送本地未推送的标签
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 %Cgree

n(%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提交规范

提交的信息很重要，可以方便我们查阅日志，建议大家认真填写，可以参考规范：（如下）

(scope)：

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(购物车):满增满减活动返回结算价因浮点问题导致不精准问题'

　　审核编辑：汤梓红