我以04官网为例子,在我开发页面的时候,第一步是先切到生产分支,然后不要用vscode自带的操作,改用git pull拉取最新代码,,此时生产的页面是这样的
我再从develop拉出一个测试分支Jenkins,以及预发布分支release,此时我的需求是这个"开发分支"改成"本地分支",页面文字统一改成绿色,而我的同事需要给页面增加一个跳转按钮.我们的代码要合并无误发布在开发分支上
然后我先从develop拉出来一个changeWord分支,然后修改代码
随后提交代码
然后我切到Jenkins分支,在这个分支上merge我的代码,我所理解的merge和rebase的区别就是,merge就是合并两个分支的代码,创建一个合并提交，提交会连结两个分支的提交历史,缺点就是同时保留了两边的提交记录,提交历史会看起来很混乱
而rebase会造就一个线性的项目提交历史,假如我的分支是feature,如果git rebase main,我可以把feature分支的起始历史放到main分支的最后一次提交之上,也就是说可以从feature分支的顶部开始向下查找到分支的起始点，而不会碰到任何历史分叉.
git merge成功之后,我先把项目跑一遍,确定没问题,再推到远程仓库,然后发测试,测试无误之后,再提一个pr到release
此时再跑一遍release.确认无误之后发测试,测试通过之后再发pr合到develop
发完生产,立马再测试生产页面.
然后再说另一头,我的同事,此时开发按钮已经完成,提交代码之后,切换到Jenkins分支
此时 git merge自己的分支就出现冲突了,修复冲突之后,跑一遍页面确认,再git push origin Jenkins
发测试没问题之后,切到release和develop,分别git pull最新代码,在切换到原分支pushButton, git rebase release,此时就出现了冲突
先解决本地的冲突，解决完冲突后，先将本地修改放进暂存区：
git add .
add更改文件，不要commit，而要git rebase --continue,最后强推到远程分支
然后就可以提一个pr到release
测试无误之后,同理,先切换到release,然后git pull release更新代码, git rebase develop,随后在提pr合进develop,发布生产
测试开发分支代码无误
