git repo organization

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

git repo organization

VANKEISBELCK Remi
Hi folks,

Just had a peek at the repo, and didn't really understand the branches in there. 

Is master supposed to be the "trunk" (or "develop") ? 
The "version" branches are release branches ?
...

I suggest we follow the Git Flow conventions :

It's a branching model that IMHO works fine in small-medium projects. It is commonly used and therefore easy to understand, by convention. 

The idea is to have a "develop" branch (LATEST-SNAPSHOT) to be used for "day to day" development (and feature branches if you want), and a "master" branch for releases (and release branches).

You can install the Git Flow command line tooling for easy management of all this. It's really a useful layer over git IMO.

What do you think ?

Cheers

Remi

PS : I'm taking 1.6.0 out for a spin, trying to see if I can upgrade in Woko... I use loads of extensions so I guess it's a good test. Will let you know. 

------------------------------------------------------------------------------

_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development
Reply | Threaded
Open this post in threaded view
|

Re: git repo organization

Rick Grashel
Hi Remi,

IMHO, the Github front page needs to better explain what's going on and what is expected from a dev standpoint.  I'll see if I can put something up there to call things out.  Especially if people aren't familiar with or confused by Github projects or Github.

The branching and commit model is Github-flow.  (https://guides.github.com/introduction/flow/).  Basically, a single master that has to be buildable and deployable at all times.  This represents the next release.  Developers create their own branches for things they want to work on.  If a developer has something they want to contribute back, they can create a pull request for whatever they are working on and then it can be discussed.  Ultimately, pull requests are merged into master once they are deemed ready.  When we release a version, we create a release branch from master, update the Jenkins builds, and publish to the Maven repos. It's pretty lightweight (I think far more so than Git-blow) and simple to use and maintain.  It also integrates extremely well with Maven automation when it comes to branching and releasing.  There is also good cross-platform and command-tooling that supports Github-flow.  

I'll try to get something more descriptive on the project page this week, but I can't see us changing this right now.  If we had a ton of traffic and movement and it was warranted, Git-flow would probably be something we could look at.

-- Rick


On Sun, Aug 2, 2015 at 4:32 AM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi folks,

Just had a peek at the repo, and didn't really understand the branches in there. 

Is master supposed to be the "trunk" (or "develop") ? 
The "version" branches are release branches ?
...

I suggest we follow the Git Flow conventions :

It's a branching model that IMHO works fine in small-medium projects. It is commonly used and therefore easy to understand, by convention. 

The idea is to have a "develop" branch (LATEST-SNAPSHOT) to be used for "day to day" development (and feature branches if you want), and a "master" branch for releases (and release branches).

You can install the Git Flow command line tooling for easy management of all this. It's really a useful layer over git IMO.

What do you think ?

Cheers

Remi

PS : I'm taking 1.6.0 out for a spin, trying to see if I can upgrade in Woko... I use loads of extensions so I guess it's a good test. Will let you know. 

------------------------------------------------------------------------------

_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development



------------------------------------------------------------------------------

_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development
Reply | Threaded
Open this post in threaded view
|

Re: git repo organization

VANKEISBELCK Remi
Allright, I'm ok with "Github-flow" : master is trunk/develop, ie the "current" state.
(Btw, "Github flow", "Git Blow", "Git Flow"... wtf ??? come on !!!)

Btw, instead of having the version 1.7.0-SNAPSHOT, it's usually better to have a "latest" version on that branch. I mean, you don't really know if next version will be 1.7.0-SNAPSHOT : it's just the "next release". So instead of 1.7.0-SNAPSHOT, I would use LATEST-SNAPSHOT on master. 

Then when creating the release branch, we set the appropriate version. 

Now for bugs. Let's say a bug arrives on 1.6.0. I guess we fix them on the release branch and try to merge this on master ?

Cheers

Rémi

2015-08-02 15:45 GMT+02:00 Rick Grashel <[hidden email]>:
Hi Remi,

IMHO, the Github front page needs to better explain what's going on and what is expected from a dev standpoint.  I'll see if I can put something up there to call things out.  Especially if people aren't familiar with or confused by Github projects or Github.

The branching and commit model is Github-flow.  (https://guides.github.com/introduction/flow/).  Basically, a single master that has to be buildable and deployable at all times.  This represents the next release.  Developers create their own branches for things they want to work on.  If a developer has something they want to contribute back, they can create a pull request for whatever they are working on and then it can be discussed.  Ultimately, pull requests are merged into master once they are deemed ready.  When we release a version, we create a release branch from master, update the Jenkins builds, and publish to the Maven repos. It's pretty lightweight (I think far more so than Git-blow) and simple to use and maintain.  It also integrates extremely well with Maven automation when it comes to branching and releasing.  There is also good cross-platform and command-tooling that supports Github-flow.  

I'll try to get something more descriptive on the project page this week, but I can't see us changing this right now.  If we had a ton of traffic and movement and it was warranted, Git-flow would probably be something we could look at.

-- Rick


On Sun, Aug 2, 2015 at 4:32 AM, VANKEISBELCK Remi <[hidden email]> wrote:
Hi folks,

Just had a peek at the repo, and didn't really understand the branches in there. 

Is master supposed to be the "trunk" (or "develop") ? 
The "version" branches are release branches ?
...

I suggest we follow the Git Flow conventions :

It's a branching model that IMHO works fine in small-medium projects. It is commonly used and therefore easy to understand, by convention. 

The idea is to have a "develop" branch (LATEST-SNAPSHOT) to be used for "day to day" development (and feature branches if you want), and a "master" branch for releases (and release branches).

You can install the Git Flow command line tooling for easy management of all this. It's really a useful layer over git IMO.

What do you think ?

Cheers

Remi

PS : I'm taking 1.6.0 out for a spin, trying to see if I can upgrade in Woko... I use loads of extensions so I guess it's a good test. Will let you know. 

------------------------------------------------------------------------------

_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development




------------------------------------------------------------------------------

_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development