From c980af66ece4c6e06c3352b564da7a1530b1fb94 Mon Sep 17 00:00:00 2001 From: Steve Klabnik + Katrina Owen Date: Fri, 9 Nov 2012 09:23:27 +0100 Subject: 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. --- guides/source/contributing_to_ruby_on_rails.md | 38 ++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) (limited to 'guides/source/contributing_to_ruby_on_rails.md') 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. -- cgit v1.2.3