git flow adoption

[Antoine Sabot-Durand]

Regarding the project, I propose we adopt git flow from Vincent Driessen : https://github.com/nvie/gitflow

It could appears a bit complicated at first but I think it's the best approach to deal with a lot of contributor in a git project. It also have tooling : git extension to deal with the flow (this article give an idea of it : http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/)

reagards,

Antoine

[Werner Keil]

Any plans to use Gerrit?

Werner

[Alain Defrance]

By the way, we're talking about branching model and code formatting, but does the work started yet ?

I checked a bit in github organization but nothing seems public so far.

Alain.

[Antoine Sabot-Durand]

No work started. We finish this vote to have our project and package names first. But we can discuss the organization in paralel.

You're right git flow is a branching and workflow model, not a tool like gerrit.

Please read the articles and give your feedback.

Antoine SABOT-DURAND

[ehsavoie]

Hi,
It looks very complicated.
We use a simplier workflow for our project (maybe because the team is smaller)
- one branch for maintenance of current stable release from which all
fixes are pull request
- one branch for new features are pull request, with of course merge for fixes.
Each developper works on is own repo.
I think it was quite similar for the izpack project, and Debian has
the same kind of workflow.
Why would we require so many branches ?
Emmanuel

----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie

[Alain Defrance]

Actually I already know well this model because we had a lot of discussion about it at exo to take a decision if yes or not we'll use it.

Finally we decided to apply an hybrid branching model (for many reasons).

I think git flow is totally good for project with frequent deploy and enterprises having many stable versions to maintain and integration branch for continuous deployment.

I guess we could use it (because actually in all projects we have feature and stable branches, git flow only name them).

About fix branch, I don't know if it's really necessary for an project API, WDYT ?

I'm not sure that API need to have fix version ...

Release branches are intellectually interesting but in real world i'm not sure it's really mandatory.

Actually at exo we removed develop branch and release branches. We still have fix branch because we have to maintain projects in production without ask and upgrade.

Anyway

[Antoine Sabot-Durand]

Yes I agree it could be a bit complicated, but we can take the good part of this model.

I think the concept of features branch is important : it's a standard way to share idea in progress without impacting people working on the main stream aspect. As we could have a lot scenario and implementation it could be useful.

Release and hot fix are optional. I propose we don't use them except we find it useful during the devs.

As we'll be a very decentralized team with no full time devs I think it's important to standardized the way we use Git. The vertue of this flow is to give a back bone to our work (the optional extension script in git are also quite useful)

regards,

Antoine SABOT-DURAND
---------------------------------------
Blog : http://www.next-presso.fr
Twitter ; http://twitter.com/antoine_sd
LinkedIn : http://fr.linkedin.com/in/antoinesabotdurand
06 08 55 34 26

[Alain Defrance]

If we don't use release branches, what's the purpose of develop branch ?

[Antoine Sabot-Durand]

develop is mainstream and master is the production branch. I'm not sure we'll need a branch to prepare the develop to go to master, but if it's the case we could use release...

Antoine SABOT-DURAND

[Alain Defrance]

Framework projects doesn't need to be deployed, thus don't need production branch don't think so ?

[Antoine Sabot-Durand]

yes but hey need a stable branch and a work in progress branch. any suggestion to have a standard alternative flow is welcome. I thought this one was a good base.

Antoine SABOT-DURAND

[Alain Defrance]

Yes of course.

Thus we probably should use feature and stable branches.

[Werner Keil]

I started using GitHub issue tracker for some things I came across.

For those using Eclipse or JBoss Studio, there is a (slightly hidden;-) Mylyn connector available as documented here:

https://github.com/blog/852-github-mylyn-connector-for-eclipse 

I propose similar to JIRA we may introduce an additional label "task".

I added one called "naming", but I am flexible on that. If you think of other commonly useful tags, please advise or use them if you create an issue. 

Regards,

Werner