Rules for Organizing the Development Process for IT Projects: Branches & Commits

Is it good when everything takes place according to the rules and the processes are well-established? The answer YES is obvious, because it increases the sense of control and ensures the mental health of all team members.

Marina Fomenko, a project manager of the Software Development Hub, shares her experience in organizing the development workspace for IT projects.

Our company has some simple rules that seem obvious at first glance, but thanks to them, the development and release processes have become more controlled. We are going to discuss the principles of branching and commits that we employ for completing projects at SDH. Let's take a look at them.

Names of branches

The name of branches for tasks must begin with the name of the task itself. Each task or story should be placed in a separate branch.

In our work, we use Jira to control the execution of tasks and Bitbucket as a version control system, because the synchronization with each other makes it easier to navigate the project.

The branch should be named as follows, for example:

LOUN-10-Branch-name,

• where LOUN-10 is a key task in Jira
• Branch-name is the name of the task itself, which, by the way, should prompt action and reveal the essence of the task.

Commits

What to write in the commits?

The commitment should contain a brief description of what was done — LOUN-10 Commit message_message. For example: 

[LOUN-10] added_user_registration.

In such a way, it will be easier to find the right commitment when needed. I remember my first company where I worked, where developers just used to put "+" in the commits without thinking. Bad experience!

Working and release branches

Working branch: Main

You can name it differently, development, current, etc., as you wish, but within the company for all the projects, this name should be the same. It is necessary to do, as in case you need to attract a new developer, he has to know initially where to branch from, rather than looking desperately for the one.

After the release is formed and all the necessary tasks are gathered in main, then main is merged into pre_release. This very version with the compiled release should be demonstrated to the customer. For this purpose, it is necessary to have a separate pre-release stage, which will be purely for the customer, for his/her needs. After the customer reviews and approves the release, pre_release branch is merged into the release branch. Such a release will be put into production. Thus, for some time release and pre_release will be identical until the next pre_release or hotfix update.

Hotfixes

For such cases, there should also be a separate task for which a branch will be created. Hot_fixes go to release immediately after verification. Next you need to do a back merge in pre-release and main, and after that, to update other working branches from main. This is necessary to make each branch as relevant as possible and to exclude even minor conflicts during the next merger.

Thus, we always have a freezed pre-release branch, intermediate between working and release one.

Frequency of commits

Make commits every day, or even several times a day!

This will protect you in situations when the computer fails. Such an easy rule to follow, but not everyone manages to do it. In our company SDH it does work.

Categories