git五个区域
- 工作区:也就是我们平时对文件进行的增删改,都是在工作区中。
- 缓存区:工作区中的文件在确定准备commit时,需要通过add命令添加到缓存区,之后才能通过commit生成提交记录。
- 贮藏区:在缓存区中的文件通过stash命令可以进入贮藏区,也可以随时提取出来。
- 本地仓库:就是本地的git仓库了,我们在起步就成功创建了一个本地仓库。
- 远程仓库:就是远程的git仓库了,可能是来自于github, gitee或者公司自己搭建的gitlab, gitea等等平台。
正常工作流程
- 需求分析
- 拆分需求,将需求分为多个功能,并创建多个功能分支(分支可以从稳定分支拉出)
- 功能分支开发完合入开发分支,部署开发环境,如果没有问题即可合入测试分支并部署让测试人员提测,待提测完成后可合入vt分支并部署,待测试在vt上进行回归测试。
目前分支情况
- master 主分支
- dev_0131 开发分支(dev)
- release_0131 测试分支(sit)
- vt_0131 vt分支
针对基座main工程的工作流
假设需要在基座开发一个上传组件和一个选人组件。
开发步骤:
- 需求分析后:通过需求从开发分支 release_0131 (注意:这边要从最稳定的分支检出)拉出两个功能分支 feature–上传组件 和 feature–选人组件
- 开始开发 feature–上传组件 ,开发完将 feature–上传组件 分支合入 dev_0131 分支并通过jeakins部署
- 将 feature–上传组件 分支合入 release_0131 分支并通过jeakins部署,提测
- 如果提测有问题回到第2步骤,如果提测没问题,将 feature–上传组件 分支合入 vt_0131 分支并通过jeakins部署提测;vt提测有问题也是要重新回到第2步骤
目前常见问题
问:功能开发到一半,来了一个测试release_0131缺陷需要优先处理
答:
方法一(推荐):将功能区代码 add 到缓存区,再将缓存区的代码 commit 到本地仓库,这个时候因为功能还没开发完成所以commit你可以自己备注:“feat:xx功能开发30%”;然后切换到测试分支,从测试分支拉一个修复分支出来修改缺陷,等缺陷修复完后合入开发分支并部署进行自测,待自测完后将修复分支合入测试分支并部署,通知测试验证下缺陷。
方法二:将功能区代码 add 到缓存区,再将缓存区代码 stash 到贮藏区,这个时候再切换到测试分支拉一个修复分支出来修复。
方法三:不管当前开发到哪里,先将工作区的区的内容提交到本地仓库,切记不要推送到远端仓库,然后直接修改缺陷,如果当前分支无法修复缺陷就切到可以修复缺陷的分支,直接修复缺陷。等修复缺陷并提交到本地仓库时,将缺陷修复的 commit 挑出来 cherry-pick 合入到开发分支部署自测,自测完后从开发分支把修复的 commit 用同样的方式 cheery-pick 到测试分支并部署。
命令总结
- init 创建一个本地仓库。
- clone 将远程仓库拉取到本地仓库。
- add 将文件从工作区添加到缓存区,本文使用了git add .来进行添加,也可* 以git add xxx来指定文件名。
- commit 将文件从缓存区提交到本地仓库。
- push 将本地仓库同步到远程仓库。
- pull 从远程仓库同步到本地仓库。
- checkout 切换分支,git checkout -b xxx则可以创建并切换到xxx分*支,没有-b便是切换。
- merge 合并分支。
- status 查看当前工作区和缓存区的内容。
- log 查看提交记录。
- branch 查看和操作仓库所有分支。
- stash 将缓存区内容提交到贮藏区,个人不推荐使用。
- tag 可以在当前提交记录生成一个标签。
- blame 追溯一个指定文件的历史修改记录
注意:(两个一定)
每次push代码前一定要先pull代码
提测自己开发的功能一定不要把别人的代码也提交上去