Branching
strategies
Reached this point, you may
have already asked your self: “Okay, branches are cool, but when should I
create and merge them?”
When we want to carry out a
version control, we need to know which strategy we are going to
follow. Using Git without having a clear branching policy is a complete
nonsense.
The branching workflow to
follow depends, mainly, on how we want to maintain the code. In this
section, we will see the two main branching strategies.
Long
running branches
This strategy is used when
we want to maintain a single version of our software at the same time.
That is, when we offer the last version of our software as available, instead
of having many versions (which can be still available, but considered as old or
unmaintained).
The key of this strategy is
having a branch only for stable versions, where the releases are tagged, for
which the default branch is used, master; and having other branches for
development, where the features are developed, tested, and integrated.
In this strategy, the master branch
is the production branch, so only tested, properly integrated, definitive
versions should be here. Or, there can also be under-development or not fully
tested versions, but they must be properly tagged.
The following graph shows an
example of the history of a repository following this strategy:
Simple and clarifying. The production
state is only modified for those changes that have been integrated with the
development branch, where nothing happens if something breaks. The changes that
have to be made for each feature are perfectly isolated, favoring the division
of tasks among the teammates.
One
version, one branch
This workflow is
thought for creating software that will be available and maintained for
several versions. In other words, a release does not “overwrite” every previous
releases, it would “overwrite” only the release of the branch the release has
been made for.
To achieve this, each
maintained version has to have its main version, but with a common development
path for all of them.
This is done having a branch
for every version (usually named PROJECT_NAME_XX_STABLE or similar)
for the stable release, the “master” of each version; and having a main branch
(and its sub-branches) where the development is made, for which default master branch
can be used. When each feature is developed and tested, the master branch
can be merged to every wanted stable version.
This branching strategy is
based on the long-running, but, in this case, having many “masters” instead of
a single one.
Take into account that each
feature should have to be tested with each version of the project we want to
apply this feature to. Consider using Continuous Integration when dealing with
this strategy.
Let’s see an example of the
graph of a history for which this strategy has been applied.
As we can see, here,
the master branch is used as the main development branch.
In the v3.0 version, we have
simulated a bug for feature1. It does not have to be necessarily a bug
appeared at integration time, it can be a bug that has been detected later. In
any case, we are sure that bug of feature1 only exists for v3.0
version. In these cases, we shouldn’t fix these bugs in master branch,
because it’s not something that affects all the versions. We should create a
branch from the affected version, fix the bug, and merge to the specific
branch. And, if the future the same error persists for new releases, we can
consider the option of merging it to master.
The main advantage of this
strategy is that the common features follow a common path, and the specific
changes can be perfectly isolated for the affected versions.
Regardless
the branching strategy: one branch for each bug
No matter the branching
strategy you use, an advisable practice is to create an independent branch for
every bug, as same as it has been reported in your bug tracker (because you use
a bug tracking system, right?). Actually, we have seen this practice in the
previous example, in the integration of the feature into the branch for v3.0
version. Having an independent branch for each bug allows to having the
issues perfectly located and identified, having the changes fixed involves
isolated from others.
Identifying this branch with
the id number generated by the bug tracker for the given bug, naming the
branches, for example, as issue-X, allows to have a track between the
changes made for the fix of that bug, to the comments made in the corresponding
ticket of the bug tracker, which is really helpful, since you can explain
possible solutions for the bugs, attach images, etc.
<< Previous Next >>
No comments:
Post a Comment