CP2K invites the community to contribute to its development! Documentation improvements, bug fixes, performance enhancements, portability issues, new features, new methods … you are encouraged to contribute so that the community as a whole can benefit.

CP2K is a large project, there is no way to study the full code, and start when that is done! Start working on small patches first, that are easy to code, to test and to integrate. Small patches are easier to review and thus will be more quickly merged to the Git master branch. As experience with the code grows, tackling larger projects becomes realistic. Developers that regularly contribute can sign up to the CP2K developer mailing list.

1. Fork the CP2K Repository on GitHub via “Fork” on https://github.com/cp2k/cp2k
   1. You will notice that you will not be able to push directly to the `master` branch of the new https://github.com/cp2k/cp2k repository. This is by intention and we would like to ask you to send changes as Pull Requests instead.
2. On your machine, clone the repository via git clone –recursive https://github.com/cp2k/cp2k.git
3. Move to the downloaded cp2k directory: cd cp2k
4. Start working in a new branch: git checkout -b my-new-feature
5. Make your changes to the code
6. Add new and changed files: git add …
7. Commit the changes: git commit
   1. Please follow the Guidelines rules
8. Do the first push to your fork, give the remote branch the same name as the local one: git push -u origin my-new-feature
9. Do some more work, then repeat point 6. and 7.
10. Push your new changes to the remote repository via git push (note: the '-u origin my-new-feature' does not have to be repeated)
11. To update the 'master' of your fork to the same state as the 'master' of the CP2K repository:
    1. tell your local git repository once about the remote: git remote add upstream https://github.com/cp2k/cp2k.git
    2. make sure you are on the right branch: git checkout master
    3. rebase' your current branch on top of the cp2k/cp2k master: git pull –rebase upstream master
    4. push the changes: git push
12. You can also rebase your feature branch, in this case do the previous point and then:
    1. git checkout my-new-feature
    2. git pull –rebase upstream master, this may generate rebase/merge-conflicts you should resolve now. If you got lost, you can always use git rebase –abort (with Git 1.8 and newer) to revert the attempted rebase

Following these guidelines will avoid common mistakes and make it easier to integrate patches. It usually takes less than one hour:

1. make -j pretty to auto-format the code (variables).
2. make -j ARCH=… VERSION=“sdbg pdbg ssmp” will check if the code compiles in serial (sdbg) / parallel (pdbg) / with omp (ssmp).
3. prepare and add testcases suitable for regtesting the code (i.e. that run quickly through all new code paths)
4. run these testcases by hand. Be sure to use bounds checking, and valgrind to check for undefined variables or memory leaks (see debug page)
5. run the full regression testing suite, be sure the new testcases run correctly, and no other tests are incorrectly affected.
6. pay attention to:
   1. are new files, including tests, visible ? Use 'git add' as needed.
   2. Are only the intended files and code modified ? Use 'git revert' as needed
   3. Does the code contain stray write statements or debug info ?
   4. Is all new code sufficiently documented and explained ?
   5. Are the input keywords clearly described ?
   6. Are proper citations added the bibliography ?
7. if any of the above steps required changes to the code, go back to the first step, otherwise go to the next step.
8. the main process to submit changes is by sending Pull Requests from a fork on GitHub to the CP2K master branch. There is a Continuous Integration system in place to check conventions and running some checks on the PRs.
   1. we use git rebase to keep the Git history linear, meaning that in your final Pull Request there can't be any merge commits