docs: use valid branch names for supported versions

See https://stackoverflow.com/a/22630664/4317384

.github/PULL_REQUEST_TEMPLATE.md

@@ -35,7 +35,7 @@
 - [ ] There are no other pull request similar to this one.
 - [ ] The pull request title is descriptive.
 - [ ] The template is fully and correctly filled.
-- [ ] The pull request targets the right branch (`develop` or `develop/v...`).
+- [ ] The pull request targets the right branch (`develop` or `develop-v...`).
 - [ ] My commits are correctly titled and contain all relevant information.
 - [ ] My code follows the code style of this project.
 - [ ] I have updated the documentation accordingly to my changes (if relevant).

CONTRIBUTING.md

@@ -55,31 +55,31 @@ After you made these checks, please follow these advices to create your pull req
 5. **Make sure that everything works and tests pass**.
    You must absolutely check that everything still works after your changes. Please also add tests for features you added or uncovered bugs you fixed. See the [Testing](https://github.com/zurb/foundation-sites#testing) section.
 6. **Create your pull request** ([link](https://github.com/zurb/foundation-sites/compare)).
-   Make sure it targets the right branch: most often `develop`, unless you provide a fix for an older version and it should be `develop/v...`. Take a look at our [Git Workflow](#git-workflow) below.
+   Make sure it targets the right branch: most often `develop`, unless you provide a fix for an older version and it should be `develop-v...`. Take a look at our [Git Workflow](#git-workflow) below.
 
 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 Workflow
 
-Foundation uses a Git workflow close to the the successful [GitFlow](http://nvie.com/posts/a-successful-git-branching-model/) branching model, to which we added `develop/v...` and `master/v...` branches to prepare and release patches for older Foundation versions. Most of the time you will not have to care about this workflow and can simply open your pull request on `develop`.
+Foundation uses a Git workflow close to the the successful [GitFlow](http://nvie.com/posts/a-successful-git-branching-model/) branching model, to which we added `develop-v...` and `master-v...` branches to prepare and release patches for older Foundation versions. Most of the time you will not have to care about this workflow and can simply open your pull request on `develop`.
 
 The workflow relies on three branches:
 
 - **`develop`**
 
-  Used to prepare the next minor/major version. It always contains all the new features and bug fixes, and is the most up-to-date version of Foundation. Almost every pull request should be opened on this branch (fixes, features, documentation...). When a new version is released, it is merged on `master`, a dedicated `develop/v...` branch is created, and `develop` now targets the next version.
+  Used to prepare the next minor/major version. It always contains all the new features and bug fixes, and is the most up-to-date version of Foundation. Almost every pull request should be opened on this branch (fixes, features, documentation...). When a new version is released, it is merged on `master`, a dedicated `develop-v...` branch is created, and `develop` now targets the next version.
 
-- **`develop/<version>`**
+- **`develop-<version>`**
 
-  Used to prepare patches for previous versions. For example: `develop/v6.5` to prepare the `v6.5.1` release. When a pull request for a bug fix is merged on `develop` and is compatible with supported versions, its commits must be added on the compatible `develop/v...` branches too. If a fix is not compatible with `develop`, a pull request can be opened on the latest compatible and supported `develop/v...` branch. When a new patch is released, it is merged on `master/v...` and `develop/v...` now targets the next patch for this minor version.
+  Used to prepare patches for previous versions. For example: `develop-v6.5` to prepare the `v6.5.1` release. When a pull request for a bug fix is merged on `develop` and is compatible with supported versions, its commits must be added on the compatible `develop-v...` branches too. If a fix is not compatible with `develop`, a pull request can be opened on the latest compatible and supported `develop-v...` branch. When a new patch is released, it is merged on `master-v...` and `develop-v...` now targets the next patch for this minor version.
 
 - **`master`**
 
   The stable branch. It only contains the latest stable version released. **Do NOT open pull requests on it**.
 
-- **`master/<version>`**
+- **`master-<version>`**
 
-  The stable branch for previous versions. For example: `master/v6.5` for stable `v6.5.*` releases. **Do NOT open pull requests on it**.
+  The stable branch for previous versions. For example: `master-v6.5` for stable `v6.5.*` releases. **Do NOT open pull requests on it**.
 
 This git workflow was fully adopted as of `v6.5`, so `v6.4` and previous versions are not supported.