The GitLab documentation mentions the complexity of the Git flow approach in “Git flow and its problems”: http://docs.gitlab.com/ce/workflow/gitlab_flow.html#git-flow-and-its-problems
The first problem is that developers must use the develop branch and not master, master is reserved for code that is released to production. It is a convention to call your default branch master and to mostly branch from and merge to this. Since most tools automatically make the master branch the default one and display that one by default it is annoying to have to switch to another one.
CASE A: If you locally develop on the master branch you would have to:
- git checkout master # edit, commit
- git push -u origin jon-wip-123 # push to named feature branch on remote GitLab server
- create a merge request
- git fetch origin # fetch remote changes without effect on local branches
- git merge origin/master # or create some other tmp branch just for the merge
CASE B: Or, work on jon-wip-123:
- git checkout -b jon-wip-123 master # create feature branch, edit, commit
- git push -u origin # push current branch
- create a merge request
- git checkout master
- git fetch ; git merge origin/master # or: git pull
- git checkout jon-wip-123
- git merge master # merge other changes into jon-wip-123
Did I get the rationale right? The question arose because generally it is advised against working on the master branch, while workflows intentionally may differ.
If CASE A is bad, then what would be the point of the quoted passage in GitLab documentation? Thanks.