From 3fd176914297da424a9812557697a25e3bf9d28a Mon Sep 17 00:00:00 2001 From: Ingo Schommer Date: Fri, 21 Dec 2012 14:26:51 +0100 Subject: [PATCH] Added docs about which branch to choose --- docs/en/installation/composer.md | 7 +++--- docs/en/misc/contributing/code.md | 36 ++++++++++++++++++------------- 2 files changed, 25 insertions(+), 18 deletions(-) diff --git a/docs/en/installation/composer.md b/docs/en/installation/composer.md index c738cc8c6..ed2c947de 100644 --- a/docs/en/installation/composer.md +++ b/docs/en/installation/composer.md @@ -212,7 +212,7 @@ Both the version and the alias are specified as Composer versions, not branch na This is not the only way to set things up in Composer. For more information on this topic, read the ["Aliases" chapter of the Composer documentation](http://getcomposer.org/doc/articles/aliases.md). -## Setting up an environment for contributing to SilverStripe +## Setting up an environment for contributing to SilverStripe {#contributing} So you want to contribute to SilverStripe? Fantastic! You can do this with composer too. You have to tell composer three things in order to be able to do this: @@ -231,8 +231,9 @@ The `--keep-vcs` flag will make sure you have access to the git history of the i The `--dev` flag will add a couple modules which are useful for SilverStripe development: - * The `compass` module will regenerate CSS if you update the SCSS files * The `docsviewer` module will let you preview changes to the project documentation * The `buildtools` module which adds [phing](http://phing.info) tasks for creating SilverStripe releases -Note that you can also include those into an existing project by running `composer update --dev`. \ No newline at end of file +Note that you can also include those into an existing project by running `composer update --dev`. +Please read the ["Contributing Code"](/misc/contributing/code) documentation to find out how to +create forks and send pull requests. \ No newline at end of file diff --git a/docs/en/misc/contributing/code.md b/docs/en/misc/contributing/code.md index c78f8514a..677f1e5a4 100644 --- a/docs/en/misc/contributing/code.md +++ b/docs/en/misc/contributing/code.md @@ -16,29 +16,32 @@ We ask for this so that the ownership in the license is clear and unambiguous, a ## Step-by-step: From forking to sending the pull request - 1. Follow the [Installation for contributions](../../installation/from-source#option-2-installation-for-contributions) instructions, which explain how to fork the core modules and add the correct "upstream" remote. +1. Follow the [Installation through Composer](../../installation/composer#contributing) instructions, +which explain how to fork the core modules and add the correct "upstream" remote. In short: - 1. [Branch for new issue and develop on issue branch](code#branch-for-new-issue-and-develop-on-issue-branch) + composer create-project --keep-vcs --dev silverstripe/installer ./my/website/folder 3.0.x-dev - $ git branch ###-description - $ git checkout ###-description +2. [Branch for new issue and develop on issue branch](code#branch-for-new-issue-and-develop-on-issue-branch) - 1. As time passes, the upstream repository accumulates new commits. Keep your working copy's master branch and issue branch up to date by periodically [rebasing your development branch on the latest upstream](code#rebase-your-development-branch-on-the-latest-upstream). + git branch ###-description + git checkout ###-description - # [make sure all your changes are committed as necessary in branch] - $ git fetch upstream - $ git rebase upstream/master +3. As time passes, the upstream repository accumulates new commits. Keep your working copy's master branch and issue branch up to date by periodically [rebasing your development branch on the latest upstream](code#rebase-your-development-branch-on-the-latest-upstream). - 1. When development is complete, [squash all commit related to a single issue into a single commit](code#squash-all-commits-related-to-a-single-issue-into-a-single-commit). + # [make sure all your changes are committed as necessary in branch] + git fetch upstream + git rebase upstream/master - $ git fetch upstream - $ git rebase -i upstream/master +4. When development is complete, [squash all commit related to a single issue into a single commit](code#squash-all-commits-related-to-a-single-issue-into-a-single-commit). - 1. Push release candidate branch to GitHub + git fetch upstream + git rebase -i upstream/master - $ git push origin ###-description +5. Push release candidate branch to GitHub - 1. Issue pull request on GitHub. Visit your forked respoistory on GitHub.com and click the "Create Pull Request" button nex tot the new branch. + git push origin ###-description + +6. Issue pull request on GitHub. Visit your forked respoistory on GitHub.com and click the "Create Pull Request" button nex tot the new branch. The core team is then responsible for reviewing patches and deciding if they will make it into core. If there are any problems they will follow up with you, so please ensure they have a way to contact you! @@ -61,7 +64,10 @@ If you're familiar with it, here's the short version of what you need to know. O * **Squash your commits, so that each commit addresses a single issue.** After you rebase your work on top of the upstream master, you can squash multiple commits into one. Say, for instance, you've got three commits in related to Issue #100. Squash all three into one with the message "Issue #100 Description of the issue here." We won't accept pull requests for multiple commits related to a single issue; it's up to you to squash and clean your commit tree. (Remember, if you squash commits you've already pushed to GitHub, you won't be able to push that same branch again. Create a new local branch, squash, and push the new squashed branch.) - + * **Choose the correct branch**: Assume the current release is 3.0.3, and 3.1.0 is in beta state. + Most pull requests should go against the `3.1.x-dev` *pre-release branch*, only critical bugfixes + against the `3.0.x-dev` *release branch*. If you're changing an API or introducing a major feature, + the pull request should go against `master` (read more about our [release process](/misc/release-process)). ### Editing files directly on GitHub.com