aboutsummaryrefslogtreecommitdiffstats
path: root/guides/source/contributing_to_ruby_on_rails.md
diff options
context:
space:
mode:
authorSteve Klabnik + Katrina Owen <steve+katrina@steveklabnik.com>2012-11-09 09:23:27 +0100
committerSteve Klabnik + Katrina Owen <steve+katrina@steveklabnik.com>2012-11-09 09:51:58 +0100
commitc980af66ece4c6e06c3352b564da7a1530b1fb94 (patch)
tree8a08fcd46f4ad3fe09fe667935b6b5f60cc5be83 /guides/source/contributing_to_ruby_on_rails.md
parentdd0040d19f2b161201fd54e21fc807fb987f016d (diff)
downloadrails-c980af66ece4c6e06c3352b564da7a1530b1fb94.tar.gz
rails-c980af66ece4c6e06c3352b564da7a1530b1fb94.tar.bz2
rails-c980af66ece4c6e06c3352b564da7a1530b1fb94.zip
Add note about squashing in contributor guide.
We tell people how to do this all the time in the Issues tracker, so now we can just point them here.
Diffstat (limited to 'guides/source/contributing_to_ruby_on_rails.md')
-rw-r--r--guides/source/contributing_to_ruby_on_rails.md38
1 files changed, 38 insertions, 0 deletions
diff --git a/guides/source/contributing_to_ruby_on_rails.md b/guides/source/contributing_to_ruby_on_rails.md
index 3791467584..01bc26c4d5 100644
--- a/guides/source/contributing_to_ruby_on_rails.md
+++ b/guides/source/contributing_to_ruby_on_rails.md
@@ -376,6 +376,44 @@ Now you need to get other people to look at your patch, just as you've looked at
It’s entirely possible that the feedback you get will suggest changes. Don’t get discouraged: the whole point of contributing to an active open source project is to tap into community knowledge. If people are encouraging you to tweak your code, then it’s worth making the tweaks and resubmitting. If the feedback is that your code doesn’t belong in the core, you might still think about releasing it as a gem.
+#### Squashing commits
+
+One of the things that we may ask you to do is "squash your commits," which
+will combine all of your commits into a single commit. We prefer pull requests
+that are a single commit. This makes it easier to backport changes to stable
+branches, squashing makes it easier to revert bad commits, and the git history
+can be a bit easier to follow. Rails is a large project, and a bunch of
+extraneous commits can add a lot of noise.
+
+In order to do this, you'll need to have a git remote that points at the main
+Rails repository. This is useful anyway, but just in case you don't have it set
+up, make sure that you do this first:
+
+```bash
+$ git remote add upstream https://github.com/rails/rails.git
+```
+
+You can call this remote whatever you'd like, but if you don't use `upstream`,
+then change the name to your own in the instructions below.
+
+Given that your remote branch is called `my_pull_request`, then you can do the
+following:
+
+```bash
+$ git fetch upstream
+$ git checkout my_pull_request
+$ git rebase upstream/master
+$ git rebase -i
+
+< Choose 'squash' for all of your commits except the first one. >
+< Edit the commit message to make sense, and describe all your changes. >
+
+$ git push origin my_pull_request -f
+```
+
+You should be able to refresh the pull request on GitHub and see that it has
+been updated.
+
### Backporting
Changes that are merged into master are intended for the next major release of Rails. Sometimes, it might be beneficial for your changes to propagate back to the maintenance releases for older stable branches. Generally, security fixes and bug fixes are good candidates for a backport, while new features and patches that introduce a change in behavior will not be accepted. When in doubt, it is best to consult a Rails team member before backporting your changes to avoid wasted effort.