git规范 ​

git 代理 ​

解决方法就是加速访问 github,本人使用蓝灯的全局代理功能

再配置 git 代理

git config --global http.proxy 127.0.0.1:51252
git config --global https.proxy 127.0.0.1:51252

以上设置后就可以随意git 操作GitHub仓库了

撤销 git 代理

git config --global --unset http.proxy
git config --global --unset https.proxy

查看 git 配置

git config --list

权限管理 ​

GitLib有五种身份权限，分别是：

• Owner 项目所有者，拥有所有的操作权限
• Master 项目的管理者，除更改、删除项目元信息外其它操作均可
• Developer 项目的开发人员，做一些开发工作，对受保护内容无权限
• Reporter 项目的报告者，只有项目的读权限，可以创建代码片断
• Guest 项目的游客，只能提交问题和评论内容

基本使用命令 ​

git branch  显示所有分支 
git pull origin master  拉取远程主机master分支上的内容
git push origin master 把本地内容推到远程主机master分支上
git branch b1 从当前分支创建一个叫b1的分支 
git checkout b1 切换到b1分支 
git checkout -b b1 相当于以上两条命令的组合 
git checkout master 切换到master主分支 
git merge b1 把b1分支的代码合并到master上 
git branch -d b1 删除b1分支，不能在被删除分支上执行

使用行为规范 ​

• 创建自己的分支，在自己的分支上进行开发
• 写好每次提交的 description 是个好习惯
• 需求完成或者 bug 修复后，利用自动化部署工具部署 dev 分支的代码到测试环境进行验证
• 自测通过后将分支合并到dev分支提交到远程主机

分支规范 ​

主分支Master ​

首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。

开发分支Dev ​

主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Dev。

这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Dev分支进行"合并"（merge）。

Git创建Dev分支的命令：

git checkout -b dev master

将Dev分支发布到Master分支的命令：

• 切换到Master分支

git checkout master

• 对Dev分支进行合并

git merge --no-ff dev

这里稍微解释一下，上一条命令的--no-ff参数是什么意思。默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Dev分支。

使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。

临时性分支 ​

前面讲到版本库的两条主要分支：Master和Dev。前者用于正式发布，后者用于日常开发。其实，常设分支只需要这两条就够了，不需要其他了。

但是，除了常设分支以外，还有一些临时性分支，用于应对一些特定目的的版本开发。 临时性分支主要有两种：

• 开发功能（dev-*）分支
• 修补bug（fixbug）分支

这两种分支都属于临时性需要，使用完合并以后，临时分支不要提交到远程代码库，使得远程代码库的常设分支始终只有Master和Dev。

开发功能分支 ​

接下来，来看这两种"临时性分支"。 第一种是开发功能分支，它是为了开发人员独立开发不受其他干扰，从Dev分支上面分出来的。开发完成后，要再并入Dev。

分支的名字，可以采用dev-*的形式命名。

• 创建一个分支：

git checkout -b dev-x dev

• 开发完成后，将分支合并到dev分支：

git checkout dev
git merge --no-ff dev-x
git push origin dev

修补bug分支 ​

后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。 修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Dev分支。它的命名，可以采用fixbug-*的形式。

• 创建一个修补bug分支：

git checkout -b fixbug-0.1 master

• 修补结束后，合并到master分支：

git checkout master
git merge --no-ff fixbug-0.1
git push origin master

• 再合并到develop分支：

git checkout develop
git merge --no-ff fixbug-0.1
git push origin dev

代码合并打tag ​

一个迭代上线并且线上回归结束后，我们通常要做两件事：

1、Developer提交Merge Requests，备注当前版本号，申请将该迭代分支合并到master分支

2、Master审核通过merge代码之后，对master分支打个标签，以便标识和快速退回到此版本；TAG版本号和应和项目版本号保持一致。例：TAG-1.0.0 TAG-1.0.1 ...

打tag可以通过git平台手动操作或通过以下命令行：

git checkout master
git tag -a 1.0.0

提交PR ​

打开命令行，关联upstream原始仓库

$ git remote add upstream https://github.com/xxx/xxxA.git

内容创作完成后，执行下面的命令，

# 全量提交
$ git add .

# or 提交某个文件
$ git add 文件名

# commit，添加commit信息
$ git commit -m 'message'

# push推送到fork远程仓库
$ git push origin master

# 保持同步原始仓库
$ git fetch upstream

完成推送后，打开Fork到自己仓库GitHub地址，选择Pull requests，点击New pull request

按照规范填写title及备注信息，点击Create pull request即可完成提交

最后等待审核者审核即可。