最近杂七杂八的东西记得挺多的…这里主要是记录了工作的时候用到的git命令的顺序和用法。

情况是这样的:

master 分支

master 永远处于稳定状态,这个分支代码可以随时用来部署。不允许在master分支直接提交代码。

 

develop 分支

开发分支,包含了项目最新的功能和代码,所有开发都在 develop 上进行。一般情况下小的修改直接在这个分支上提交代码。

 

feature 分支

如果要改的一个东西会有比较多的修改,或者改的东西影响会比较大,请从 develop 分支开出一个 feature 分支,分支名约定为feature/xxx,开发完成后合并回 develop 分支并且删除这个 feature 分支。

 

bugfix 分支

如果我们发现线上的代码(也就是 master)有 bug,但是这个时候我们的 develop 上的有些功能还没完成,还不能发布,这个时候我们可以从 master 分支上开出一个 bugfix 分支(记住:直接在 master 上提交代码是不允许的!),分支名约定为bugfix/xxx,在这个分支上修改完 bug 后需要把这个分支同时合并到 master 和 develop 分支。

 

git message 规范

针对git提交的message信息,网上查看了一下总结了如下的部分规范,大家先试用一下。

 

首先记录一下刚才的提交流程。

情况是这样的。

我目前工作任务编号是 169581, 该工作属于重构工作。

它的上级工作编号是 169580,属于重构工作。

169580 的上级就是dev …

这里的 分支就是: dev  feature/169580  feature/169581

 

然后我如果要得到 feature/169581 分支。

我就应该先从 dev 里面得到 169580 然后再从 169580 得到 169581 …

 

这些不赘述了,接下来是提交部分。

 

假设我完成169581的编码工作了,需要进行提交。

则对应操作如下:

 

git stash  ——暂存

git checkout feature/169580  ——切换到169580分支

git pull  ——拉取可能存在的其他人的最新提交

git checkout feature/169581  ——切换回到169681分支

git rebase feature/169580  ——对当前分支的上级分支进行变基 —— 具体参考pro git 2

git stash pop ——取出暂存

git add … ——这里根据修改,确定哪些要提交

git commit -m”……” ——根据前面的修改信息,提交对应的信息

git push origin feature/169581  ——最后提交到远端分支

 

接下来属于内部操作了…在 git4u 上面提交 MergeRequest 到 上级分支 feature/169580

这里记住如果是多次修改 feature/168581 则不需要再次提交 合并请求。

 

 

第二种:直接覆盖本地上次修改,强行push到远端

git add *

git commit –amend  ——修改上次提交,wq确认保存(两个减号)

git push -f origin feature/169581 ——强制push到远端

 

本地rebase 合并之前的提交记录

git rebase -i featur/169580

这里的下划线要替换成版本号。

比如 git log

A

B

C

D

A是最新的,然后呢我要把 ABC这三个记录合并起来。

就应该用 git rebase -i D

 

 

 cd ptp

bundle install
【NetEase】Git提交流程 – 记录
Tagged on: