git开发流程
在开发中,正确使用 git 能让开发事半功倍,下面我简单介绍一下在开发中的一些常见 git 操作。
分支功能介绍
我们在项目开发中,会用到如下几个不同分支。
序号 | 分支 | 介绍 |
---|---|---|
1 | dev | 内网编译分支 |
2 | test | test 环境编译分支 |
3 | release | 待发布分支,也可以看做是外网分支 |
4 | master | 外网分支,只是commit 记录更加简洁 |
5 | feature/* | 功能分支 |
6 | bugfix/* | bug 分支,用于修复外网 bug |
不同的分支在不同的应用场景中扮演着重要的角色,所以,选择正确的分支进行开发至关重要。介绍分支显然不能脱离它的应用场景,那么,先了解一下我们开发时常见的场景有哪些。
开发中,常见的有主要有如下几个场景
- 内网开发新功能
- 修复未发布到外网的 bug
- 修复已发布到外网的 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
分支再merge
到dev
和test
分支,让 bug 修复在 dev 和 test 环境都生效。
rebase 还是 merge
虽然,rebase
和merge
都可以合并代码,但是,也不能乱用。
什么时候该用rebase
,什么时候该用merge
?
牢记一个原则,相同基准的分支,用rebase
操作,已经提交到远端的 commit,不要进行rebase
。
比如,我从远程的dev
分支合并代码到我本地的dev
分支,可以使用rebase
。
另一种情况,比如我本地有一个分支feature/#xxx
是从远程的release
分支创建的,我在feature/#xxx
新增了一些提交,在 push 到release
之前,我们可以去rebase
release
分支。
- 本博客所有文章除特别声明外,均可转载和分享,转载请注明出处!
- 本文地址:https://www.leevii.com/?p=2700