Add docs about the git workflow

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index db2be6c58315f5a14eedb92b3a78c43dd1fcea42..d8d94c6ddcff0073f669aa6ed26469d57ffc791c 100644 (file)
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -22,6 +22,13 @@ All new features and bug fixes should be submitted as pull requests, so the comm
 
 When you submit a pull request, @mention a few people you’d like to help you review it. Once those people have signed off on it, the pull request can be merged! Core Team members will handle the merge itself.
 
+## Git Worflow
+
+Foundation uses a git workflow close to [GitFlow](http://nvie.com/posts/a-successful-git-branching-model/). The workflow relies on three branches:
+- **`master`**: The stable branch. It only contains the latest stable version released. Pull requests for docs improvements can be opened on it.
+- **`develop`**: The developing branch used to prepare the next version. It always contains all the new features and bug fixes previously made, and constitutes the more up-to-date version of Foundation. Almost every pull request should be open on this branch. When a new version is released, it is merged on `master`, a support branch is created, and `develop` now target the next version.
+- **`support/*`**: Support branches used to support the previous versions (i.e. `support/6.3` for `v6.3.0`) and prepare patches (i.e. `v6.3.1`). When a bug fix is compatible with supported versions, it is also merged on their support branches and patch versions can be released. If a fix is not compatible with `develop`, a pull request can be opened on the latest compatible and supported version.
+
 ## Coding Standards
 
 If you aren't sure how a feature should be implemented, we recommend checking out our [standards document](https://github.com/zurb/foundation-standards), which outlines every aspect of writing framework features, from Sass to JavaScript.