【NetEase】Git提交流程 – 记录

最近杂七杂八的东西记得挺多的…这里主要是记录了工作的时候用到的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

 

关于记录合并：

• pick：保留该commit（缩写:p）
• reword：保留该commit，但我需要修改该commit的注释（缩写:r）
• edit：保留该commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e）
• squash：将该commit和前一个commit合并（缩写:s）
• fixup：将该commit和前一个commit合并，但我不要保留该提交的注释信息（缩写:f）
• exec：执行shell命令（缩写:x）
• drop：我要丢弃该commit（缩写:d）

 

分支合并：

当我开发完branch功能，需要合并到dev时：

git checkout dev //切换到分支dev

git merge tk // 将tk分支的代码合并到master上

最后push到origin…

 

cd ptp

bundle install