Gitlab protects master branches

Ok still learning the differences between Github and gitlab. The good news is that the basic git commands do work properly between them, but the semantics are a little different.
The biggest difference is that GitHub.com is completely flat, there is no hierarchy of repos, whereas with gitlab, you can have arbitrary nest of projects and then subproject, so the names look more like auto/project/market rather than just a repo name.
The second is that a GitHub pull request is a gitlab merge request, they are doing the same thing and the users interface for accepting an MR is a little different.
The other confusing thing is that gitlab protects the master branch so the canonical series:
git checkout -b rich-edits
...make some changes...
git commit -a
git push
git checkout master
git pull --rebase
git checkout rich-edits
git rebase master
git rebase master -i
git push -f
git push origin rich-edits:master

Will fail on the last step because the gitlab protects the master by default. This makes sense for most projects, you never want to push into master, you should issue a merge request to yourself, but if you are working fast, then the answer is to disable the protection at the master level.
This is the gitlab settings in the repo called settings/Protected Branches and you can disable it.

CategoriesGeek

%d bloggers like this: