Hi Jakob,

I have a few comments based on my experiences using Git-Flow... See inline
below.

On 13 May 2013 22:12, Jakob Frank <[email protected]> wrote:

> Hi all,
>
> last week I fixed some issues in LDPath (MARMOTTA-197, MARMOTTA-221) which
> should be also backported to a future 3.0.1 bugfix-release.
>
> To keep track of such things I propose the following branching workflow for
> releases and backports:
>
> At the moment, we have two branches in the git-repository: master and
> develop.
>
>    - All development should be done in the develop-branch. This is also the
>    branch that is tracked by the jenkins server.
>

In my Git-Flow projects I have a Jenkins Job that runs against master only
when it detects changes in Git, not a regular daily integration test.


>    - When we feel it is time for the next release, develop is merged into
>    the master-branch, where the actual release process then takes place.
> (tag,
>    update of version numbers, release-process related fixes (N&L), etc.)
>

In the Git-Flow methodology there is a temporary "release-N.N.N" branch
created to bump the version numbers and do QA. This temporary branch is
then merged into both master and develop so that you never need to have a
backwards merge from master to develop.


>    - In the meantime, development can continue on the develop branch.
>    - After a successful release (vote has passed), the changes in master
>    are merged back into develop.
>

See above. In Git-Flow this is the point where the temporary branch is
merged into both master and develop, so that before this point master is
still stable at the last actual release.


>    - For backports/bugfixes in a released version, we start a new branch
>    from the release-tag (e.g. "3.0.x-bugfix" for the 3.0.0-incubating
> release)
>    where the bugfixes are applied. From this branch we can then do the
> bugfix
>    releases (e.g. 3.0.1-incubating).
>

+1. This is by far the easiest way to do minor bug fixes.


>    - Changes to the bugfix-branch(es) should be done by cherry-picking [1]
>    commits from the develop branch (as far as this is possible). Use the -x
>    option!
>
+1


>
> So, what do you think?
>
> Best
> Jakob
>
> [1] <https://www.kernel.org/pub/software/scm/git/docs/git-cherry-pick.html
> >
>

Reply via email to