Pull requests should be opened to the
masteris reserved for releases.
Here are the basics of contributing to GitHub:
- Fork and clone the project
- Set up the project locally
- Create an upstream remote and sync your local copy
- Branch each set of work
- Push the work to your own repository
- Create a new pull request
- Look out for any code feedback and respond accordingly
While in the development stage, you can live preview your work using the GitHub Pages Ruby Gem.
- fork Kotlin-SCP repository
- clone your fork:
git clone firstname.lastname@example.org:[YOUR-USERNAME]/Kotlin-SCP.git
- enter your local copy:
- initialize git flow:
$ git flow init
- fetch remote branches:
$ git fetch --all
Simply put, every time you want to work on a new section, or add a sub-section, you should start a “feature”:
$ git flow feature start my-new-section
To keep your work safe, don’t forget to publish your feature often:
$ git flow feature publish
For typos and any other issues that should not wait for the next release to be fixed, you should start a hotfix:
$ git flow hotfix start
Once you’re ready to merge your work with others, you should go to main repository and open a New Pull Request to the
develop branch. Then, someone will review your work, comment, request changes, and/or simply merge it to branch
develop of the project’s main repository. Hotfixes will be merged both to
master branches, making changes immediately available. Features become available on the next release.
Remember to keep
develop branches of your fork up to date with the upstream ones.
You can do it using the GitHub Pages Ruby Gem: “A simple Ruby Gem to bootstrap dependencies for setting up and maintaining a local Jekyll environment in sync with GitHub Pages.”
Provided that Docker is installed, follow the official GitHub Pages Ruby Gem instructions to build the Docker image and run the server.