git开发流程

在开发中,正确使用 git 能让开发事半功倍,下面我简单介绍一下在开发中的一些常见 git 操作。

分支功能介绍

我们在项目开发中,会用到如下几个不同分支。

序号分支介绍
1dev内网编译分支
2testtest 环境编译分支
3release待发布分支,也可以看做是外网分支
4master外网分支,只是commit记录更加简洁
5feature/*功能分支
6bugfix/*bug 分支,用于修复外网 bug

不同的分支在不同的应用场景中扮演着重要的角色,所以,选择正确的分支进行开发至关重要。介绍分支显然不能脱离它的应用场景,那么,先了解一下我们开发时常见的场景有哪些。

开发中,常见的有主要有如下几个场景

  1. 内网开发新功能
  2. 修复未发布到外网的 bug
  3. 修复已发布到外网的 bug

内网开发新功能

按照我们现在的开发流程,新功能肯定会对应一个需求号,我们依据于需求号进行开发。

假如,我们有一个需求号为1650,这时候需要创建一个功能分支feature/#1650。问题来了,该从哪一个分支去创建?

由于新功能开发不能夹带没有升级到外网的代码,我们需要保证开发的分支是干净的。所谓干净的分支,就是说分支的代码要和外网的代码保持一致,而release分支正好对应的是外网的代码,所以,开发新需求,我们需要从release分支去创建功能分支。

为了保证 release 分支最新的 commit 记录,先 fetch 一下。

git fetch origin release

然后,以远程release为基准创建功能分支。

git checkout -b feature/#1650 origin/release

在开发中,我们可以在feature/#1650分支上提交很多个 commit 记录,到达一个开发阶段之后,比如需要给产品测试,我们需要把代码提交到内网 dev 环境,由于dev分支对应的是 dev 环境,所以,我们需要把功能分支上的提交合并到dev分支上。

首先切换到dev分支。

git checkout dev

我们选择rebase方式合并代码,为了不破坏原始的提交记录,让记录保持线性。

git pull origin dev --rebase

之后执行合并操作。

git merge "feature/#1650" --no-ff -m "merge: 合并#1650需求 (story#1650)"

如果出现冲突,解决冲突,解决完冲突继续合并。

git merge --continue

合并结束后,将最终代码push到远程dev分支。

git push origin dev

你可以把feature/#1650分支推送到远端,也可以选择不推送。如果推送的话,要记得在release发布之后将功能分支及时删除,防止无用远程分支过多。

修复未发布到外网的 bug

每一个 bug 肯定对应一个 bug 编号,而禅道上的 bug 肯定是经过产品或测试的同事测出来提的 bug,所以代码肯定是已经发布到 test 环境中了。那么,我们修改 bug,可以在本地的test分支中直接修改,改完直接push到远程的test分支。

首先,切换到test分支。

git checkout test

然后在test上修改 bug。

git add .
git commit -m "fix: xxxxx (bug#123)"
...
git commit -m "fix: xxxx2 (bug#123)"

改完之后推送到test分支。

git pull origin test --rebase
git push origin test

由于 test 环境的编译时定时的,有可能提交之后不能立即看到效果,如果需要线上看到效果,可以将test的改动合并到dev分支,合并方式和上面合并功能分支的方式类似,不再赘述。

修复已发布到外网的 bug

外网出 bug 肯定要在外网的代码基础之上去修改。所以需要从release分支去创建bugfix分支,这里创建分支需要携带 bug 号。

假如 bug 号是123,首先从release创建bugfix/#123分支。

git checkout -b bugfix/#123 origin/release

然后在bugfix/#123修复 bug,之后提交到远程的bugfix分支,如果没有则创建。

如果想在 dev 环境立即看到修复效果,就合并到 dev 环境中,操作方式上面已经介绍过了,不在赘述。

等到 bug 全部修复结束时,准备发布外网环境,我们需要将远程的bugfix分支合并到release分支并删除bugfix分支。并且把合并过后的release分支再mergedevtest分支,让 bug 修复在 dev 和 test 环境都生效。

rebase 还是 merge

虽然,rebasemerge都可以合并代码,但是,也不能乱用。

什么时候该用rebase,什么时候该用merge

牢记一个原则,相同基准的分支,用rebase操作,已经提交到远端的 commit,不要进行rebase

比如,我从远程的dev分支合并代码到我本地的dev分支,可以使用rebase

另一种情况,比如我本地有一个分支feature/#xxx是从远程的release分支创建的,我在feature/#xxx新增了一些提交,在 push 到release之前,我们可以去rebase release分支。

如果您觉得本文对您有用,欢迎捐赠或留言~
微信支付
支付宝

发表评论

您的电子邮箱地址不会被公开。