From 89546d14d588251f935c7124bb61ccb0d094f931 Mon Sep 17 00:00:00 2001 From: Nicolas Coden Date: Tue, 17 Jan 2017 20:24:56 +0100 Subject: [PATCH] Add docs about the git workflow --- CONTRIBUTING.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index db2be6c58..d8d94c6dd 100644 --- 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. -- 2.47.2