COmanage Developers List

[Arlen Johnson <>]

+1 to both the idea of having a separate branch and to Scott's suggestions.
A

On 2/2/16 10:09 PM, Scott Koranda wrote:
> Hi,
>
> > I've been trying to work out a git strategy for bugfixes that seems easy
> > to understand and track. We've talked about it before, but I don't think
> > we've settled on anything really, so here's my proposal:
> >
> > (1) develop continues to be candidate changes to merge into master
> >      (ie: the next minor release).
> Sounds good.
>
> > (2) Once at least one issue has been assigned to the bugfix release
> >      (eg: 1.0.1), we create a new branch from the appropriate parent
> >      release (ie: develop-1.0.1).
> I think the approach is fine but I would change the name from
> 'develop-1.0.1' to something else since there is already a
> branch named 'develop'. Something like 'target-1.0.1' or
> 'bugfix-1.0.1'.
>
> > (3) Appropriate fixes are pushed to develop-x.y.z, NOT to develop.
> > (4) When ready, develop-x.y.z is merged into master and the usual
> >      release process is followed.
> > (5) master is then merged into develop. (Or develop-x.y.z, I suppose
> >      it doesn't matter.)
> I think that approach is fine but we should be prepared that
> there may be dead-end changes in a branch that should not be
> merged into devlop, or there may be a mixture of things we
> want to merge it and dead-end changes.
>
> > I think this avoids cherry picking as part of the process, which seems
> > cleaner to me.
> We may need cherry picking to grab commits when a branch has
> both things we want to evolve and dead-end changes.
>
> Thanks,
>
> Scott
>
> > Thoughts?
> >
> > Thanks,
> >
> > -Benn-