一个较为复杂的开发分支流程: 可分为:master主干分支、hotfix修复BUG分支、release发布分支、develog开发分支、feature特性分支 一般可以采取的做法为: master主干分支:用于打Tag标签(对应某个release发布分支,并不是每个Tag标签一定对应一个release发布分支,hotfix分支也可以合并到master分支以产生对应一个Tag标签), 此外,一般release产生Tag标签如1.0->2.0,而hotfix产生的Tag标签则如0.1->0.2,其必须保证可以正常运行 hotfix修复BUG分支:应只负责修复master分支时的BUG,修复BUG时从master主干分支创建hotfix分支,修复后合并到master分支再打新的Tag标签、以及合并到develop分支 release发布分支:主要用于发布版本,当然也可以修复某些个BUG,若是修复某些BUG则可以在必要时合并到master主干分支再打新的Tag标签, 以及合并到develop分支,这个分支一般不做功能增改、只需要关注小BUG修改和合并等事宜 develop分支:一直处于开发状态,其为代码中心分支,包括自身BUG修复,或者从其创建feature特性分支以在特性分支上添加新的功能,当develop分支到合适时候可以合并 发布到release分支,并以此release发布分支合并到master分支再打Tag标签 feature特性分支:主要增加新的功能特性,从develop分支创建并完成后需要与develop分支合并,此后便可删除该特性分支,一般情况下feature特性分支可能有多个。 以上的这些分支中:一般使用项目的用户可能使用master分支或者release发布分支,开发者用户一般使用到feature、hotfix、develop分支 这些分支中,master、develop分支最重要。发者还需要记住当前所处的分支以及各个分支的状态、创建、合并分支等操作。 鉴于以上手动操作的复杂性:建议使用辅助工具git-flow,帮助管理,减少操作出错 git-flow流程: 0. github上创建远程仓库 1. git clone该仓库到本地 2. 进入该仓库所在目录,使用git flow来初始化默认仓库设置 git flow init -d,-d参数此会默认产生master、develop这两个分支 3. 同样地在远程仓库创建develop分支(以分支develop设置为跟踪来自origin的远程分支develop) git push -u origin develop 4. 后面的操作便是其他开发者fork或者git clone到其本地仓库进行修改develop分支,对该分支进行操作前应先git pull最新github上 的develop代码,此后再进行开发,修改完成后可以git push操作或者Pull Request操作 步骤: 0. git clone 远程的develop分支到本地仓库 1. git pull 获取最新源码(第一次git clone时已为最新源码) 2. git flow feature start xxx 创建feature分支xxx,xxx一般以有意义的当前实现某功能命名,该分支为feature/xxx 3. 在新创建的分支中实现功能(包括写代码、提交到本地特性仓库)后并提交到远程对应的特性仓库 git push origin feature/xxx 此操作后,可在github上创建Pull Request合并到develop分支请求(可在github上设置默认处理发送请求的分支,一般为develop分支) 4. 审查该Pull Request合并请求,若没有问题,可将其与develop分支合并,否则反馈问题该请求给提交者 5. 基本上若有问题需要返工则可能会重复3.4步骤直到可以满足合并的要求便可关闭该请求,或者拒绝时也可以直接关闭该请求 一般反馈的问题可能有:没有测试或者测试未通过、编码规范不到位、代码质量不高、还可以重构、有重复的部分等 6. 请求合并后,提交者若要进行新的功能开发,应先更新本地develop分支,然后再从最新的develop分支重新创建新的特性分支 进行开发,git checkout develop,git pull,git flow feature start feature-other,git push origin feature/feature-other 7. 重复创建特性分支提交分支、合并分支、更新develop分支到一定适合时便可发布,此时使用到release分支,创建release分支 git checkout develop,git pull,git flow release start '1.0.0',创建发布分支release/1.0.0 8. 在release分支中可以修复bug或者结束发布分支与develop分支合并 git flow release finish ‘1.0.0’,此后便会输入一系列信息 包括合并到当前develop分支、删除release/1.0.0分支、对应release分支打tag标签(git tag 可查看)、合并到master分支并打相同 标签、切回到develop分支 9. 提交develop分支到远程develop仓库,git push origin develop 10. 切换到master分支,并提交master分支到远程master仓库并push标签信息,git checkout master,git push origin master, git push --tags 11. 如果master分支或者发布版本的标签分支出现突发BUG,需要紧急修复,此时需要从该master或某tag标签下分支下创建hotfix分支, 如:以tag 1.0.0创建hotfix分支1.0.1: git flow hotfix start '1.0.1' '1.0.0' 12. 完成修改后,便可提交到远程仓库中,git flow hotfix finish '1.0.1'(此会使得其自动合并到本地master和develop分支中), git push origin master,git push origin develop 13. 创建tag 1.0.1,需要在github的release中draft a new release创建,此后本地仓库可以更新并查看tag,git fetch origin, git tag 以上这些流程,建议时常查看a-successful-git-branching-model开发流程图,以便于理解流程内容;
Git仓库维护:
0. Fork或者clone来的仓库,可能与原仓库源码不是最新的,需要时常更新以与原仓库一致
1. Fork某原仓库至github账户下
2. clone该Fork后的仓库至本地仓库
3. 给原仓库设置某个简易的名称,如update-project,并将其作为远程仓库;也即是以update-project作为原仓库的标志符号
git remote add update-project git@github.com:some-user/some-project.git
4. 从原仓库中(远程仓库)的master分支下获取(拉取fetch)最新源码并与自己本地仓库的分支进行合并
git fetch update-project
git merge update-project/master
5. 一般在创建特性分支时,一定要确保在最新源码的基础上创建,故先将仓库更新到最新源码状态。