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).
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. That being said, I opt to work out our own flow - simple and straight forward. There can be advantage - we must adjust our release process to the flow as well. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ 2014-01-24 Rene Gielen <rgie...@apache.org>: > Hey Lukasz & others, > > sorry for chiming in a bit late, I'm suffering from heavy workload > currently. > > Basically this idea looks quite good and straightforward to me. On the > other hand, kind of a standard, named git-flow, seems to have > established, which I find worth evaluating: > > http://nvie.com/posts/a-successful-git-branching-model/ > > Not only that it is well documented and contains all the (corner) cases > we might need, there is also excellent tooling support: > > https://github.com/nvie/gitflow offers extensions to git to add workflow > semantics to your branching process, e.g. starting a feature: > git flow feature > git flow feature start <name> [<base>] > git flow feature finish <name> > Besides more examples on what the git extension does, you will find > further excellent explanatory resources linked on this page. > > IntelliJ IDEA also has git-flow support: > http://plugins.jetbrains.com/plugin/7315 > While there were some issues reported lately, development seems to be > active and I already used it successfully in version IDEA 12 > > Atlassian Sourcetree, IMO the most complete git shell on the planet, has > also excellent support for git-flow. The following is also a great read > describing the concepts and processes behind this branching model, in > addition to the original article quoted above: > http://blog.sourcetreeapp.com/2012/08/01/smart-branching-with-sourcetree-and-git-flow/ > > The Atlassian blog also contains an overview over various well > established workflows, including git-flow - also well worth reading: > https://www.atlassian.com/git/workflows > > What I like about git-flow > - well documented - so well that we don't have to document it ourselves ;) > - well thought out > - very organized > - clean branch naming, including "subdirectories" for branches; that is > branches are named LANE/TOPIC - e.g. hotfix/s2-099 > - there is quite users / future contributors are already familiar with > this workflow, since they might be using it at work > > Just my $0.02 > René > > Am 16.01.14 08:01, schrieb Lukasz Lenart: >> Hi, >> >> As Struts migrated to Git it's time to plan what kind of git flow we >> are going to use. >> >> I thought about something like that: >> - 'master' contains always the latest released source (also as a tagged >> version) >> - 'develop' contains the next version and we can commit some small >> patches directly to it >> - 'branch-xxx' will contain large modifications and refactors >> - 'feature-xxx' will contain huge modifications, like Struts3 >> -- 'feature-xxx-yyy' will contain branch of feature branch >> >> The naming schema can be adjusted but I think it should be simple and >> straightforward. >> >> >> Regards >> > > -- > René Gielen > http://twitter.com/rgielen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
