Git Workflow about wet-boew HOT 4 CLOSED

We considered that workflow but in consultation with representatives from a few well-established projects we decided to do a mix of git-flow and github-flow (http://scottchacon.com/2011/08/31/github-flow.html). The reason being that there is too much overhead with git-flow and a little too much free-wheeling with github-flow.

We ultimately based our workflow off of rails/rails and jquery/jquery as we found them to be both simple and effective models.

from wet-boew.

Thanks Paul I just spent the last little while going over github-flow. It does seem deceptively simple! When you get a chance if you could let me know where you deviate from github-flow I can try to match up the drupal repository as well with that workflow.

from wet-boew.

Like GitHub-flow we have a "master" branch which is the latest. We also have "gh-pages" for working examples (currently just mirroring the code from "master"). Also like GitHub-flow we create a new branch for anything new (new port or new feature) and currently use the feature-* naming convention. We also encourage frequent commits/merges just like with GitHub-flow.

Where we differ is that the repository is read-only for all but the select few on the Release Management Team. Changes can only be made through pull requests and each pull request needs to be reviewed first by the affected sub-project leads and then finally by the Release Management Team. Release Management Team takes care of sending pull requests for review by submitting a comment requesting a review and including @username for each of the affected sub-project leads. Once both the affected leads and the Release Management Team approve, the Release Management Team is then responsible for merging in the changes.

from wet-boew.

Thanks @pjackson28 exactly what I needed! :)

from wet-boew.