Using GitHub

Learning how to interface with Git and track your changes is as important as sharing them!
GitHub's platform lets us set milestones, track issues, create patches, and review code changes. Integrating all of these tools in our workflow will help us be correct and be on time.

License

Before we actually get to writing code, let us remember that our software is publicly visible, and as such, should have an appropriate open source license. Make sure to add a license to all repositories you are working on. For open source projects, we will generally be using the GNU General Public License v3.0 license.

Follow this guide on adding a license to a repository. As a shortcut, you can append /community/license/new?branch=master&template=gpl-3.0 to the repository's GitHub URL and follow the instructions.

Pull Requests

An integral part of the GitHub flow is branching and pull requests, abbreviated PRs. To learn more about the purpose of pull requests on GitHub watch this short video.

We will be using proper branching and pull requests in order to:

• Keep the master branch in a stable state
• Logically group feature developments
• Conduct code reviews and host discussions

Pull requests are petitions to merge changes made in a compare branch into a base branch—usually from a developing branch into master. All commits made in the developing branch before the pull request's approval are incorporated.
Pull requests provide a platform for discussing changes—which will let us conduct code reviews. Please familiarize yourselves with the pull request flow and requesting reviews.

Projects that enforce a stable master branch should only allow squash merging. This allows people to have non stable commits in working branches (AKA work however they prefer) as long as the final commit is stable.