struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lukasz Lenart <>
Subject Re: Git flow
Date Sun, 16 Feb 2014 19:47:39 GMT

First flow based on "git-flow" is done ;-) Basically it looks ok, the
only problem is with many comments - you can see it here [1]. In that
case each commit was referencing the JIRA issue. It could be omitted
and only finishing (git flow feature finish) commit message can
contain reference to the issue but Apache Git doesn't present any
graph [2] - so it's hard to figure out what changes were introduced
with that "feature" (when you use SourceTree you will see a nice graph
of changes).

Anyway I opt to use only "finishing referencing" - it reduces noise :-)


+ 48 606 323 122

2014-02-06 9:33 GMT+01:00 Lukasz Lenart <>:
> 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 :-)
> Regards
> --
> Łukasz
> + 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
>>>>>> explain each others - using git-flow means we must understand how
>>>>>> 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