Collaborating: git development workflow

Who is a collaborator?

Collaborators are those who have been granted write access to the main repository of a project, in this case CoolProp/CoolProp. This repository will be referred to as upstream in this document.

You might want want to know how a collaborator is different from a contributor. The Collaborator Workflow is used primarily for the following:

• Merging contributor branches into upstream/master and/or upstream/release branches.
• Creating upstream/development branches.
• Tagging released versions within master and release branches.

If you are not a CoolProp Collaborator, you will want to use the Contributor workflow.

Branching Model

Merging topic branches

• Topic branches must merge into the master branch.
• Merging a topic branch puts it into the next release, that is the next release created from master and/or the next patch release created from a specific release branch.

Steps

Add remote repo for contributor/collaborator, if necessary (only needs to be done once per collaborator):

$ git remote add _bobuser_ https://github.com/_bobuser_/CoolProp.git

Fetch remote:

$ git fetch _bobuser_ topic-13

Select the new branch for code review and testing

$ git checkout topic-13

Provide any review comments on the pull request on Github and test any updates provided by the contributor.

Once satisfied with the branch, merge the topic branch into master on Github. A Squash & Merge will generally keep a cleaner history as it squashes all commits in a pull request to a single merge commit in the main project's history. Unless there is a clear reason to keep multiple commits separate for documentation purposes, a Squash & Merge is recommended.

Release branches

Releases are coordinated among the core development team and come in three flavors:

• Major
• Minor
• Patch

The release process involves creating an official Github Release (including tags, change summaries, etc.) as well as tagging a new release version on the binary repository on SourceForge. This process is documented in the Release Checklist

Tagging a Release

Releases are tagged with a version according to the standard convention of Major.Minor.Patch. Depending on the release change log, the release will be tagged appropriately with all qualifiers (alpha, dev, ...) from the version number.

Any Other Branches Worth Mentioning

coverity_scan: New merges are automatically added to the coverity_scan branch so that code changes can be tested automatically against a number of standard compilers. This should be an automatic processes at this point.