A simple git workflow with GitLab

As a part of an E-commerce project based on Hybris Platform for one of our clients, we have used Git as version control system.

Git it easy and has a lot of advantages.

Firstly, it was strange for developers who have worked with SVN for many years. So we have some troubles in particular during commits, branches handling such:
some commits are lost, branches created during merge, issues during merge conflicts ...

So I decide to use a git worklow based on Git best practices:
- Branches naming
- Commits, merge
- Handling merge conflicts

Well, we have already installed GitLab community (A powerful tool for working with git and other interesting features) , so why not use it to handle our workflow, branches, code review...

The workflow that I used is inspired from a good article: A successful Git branching model
writed by Vincent Driessen.

The workflow is the following:

What it's required to work with this workflow ?

Git knowledge: 

You need to know how to use git (I assume that git is already installed and configured).

Hosting code:

A hosting code is required to manage graphically pull requests, handling branches...

Indeed, there are several tools:

1. Github: https://github.com/
2. Gitlab: https://about.gitlab.com/
3. Bitbucket: https://bitbucket.org/product
4. and others...

Gitlab as hosting code:

Gitlab offers many options: cloud, community (CE) and enterprise version (EE).

In Sqli Group, we use Gitlab community version, because it have many advantages:

1. Open source
2. A convenient user interface
3. Can be installed in local server (local database )
4. LDAP integration
5. Snippet support
6. Protected branches
7. Private /public repositories
8. Groups
9. Forks/Merge requests
10. ...

For more details see the following link:  http://www.slideshare.net/roidelapluie/gitlab-intro

The install process of gitlab is not covered in this post. For how to install gitlab,  I suggest the following article:
https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-gitlab-on-ubuntu-16-04

How to work with this worflow ?

The workflow is applied on master branch (to ensure that master is always ready to be delivered )  
It's still valid for any branch: develop, hotfix, release ...

In the next lines, I will show the steps how to use the workflow successfully and some useful git commands.
  
1- Branch creation

For this I suggest to create the branch remotely  in gitlab as following: 

 I can create the branch in local then push it to remote:

 $ git checkout -b branch-ID-JIRA // create a branch and switch to it  
 $ git push --set-upstream origin branch-ID-JIRA // push branch to remote repo  

Note: The option --set-upstream is used to specify the default remote (origin) branch to push.
After we only use git push.

2- Getting the branch 

I use the following commands:

 $ git fetch  
 From https://gitlab.com/Abdou/demogitlab  
  * [new branch]   branch-ID-JIRA -> origin/branch-ID-JIRA
 $ git checkout branch-ID-JIRA

3- Commits in the branch 

I will create a text file for test.

 $ touch demo-worflow.txt  
 $ vi demo-worflow.txt  

First, I add a text. Then I check with git status to detect modifications:

 $ git status  
 On branch branch-ID-JIRA  
 Your branch is up-to-date with 'origin/branch-ID-JIRA'.  
 Untracked files:  
  (use "git add <file>..." to include in what will be committed)  
     demo-workflow  
 nothing added to commit but untracked files present (use "git add" to track)  

The added file is red, so it's untracked (unversioned). It needs to be versioned.

For this I will use:

 $ git add .  

Then git status:

 $ git status  
 On branch branch-ID-JIRA  
 Your branch is up-to-date with 'origin/branch-ID-JIRA'.  
 Changes to be committed:  
  (use "git reset HEAD <file>..." to unstage)  
     new file:  demo-workflow  

Now the file is tracked. so I commit with :

 $ git commit -m " first commit in branch-ID-JIRA"  
 [branch-ID-JIRA d2d6bf4] first commit in branch-ID-JIRA  
  1 file changed, 3 insertions(+)  
  create mode 100644 demo-workflow  

4- Update local master branch 

For this I use:

 $ git checkout master  
 $ git pull   

 
5- Merge local master into our branch

This is an important step, before push of the commits, I should merge master (target source) into our branch (source branch) to detect any conflict and resolve it.

For merge I use:

 $ git merge master  
 Already up-to-date.  

In this case, I can go to next step.

Otherwise, some conflicts can be arised:

The branch branch-ID-JIRA|MERGING means that I have a conflict and my branch it's in a MERGING state. So I resolve the conflict and commit.

There are many ways to fix the conflicts, by using vi editor and  git commands line.

We can also using a  merge tool ( I will write an other post for this):

For now I use gittortoise (A graphic tool as an alternative to git commands line), I can use it as a merge tool.

So to fix the conflict, I use:

 $ git mergetool  

 A window is opened:

So I can resolve this conflict as folllowing:

 

Ther are three options:

- Use the whole file of others (file in master)

- Use our file (file in branch )

- Merge line by line: Use line of other side or the line of our side.

After finishing, I use mark as resolved to save modifications:

Then commit and push.

The result in gitlab after push:

If some troubles occur during merge, I can abort the merge by using :

 $ git merge --abort

6- Push branch to remote repo:

If the merge was successful,  we can push to remote.

 $ git push  

7- Create Merge Request (in other hosting code we also called Pull Request (PR))

 After push, we create a merge request as following:

Then add a reviewer for each merge request, the reviewer can add comments, validate or refuse the merge request.

Note:  There is a limitation in gitlab, we can only add one reviewer unlike in bitbucket which more reviewers can be added.

The merge request is very useful to increase quality code, add useful comments, ideas for refactoring...

8- Accept / Refuse merge request

If all is OK,  reviewer accept the merge request and merge the source branch in the target branch (master in this case).

Note: In some case we find a conflict during accepting merge request.
In this case, the developer who commits should first fix the conflict and then the  MR can be accepted.

Advantages ? 

The are many advantages of using such workflow:

- The master branch is always ready for release process (Or any branch used for release),
- Increase quality code by code review
- Avoid regression and build crash
- Win time :) ....

Hope this first post be helpful for you.

Enjoy it !

Feel free to add your comments, remarks ...