Workflow

Setting up the environment (Forking)

The best way to work on the CKAN project is to fork the project and clone it from your own github account. Then you can just clone the files onto your local machine:

> git clone [email protected]:github-user-name/CKAN

It's recommended you add the main CKAN repo as a remote upstream (using HTTPS to prevent accidental pushes):

> git remote add upstream https://github.com/KSP-CKAN/CKAN.git

Keeping up to date (Pulling)

To keep your forked sub-projects up to date is pretty straight forward from here on out. Run the following after switching to your master branch:

> git fetch upstream
> git merge upstream/master
> git push origin master

This will pull the changes from upstream (the CKAN repositories), merge them into your master branch, and push the changes to your github fork.

Working on the code (Branches)

Try to create a branch for each feature/issue you work on. This allows for separate pull requests for each feature/issue.

> git checkout -b 999_fix_thing
Switched to a new branch '999_fix_thing'

> git commit thing.pl -m "I'm fixing a thing - closes #999"
[999_fix_thing 1dacc06] I'm fixing a thing - closes #999
 1 file changed, 1 insertion(+)
 create mode 100644 thing.pl

> git push origin 999_fix_thing
Counting objects: 3, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 305 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To [email protected]:github-user-name/CKAN-project.git
   baad2a2..1dacc06  999_fix_thing -> 999_fix_thing

Pull requests

When making a pull request, please:

• Make sure the pull request title is human friendly without following any links. "CKAN no longer runs slowly on Sundays (#1337)" is better than just "Fixes #1337".
• Make sure you link any relevant issues in the body. For issues in the CKAN repo, you can just use #1337 syntax. For issues in other repos, it's KSP-CKAN/CKAN-meta#1337.
• We love you most when your pull request comes with documentation and tests. We love you most of all when your pull request is documentation and tests on existing code.

When merging a pull request, make sure:

• A human has tested the changes by building and running the client.
• A human has reviewed the code.
• They can be different humans. Hence if you've done one, but not the other, please comment this in the pull request body.

Compiling

From a command-line

Type ./build. You'll get a _build folder created, which will include ckan.exe and netkan.exe if all is successful.

See Building CKAN for more details.