NO local master branch? A git/GitLab workflow with a protected master branch

GitLabHQ's GitLab is an awesome source code management system. It lets you set up self-hosted git service similar to the famous github in your inner networks. GitLab supports role-based permission and protected branch, which allows finer control over development workflows.

Two roles are commonly seen in GitLab/git workflow, that is, the project developers and project masters. The developers have NO write permission to a protected branch which usually refers to master. On contrast, project masters have ALL privileges over all branches.

Developers and masters fight with each others to see who contribute more to the project. The story about GitLab workflow starts here...

For developers: DELETE Local Master Branch

For poor developers, things are simple: + Delete Local Master Branch and Stay on Your Own Branch
+ Always fetch from orign + Always merge origin/master into YOUR_BRANCH locally. + Always push your changes to origin YOUR_BRANCH.

I will show you how to be a nice developer.

  1. Clone the project.

    $ git clone GIT_URL LOCAL_PROJ_NAME
  2. Work on your own branch and forget about the local master branch from NOW. Pleas READ this section because it is extremely critical.

    First, list all remote branches to check if YOUR_BRANCH is already there.

    $ git branch -a

    If the answer is YES, just checkout.

    $ git checkout YOUR_BRANCH

    Or if the answer is NO, you need to create your own (currently local) branch. -b option does this.

    $ git checkout -b YOUR_BRANCH

    Finally, check your current branch. Make sure you are on YOUR_BRANCH.

    $ git branch
  3. Yes, I'm totally sure of that. DELETE your local master branch because you don't need it. Its existence brings more bad than good.

    $ git branch -D master
  4. Hack on your own branch and push your branch to remote repo for backup. You don't want to merge your branch into master because your code is still in an early stage.

    $ git add .; git commit
    $ git push origin YOUR_BRANCH
  5. You reach a milestone in your branch and eagerly merge your branch into master. Wait... It would be kind to first merge master's changes into your branch. And trust me, it won't take much time--just fetch and merge.

    Firstly, you fetch changes, all branches' changes by default, from the remote repo.

    $ git fetch origin

    Then, merge remote master's changes into YOUR_BRANCH. Manual conflict resolve may be required.

    $ git merge origin/master
    $ git add .; git commit
    $ git push origin YOUR_BRANCH
  6. Happily tell the project master to merge your branch into master. You can send a pull request or send a email.

So you, the developers, go into an infinite loop like this:

$ git add .; git commit
$ git fetch origin
$ git merge origin/master
$ git add .; git commit
$ git push origin YOUR_BRANCH

What's wrong with my local master branch?

Well, there is nothing wrong with your local master branch. Master branch is still in the repo, you can checkout to master whenever you want. But, as local master branch will arise much confusion, it is highly recommended that you forget it.

Please! Please! Please! DELETE your local master branch!!!

How often should I pull/merge master's changes into my branch?

It depends. You are supposed to fetch and merge master's changes into YOUR_BRANCH from time to time. At least, you should do it before you send a pull request or, when the project master shouts at you.

For masters

For masters, great power comes with great responsibility. It is you that do all the master-merge work. It sounds not that difficult to do the job, but takes great carefulness to do it well.

Pull command will do the job. git will first try to merge the changes automatically. git says nothing if auto merges work, or it will prompt if conflicts arise.

  1. Switch to local master branch.

    $ git checkout master
  2. Update local master.

    $ git pull origin master
  3. Fetch and merge changes form other developers' branches.

    $ git fetch
    $ git merge origin/DEV_BRANCH
  4. Resolve conflicts if needed.

    $ git add. ; git commit
  5. Push changes to remote master in repo, then ask your developers to fetch and merge.

    $ git push origin master

Comments !