How to manage bug fixes (and small features) accumulation?

[Mateusz Loskot]

Hi,

As developer experienced with the Subversion and its
Common Branching Patterns [1], I'm wondering if and how
others replicate some of its conventions with the gitflow.

In particular, I'm interested in the point 5 of the SVN Patterns [1]

"""
5. The branch is maintained over time. While work continues on /trunk
for version 2.0, bug fixes continue to be ported from /trunk to /branches/1.0.
When enough bug fixes have accumulated, management may decide to
do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1,
and the tag is packaged and released.
"""

The question is, how to achieve similar bug fixes accumulation in gitflow?

Let's consider simple projcet scenario in Git repository managed with gitflow:

Current state:
1. Current master branch stores released version 1.0.0 (there is also
tag v1.0.0).
2. Current develop branch moved far and includes lots of new features.
3. Number of topic branches with little bug fixes have been created,
but nothing merged yet (equivalent to GitHub pull requests dangling
around and waiting to be merged).

The plan:
1. The develop branch is planned to become release 2.0.0, because it's
got lots of 'dramatic' changes that don't really fit the line 1.x
2. Meanwhile, lots of the bug fixes (and small features too)
accumulated in topic branches based on 1.0.0 should be released as
1.1.0 earlier, before 2.0.0 is ready.

The point 1. of the plan will be achieved using the gitflow release/
branch, as usual.

How to achieve the point 2, what to branch off of?
Creating release/1.1.0 from master does not seem right for gitflow, as
the release is branched off of develop only.
Creating hotfix/1.1.0 from master seems technically right, but
conceptually the "bug fixes accumulation" does not fit well to the
emergency hotfix release. It's more like a regular continuous
maintenance of 1.x line, common pattern in the Subversion workflow.

How to manage such situations when a numerous topic branches or GitHub
pull requests have been submitted, reviewed and are ready to merge,
but release that would follow should not be based on develop which
includes too many new features and is not ready yet, so an
intermediate
release is necessary?

[1] http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
"Participation in this whole process is a form of torture" ~~ Szalony

[Mateusz Loskot]

On 22 September 2013 17:58, Mateusz Loskot <mat...@loskot.net> wrote:
>
> As developer experienced with the Subversion and its
> Common Branching Patterns [1], I'm wondering if and how
> others replicate some of its conventions with the gitflow.
>
> In particular, I'm interested in the point 5 of the SVN Patterns [1]
>
> """
> 5. The branch is maintained over time. While work continues on /trunk
> for version 2.0, bug fixes continue to be ported from /trunk to /branches/1.0.
> When enough bug fixes have accumulated, management may decide to
> do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1,
> and the tag is packaged and released.
> """
>
> The question is, how to achieve similar bug fixes accumulation in gitflow?

> [...]

I think I've found solution for the overall problem I described:
support branches.

In fact, my requirements are the same as explained here [1],
in ticket of a project I accidentally found:

"""
If the master branch contains an 2.0 tag we can no longer hotfix the
previous 1.0 tag. The reason is that the 1.0.1 hotfix branch when
merged back into develop and master will get all the 2.0 commits.
Therefore to allow maintenance of older releases git-flow support
branches will need to be used.
Instead of a hotfix branch a support branch 1.x should be used for
maintenance of old releases? Then create hotfix/release branches off
of support and merge back into support.
"""

[1] https://bitbucket.org/atlassian/maven-jgitflow-plugin/issue/64/add-git-flow-support-branches


This is exactly the problem I'm trying to address.
Hopefully, the support branches will do the job well.

So, I'm going to upgrade to AVH Edition of gitflow and start using
support branches.