Skip to content

Latest commit

 

History

History
105 lines (71 loc) · 2.99 KB

CONTRIBUTING.md

File metadata and controls

105 lines (71 loc) · 2.99 KB
Raw

This document describes how to contribute to GTNA.

Overview

  1. Fork on GitHub
  2. Develop on a topic branch a) Deal with upstream changes
  3. Send a Pull Request

GTNA is hosted on Github, a social code hosting service that hosts Git repositories.

You'll need a GitHub account to contribute to GTNA.

  1. Fork on GitHub

In the GitHub UI there's a "Fork" button which will copy the GTNA repository to your account. After forking clone your fork to your dev machine.

By default the remote you clone from is called orign. Let's rename it to something with more context:

git remote rename origin github

Because we'll deal with upstream changes we'll add the upstream repository to our clone:

git remote add upstream https://github.com/BenjaminSchiller/GTNA.git
  1. Develop on a topic branch

It's good practice to do development on a topic branch. This is a branch that contains all commits for one feature. To create a branch run:

git checkout -b new-feature

During development you should push your changes to your GitHub fork so you have an off site backup and others can follow your development.

git push github new-feature

a) Deal with upstream changes

If one of your features takes several days to complete development on the upstream master might continue. It's a good habit to merge in changes from upstream frequently. It's easier to handle merge conflicts in little steps then going through merge hell for 20 commits in one run.

First we'll get the changes from upstream:

git fetch upstream

Now we'll rebase our topic commits onto the new upstream master -- or the branch you branched off.

git rebase upstream/master

This changes your history so a normal git push github new-feature will fail. We'll need to force it.

git push -f github new-feature
  1. Send a Pull Request

After finishing your work you can send a pull request in the GitHub UI.

Commit Messages

Please read http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html about commit messages.

Example Commit Message

Capitalized, short (50 chars or less) summary

More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.

Write your commit message in the present tense: "Fix bug" and not "Fixed bug." This convention matches up with commit messages generated by commands like git merge and git revert.

Further paragraphs come after blank lines.

  • Bullet points are okay, too

  • Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here

  • Use a hanging indent