2 Contributing a patch

If you would like to contribute some code to the project, you can do so by creating a branch of your fork with the code you would like to contribute. If you try to make an edit directly in the project's Github repo, you will see that when trying to save the edit, you will be given the option of saving the edit to your fork's main branch, or of creating a feature branch. If you are planning on making more than one contribution (and you never know, even if you're not planning on it, you could wind up making more than one contribution), it's best to save the edits to a separate branch on your fork, so that your main branch reflects the main branch of the project's repo.

If you have already forked the project before, make sure your fork's main branch is up to date with the project's main branch (in Github there is now a very useful "fetch upstream" option at the top of your fork's codebase) before creating the feature branch (otherwise you will have to "fetch upstream" on the feature branch also).

Even if you created a feature branch on your fork remotely (i.e. through the Github interface), you should still test it locally before making a Pull Request out of it. In your local environment, issue a git pull to make sure everything is up to date, then checkout your feature branch (for example, if you called the feature branch 'patch-1', you would issue git checkout patch-1).

Now you can run the app again to test your feature: bundle exec rails server, and once the server is running, open your browser at http://127.0.0.1:3000.

Creating a patch

Directly on the source repo on Github

If you only need to create a simple patch with a small fix, you can do so by editing any file directly from Github, on the project's source repository. When you try to save the changes, you will not be able to commit them directly to the source repo, but you will be given the option of committing the changes to a new branch on your fork. This is a simple and fast way of creating a patch on your fork, against which you can create a PR.

On your local fork

You can easily create a patch branch from your local fork.

If you are intending on creating a patch that is a bugfix, if for example it fixes a bug for which there is an issue, we suggest you create a branch that starts with fix/, this will allow the PR that will be made from your branch to be tagged automatically as bugfix.

Similarly, if you're intending on creating a patch that adds a feature, for example if it implements an enhancement that was requested in an issue, we suggest you create a branch that starts with feature/, this will allow the PR that will be made from your branch to be tagged automatically as enhancement.

To create your local branch, first make sure your local repo is up to date. Easiest way to do this now is:

1. From the github page for your fork, click on Fetch upstream -> Fetch and merge.
2. From the command line, make sure you are on the main branch git checkout main, and issue a git pull.

Now you can create the new branch, which will branched from main:

$ git checkout -b fix/issue-51

This will create the branch and check it out. You are now working inside the fix/issue-51 branch (or whatever you have called it).

Make your changes, and make only the changes that are required for the exact fix or feature in the issue you are addressing. Once you have made your changes, add the files to be committed:

1. You can see a list of the files that have been changed by issuing git status
2. You can add only the changed files which you wish to be committed for this PR one at a time with git add path/to/changed/file/for/PR
3. Add a short but significant commit message that explains what your changes are doing: git commit -m "move styles to webpack/javascript/stylesheets"
4. Push your committed changes to your remote fork: git push -u origin fix/issue-51
5. If you navigate the main project github repo, you should see a message about recent pushes to a branch on your fork, asking if you want to start a Pull Request from this branch. Click on Start a Pull Request.
6. You can give the Pull Request a title (probably not much different from the commit message for your changes), and you can add some further explanation in the body. If you add the phrase "fixes #51", then issue 51 will be linked to this PR, and if the PR is merged then the issue will be automatically closed.

Creating unit tests

When using the scaffolding generator, basic unit tests for the routes and views are created automatically.

«            GO BACK TO THE PREVIOUS SECTION	CONTINUE TO THE NEXT SECTION           »
1 Setting up the development environment	3 Handling i18n