Workflow for XGC-Devel and XGC-Full-f

In order to keep the repositories for code development clean, normal users have only read privileges on XGC-Devel and XGC-Full-f. Like the XGC-User repository, these repositories also contain only one branch called “master”. Code development is carried out in user forks of XGC-Devel or XGC-Full-f. A fork is a separate repository, that is initially an exact copy of its parent repo. Note that each user can create only one fork of a repository. The fork created by the user will not be listed under the PU organization (PrincetonUniversity/[repo name]) but under the name of the user ([username]/[repo name]). When code modifications prepared in a fork are ready for merging, a pull request has to be created on the GitHub website in order to pull changes from a user fork into the parent repository. A fork can be used by only one developer or by a group of developers. Inside a fork, branches can be used to organize code development.

Code development shall be organized as separate features or projects. Each feature/project has a lead developer in whose personal fork the code development for the feature/project is carried out.

Contents

• Brief description of the workflow
• Use of forks
• Feature branch workflow inside a fork
• Management of Branches
• Exceptions from the Fork/Feature-Branch workflow
• Pull Requests
• Policy for large files
• Automated Testing of Pull Requests
• XGC Coding Guidelines
  • Basics
  • Formatting
  • Function/Subroutine arguments
  • Function/Subroutine
  • Doxygen comments
  • Version control (git)
  • Hardcoding
  • Compatibility
  • Runtime inputs and preprocessor flags
  • Modularity
  • Source file length
  • Testing
  • Pull requests
• Git Cheat-Sheet