struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukasz Lenart <>
Subject Re: Git flow
Date Thu, 06 Feb 2014 08:33:57 GMT
The only things that needs clarification is when to use
feature/support/hotfix prefix.

- hotfix is obvious (I think) - security vulnerabilities
- feature - something big, like Struts2 for example :-)
- support - daily work with JIRA tickets?

wdyt? Or I messed up everything :-)

+ 48 606 323 122

2014-02-06 Lukasz Lenart <>:
> git-flow applied!
> Please check if everything os ok (I'm not sure what else I suppose to
> do instead calling git flow init -d)
> Regards
> --
> Łukasz
> + 48 606 323 122
> 2014-01-29 Lukasz Lenart <>:
>> Just added info about git-flow
>> 2014-01-29 Lukasz Lenart <>:
>>> 2014-01-28 Rene Gielen <>:
>>>> Am 28.01.14 12:19, schrieb Lukasz Lenart:
>>>>> I don't think we need git-flow - we don't have huge development team,
>>>>> there is (almost) no situation when we work together on some
>>>>> issue/feature. And learning the whole flow is useless (at this
>>>>> moment).
>>>> Then I'm wondering a bit why we wanted to move to git in the first
>>>> place. It was my impression that we wanted to profit especially from
>>>> advanced processes like easy feature branching and merging, e.g.
>>>> - isolate features to make their impact better assessable
>>>> - allow for (yet not require!) code reviews before features are merged
>>>> to mainline - especially useful for our new committers, IMO
>>>> - allow cherry picking for releases
>>>> - backporting features from development to stable branches
>>>> - allow for collaborative working on groundbreaking features and ideas
>>>> for new major versions
>>>> - allow isolated work and straight forward, well documented processes
>>>> for hotfix releases, including multiple merging to all working branches
>>>> - allow for external contributions while working on new features, solely
>>>> targeted towards such feature
>>>> ... to name just a few.
>>> All these points are valid for git, but they don't proof that we must
>>> use the git-flow ;-)
>>>> As for me, I did not find it hard to learn git-flow to a level that I
>>>> felt my own and my team's productivity increased. I started with forcing
>>>> myself to work based on feature branches and the follow-up processes,
>>>> only to to find me loving it soon and missing it everywhere where I was
>>>> forced to use e.g. svn where such processes are PITA.
>>>>> I'd rather start with something simpler and what we can understand and
>>>>> explain each others - using git-flow means we must understand how it
>>>>> works in first place and it isn't just to read some blog posts -
>>>>> understand the whole philosophy behind.
>>>> I agree that git-flow is not the only possible way to go, and that we
>>>> might want to establish our own solution. Of course, it is well thought
>>>> out and flexible for both keeping things simple if you want to, as well
>>>> as offering advanced tooling for advanced problems. In either case -
>>>> adapting git-flow or working out our own process - I would opt for a
>>>> model that is both easy to use and grows with our needs. I see advanced
>>>> needs if we start our work on S3, and if we might manage to attract more
>>>> contributors along the way. Certainly we would want to establish a flow
>>>> that does not limit ourselves in future, wouldn't we?
>>>> Just to give an example, I started some prototyping experiments on how
>>>> multiple possible return value types and result containers could work
>>>> out (inspired by Spring MVC and Play). To advance on this, I would like
>>>> to share this and have others review and potentially collaborate on
>>>> this. But for a rather long time, this might stay experimental and not
>>>> ready even for development branches that we might want to offer
>>>> adventurous users to use in their projects. I'm pretty sure that there
>>>> might be a lot of such experiments and ideas that develop around the
>>>> idea of bringing out a new major release.
>>> Ok, I'm still not fully convinced but it doesn't make sense to spend
>>> more time on this topic - let's adopt the git-flow!
>>> Regards
>>> --
>>> Łukasz
>>> + 48 606 323 122

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message