大部分前端的工作模式
- 协同开发,大家都git clone 远程仓库到本地
- 从master上切自己的本地分支进行开发
- 若遇到线上紧急bug需要修复,从master上切一个bug-fixed分支 修复bug后 把此分支merge到master 紧急发布生产
- 然后把bug-fixed的merge到dev分支上 以保持dev和master的同步
- 测试阶段,将自己的本地分支merge到dev分支
- 测试完毕,上线阶段的时候再把自己的本地分支merge到master分支发生产
之前所在的公司几乎都是上述这种工作模式,其优点就是傻瓜式操作,简单易上手
其弊端就是大部分人commit之前不喜欢pull下最新代码 导致会有merge commit,经常也会遇到冲突,然后git树不是线性的
现公司要求的工作模式:
以sourcetree举例
- 协同开发,大家都git clone 远程仓库到本地
- 从master上切feature分支作为本期需求的开发分支
- 所有开发人员从feature分支上切自己的本地分支进行开发 以姓名-模块的形式命名分支
- 每天推送代码之前,先切到feature分支上 git pull最新的代码 并且是用变基代替合并 保证自己本地的feature是最新的代码
- 切回到自己的开发分支,然后右击feature分支 选择将当前变更变基到feature分支上 有冲突则解决冲突
- 将自己的分支推送到远程
- 在gitlab上发起merge request 将自己的分支合并到feature分支上并且指定review的人员 Review通过后由其merge
- 如果线上有紧急bug修复,从master上切bug-fixed分支 修复bug后发起merge request至master 并设定相关Review人，Review通过后，将对应commit cherry-pick至Master分支
git命令行的话则是如下操作
- 克隆远程仓库到本地: git clone 远程仓库地址
- 此时本地默认只有master分支 需要切换到远程的featureA分支: git checkout -b featureA origin/featureA
- 从featureA上切自己的分支开发: git checkout -b 姓名_模块
- 提交代码:git add. + git commit -m '描述' 两连
- 在自己的开发分支git fetch 获取远端所有更新
- git rebase origin/featureA 本地开发分支上所有的变更变基最新的featureA上
- git push -f origin 姓名_模块
- 在gitlab上创建merge request
总结
现公司的工作模式有以下几点是我之前没有遇到过的 更加的规范,有利于多人协同开发的工作模式 继续加油~~
git rebase
变基rebase这个操作说白了就是，重新选定当前提交的根节点
这个操作会把整个本地分支移动到feature分支的后面，有效地把所有feature分支上新的提交并入过来 就能保证git树的线性了
merge request
以前我们习惯于自己在本地进行将开发分支和功能分支进行合并 有冲突解决冲突 然后推送到远端
merge request的作用其实就是多了一层review 由指定的人员review之后再merge
cherry-pick
复制一个特定的提交到当前分支 避免重复劳动 也不用合分支
git cherry-pick 4c805e2