kotovalexarian-likes-github/rails--rails
1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
Code Releases Activity

Add note about squashing in contributor guide.

Browse source 
We tell people how to do this all the time in the Issues tracker,
so now we can just point them here.
This commit is contained in:
Steve Klabnik + Katrina Owen 2012-11-09 09:23:27 +01:00
parent dd0040d19f
commit c980af66ec
1 changed files with 38 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

38
guides/source/contributing_to_ruby_on_rails.md
View file

@ -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.