Brief description of the workflow

• Starting point: You want to start a new project or work on a project that is led by another developer.

• Either start the project in your own fork if you are the lead developer of the project, ask for write access to the lead developer’s fork, or follow the same workflow as you would with XGC-Devel but using the lead developer’s fork as the parent repo. (This requires adding that developer’s fork as a remote source to the working copy of your fork.

  • “Remotes” are basically just links to a Git repository on a remote server. You can use remotes to synchronize (push/pull) your working copy of a repo with any fork of that repo, e.g., forks owned by other XGC developers. The most important remote is “origin”, which is the remote from which your working copy has been cloned (usually your fork of a repo). The remote name “upstream” is often used for the parent repo of your fork.

• Clone the fork you want to work on if the fork’s owner has given you write privileges, or fetch the lead developers fork information into the working copy of your own fork, and checkout/create the appropriate branch.

  • Adhere to the naming convention [username]/[branch name] so that the owners of branches can easily be identified (especially if you work in someone else’s fork).

• Work on the code and try to commit in small increments.

• When you are ready to merge your new code:

  • Make sure that master in the fork you are working on has been synchronized with master in the parent repo (see Feature branch workflow inside a fork)

  • Update master in your working copy

  • Merge master into your branch and resolve any conflicts

  • Open pull request from your branch to the master branch in the XGC parent repository (or the lead developer’s fork).

• After your pull request in the fork has been merged, delete that branch and (if applicable) synchronize the copy of the branch into which your PR was merged in your own working copy.