我和我导师关于工作流的理解产生了不一样的意见:
我理解的git工作流是分支分为master、develop、test、hotfix、release分支几个，master作为主分支存放最新可靠的代码，develop可在多分为多个开发者自己的开发分支，每个开发者提交到自己的开发分支，之后合并到test分支（冲突由开发者自己解决），当测试通过后合并到master分支，之后按照需求固定出release版本。
然后实际操作就是公司的gitlab上有一个公司仓库，所有开发者均使用这个仓库，在该仓库上创建各自的develop分支，并在分支上提交代码，最后申请合并到master分支，导师同意后导师进行合并（由于没有测试，直接合并到master）。
而我导师的理解是公司的gitlab上创建一个公司仓库，而后开发者fork公司仓库在公司gitlab上创建一个新的个人仓库，而后开发者各自将代码提交到各自的个人仓库，最后从个人仓库的master分支向公司仓库的master分支提出合并申请。
导师的理解和我从各种资料以及之前工作学习的git流程不太一样，我不知道是我之前理解的有问题还是我导师理解的有问题。
我认为fork只有非项目开发者需要贡献代码，才会去fork，而项目开发者应该只在项目仓库本身上提交代码，而不是fork出去再提交回来。
gitflow 是对提交到git仓库内容的规范。命名规范，合并规范。遵循gitflow工作流可以产生清晰的提交历史。
图解git flow开发流程 - 知乎
你导师说的github建仓库，fork分支，开发完成后发起一个pull request请求。去merge分支代码到指定分支，可以由相关人对pull request 请求进行 review。这种方式适合开源库模式，或者对代码提交，需要进行review的公司。
原则上你理解的是对的，你导师从另一个角度去解读，也不能说有问题，算是局部是