GIT & Branching Model

What is GIT?

GIT is an distributed version control system, an open-source project. We can use GIT for small projects or big projects.

How Many Types of Version Control System?

At this time, we have 2 major types of version control system. They are:

• Distributed Version Control System (DVCS), such as: Git, Mercurial, ..
• Centralized Version Control System (CVCS), such as: SVN, Perforce, ...

How Does CVCS Work?

In CVCS:

• we have the central server. All the source-code of the team will be stored there.
• Each member of the team will checkout the code directly from server.
• After modifying code on their local, developers need to push their changes directly into server code. Thus, other member can see those changes.

How Does DVCS Work?

In DVCS:

• All the source-code of teams will be stored on central server (remote) as in CVCS.
• Developers need to checkout the code from this server if they wish to work on it.
• There is another version of GIT on their local. So developers will temporarily push their changes to this local git server.
• Developers can push all their local changes to remote at once if they want.

Which Type of Version Control System (DVCS or CVCS) is Becoming Popular Nowadays?

DVCS(GIT) was used by most users around the world as many benefits were utilized by its user.

Could You Tell Me What Are Those Benefits?

OK, DVCS or Git users can gain the following benefits:

• Each developer PC has its own local GIT server, SO they can share code together without committing that code to the central server.
• The source code was pulled to their local PC. So they can modified the code and temporarily commited to local GIT without internet connection.
• After modifying the code, they can commit to local GIT and push to remote once when the Task was completed. This makes sure that developer only pushes completed code to remote server (central server).
• Un-completed code will be temporarily committed to local git. Only completed code will be pushed to remote server, so developer rarely breaks others by committing mistake code (such as: un-buildable code, ...)
• Pulling/pushing changes to local GIT, so it will be done faster
• We spent less time to solve conflict when merging local changes to remote server as we temporarily commited on local and only push to remote once the task was finished.

OK, I Understand An Overview About CVCS and DVCS, What Can I Learn More in This Article?

In this article, we will learn how to use GIT with branching model and use it with source-tree.

So, What is Branching Model?

Branching model is a process that defines what we should do:

• When implementing new task?
• How did we fix a bug?
• How did we prepare for new release version?
• How did we do a hot-fix (bug on production)?

We Use GIT as Source Code Repository for Our Team, Is There Any Workflow for using GIT that Maximize the Co-operate Between Member?

For using GIT, we have Git-flow process, it is useful for team co-operation.

This can help us to avoid a lot of mistakes related to development process.

Where Can I Use GIT Flow for My Team?

In GIT flow, it specifies:

• How did we implement task?
• How did we fix a bug?
• How did we prepare for new release version?
• How did we do a hot fix (bug on production)?

What Should I Do Before Starting?

In branching model, we have "master" and "developer" branch. "master" branch is where we contain production code, "develop" branch contains code for development of new features.

We also need to config this also.

In source-tree, click on "Git Flow" icon at the top-right and leave the setting as default. Click on "OK" button:

What Should I Do When Implementing My New Task?

When implementing a new task, we need to create a new branch (called feature branch). Your task will be implemented and committed into this branch.

When the task is finished and carefully checked, we will merge this feature branch into develop branch.

OK, How Can I Do It in Source-tree?

I assume that your task is "Implement user login" and taskId is #01.

Click on "Git flow" toolbar item again and select "Start new Feature":

Input name of branch into "Feature Name" textbox in format:<task id> <task name>:

Note: Please do not change option in "Start At" as default.

In Preview region, we can understand that:

• The system will checkout the lasted code from development branch (develop branch).
• Then it will create new "feature/01_Implement_user_login" from development branch.

When Config the git-flow in Source-tree, We Leave It as Default Value for Now. Can I Change it to other-values if Needed?

Yes, you can change it to whatever you want. As shown in the image below, I change name of "feature branch prefix" to "custom-feature":

Can I Change Name of Development Branch and Production Branch?

Yes we can. But aware that production branch should be the existing branch.

Can You Tell Me More on How to Merge Branch in GIT?

Merging from branch A into branch B. GIT will apply all changes of branch A into B. It is required that A is an ancestor of B or they have the same ancestor.

For merging from branch A to branch B, please follow the steps in order:

• Pull the lasted code in branch A from remote server to local.
• Pull the lasted code in branch B from remote server to local.
• Merge from B to A and resolve conflict if any. Then commit into local.
• Merge A to B and commit to remote.

When Finishing My Task, I Should Merge It into Development Branch (named develop) as Mentioned in Branching Model. There are so Many Conflicts. Can We Avoid This?

There are so many conflicts, it means there are so many differences between your branch and develop branch. There are some reasons as below:

• Your branch was created a long time ago.
• It is a long time, we did not merge new changes from develop branch into your feature branch.
• Your team can make a huge number of changes in a short time.

Ok, What Should I Do if "My Branch was Created a Long Time Ago"?

It is a long time you cannot finish your task/ feature (so we can not delete your branch).

• It can be your task is too big. So a long time was required for implementing that task. For this case, we need to consider break the tasks into smaller isolated tasks. So each task will be implemented in less time and your feature branch will exist for a shorted amount of time.
• It can be a big task and I cannot break it into a smaller task. For this case, we should merge from develop branch into your feature branch more frequently.
• It can be a considering feature waiting for client acceptance. It is ok for this case as it rarely occurs.

What Should I Do if "It is a Long Time, We Did Not Merge New Changes from Develop Branch into your Feature Branch"?

Normally, we should merge development branch (named develop) into your feature branch frequently. This will help your branch update new change made by other members in the team.

Merging from develop branch into your branch also help us using some other function/ feature implemented by others.

How many times should we merge or how long should we merge once. It belongs to the number of changes made by your team.

If your team can make many changes (those changes were pushed to develop branch) per days. I suggest that we should merge once at the beginning of your working day, So your code is up-to-date everyday.

If you team makes a few changes or new code is pushed to develop branch around 3 days in average. I suggest that we can merge from develop branch into your branch once for every 3 days.

You should know how to balance between the number of changes we apply to our feature branch on every merging from develop branch into your branch and how long it should be.

What Should I Do if "My Team Can Make a Huge Number of Changes in Short Time"?

As mentioned in the previous question, we should know how to balance between the number of changes we apply to our feature branch on every merging from develop branch into your branch and how long it should be.

We can merge from develop branch in every 4 hours or in every 3 days.

If we merge in a very short time, just a little change applied into your branch and it takes you a lot of time for merging between branch.

If we rarely merge from develop branch into our feature branch, it will be a pain at the time we finish our tasks, as we need to merge our code into develop branch and there are so many conflicts that need to be solved. Another problem, there may be some duplicated feature as we did not know that feature was already implemented by other member in team. This wastes time of our team.

Ok, it is a Useful Knowledge for Me, Can You Go Ahead. What Should I Do for Preparing the Next Release?

There are some problems the team is facing as below:

• After period of development time, the team needs to make a new release to our customer.
• Normally, preparing new release to customer just needs some developer, not the whole team.
• For best utilizing the resources of team, other members will continue implementing new features/ tasks. This should not impact members who are preparing new release.

For solving those issues, in branching model has the Release branch concept. We can use it in this case.

Can You Tell Me More Detail on Using "Release Branch" to Solve Issue of my Team?

Ok, from development branch (named develop), we create "release branch" (for example release 2.0, release 3.0, ...)

For members who working on preparing the new release, they will work on this new release branch.

Other members will continue their tasks normally. Those members should not touch on development branch (named develop).

Ok, It Is Clear to Me. Can You Show Me "How To Do in source-tree"?

Select "Start new release" from the list of options:

In this window:

• We should leave default option in "Start at"
• Input the name for "Release Name". for example "2.0" in this case.

Look at "Preview" section. We understand that GIT will get the latest code and create new branch named "release/2.0".

So developers who work on preparing a new release will work on this branch.

Ok, We Have A New Branch for Preparing New Release. What Should I Do When the Release is Ready?

When release is ready for real release, we will:

• Merge release branch into master.
• Create new tag for this release. Usually, we should name the tag the same name as release branch. Such as: "2.0" in this case.
• Merge release branch into develop branch.

Why Do I Need to Create New Tag for New Release?

Remember, Master is production branch. It contains production code.

When we have more than 1 release (such as release 1.0 and 2.0). We want to checkout the code in release 1.0. We will check out that code from tag named "1.0" as our convention.

Another, source of tag cannot be changed. Checking out the code in tag 1.0. Surely, this is the code at the time that we release version 1.0 and cannot be modified anyone.

Without tagging on new release, we cannot get back that code in future.

Ok, I Understand. But Why Do We Need to Merge my Release Branch Back to Development Branch (Named Develop)?

Release branch was created from develop branch and can be modified during preparing new release. Those changes need to merge back to develop branch.

So in future release, It includes improvements/ changes in previous release.

Ok, please show me how to do it on source-tree?

In source-tree, click on "Git flow" and select "Finish release" option:

Note:

• We should currently be on release branch that we want to finish or you can check again in "Current state" region.
• Just make sure you did not finish the wrong release.

Click on "Finish Release", we see the window as below:

In this window:

• Make sure "Release Name" is the name of the release you want to finish.
• We can check or uncheck Delete branch in "After finishing"
• Please do not check on "Force deletion".
• "Preview" explains that will be done if we click on "Ok"

Click on "Ok", we can see that there is new tag (named 2.0) was created and code in your release branch will be merged into master/ develop branch:

Ok, Now I Have a New Release and Deploy to my Client Production. Unlucky, They Notify Us of a Serious Issue that Needs to be Fixed as Soon as Possible, What Should I Do in this Case?

In branching model, we need to create a hotfix branch from master branch. The issue will be fixed there and merge back to develop and master branch.

The Bug is on Master Branch and on Production Server, Why Do I Need to Merge Back to Develop Branch?

Currently, the production has that issue. It means that code in your develop code also has that issue.

Future release will also have this issue if the hotfix was not merged back to develop branch.

 

For more information, Please have a look my slide at http://www.slideshare.net/TuTran10/fullstack-requiste-git-sourcetree

CodeProject

Thanks for reading.

Note: Please like and share with your friends if you think this article is useful, I would really appreciate it.