6.1.6.1. Working with OpenFAST on GitHub

The majority of the collaboration and development for OpenFAST takes place on the GitHub repository. There, issues and pull requests are discussed and new versions are released. It is the best mechanism for engaging with the NREL OpenFAST team and other developers throughout the OpenFAST community.

6.1.6.1.1. Issues and work assignment

Issues should be opened with proper documentation and data to fully describe the problem or feature gap. It is here that communication and coordination should happen regarding ongoing work for new development, and developers should make clear any intention to complete a task.

6.1.6.1.2. Pull Requests

When a code modification is ready for review, a pull request should be submitted along with all appropriate documentation and tests. An NREL OpenFAST team member will assign a reviewer and work with the developer to have the code merged into the main repository.

New pull requests should contain the following:

  • A description of the need for modifications

    • If the pull request fixes a bug, the accompanying GitHub issue should be referenced

  • A summary of the work implemented

  • Regression test results

    • If all tests pass, the summary print out should be provided

    • If any tests fail, an explanation of the failing cases and supporting data like plots should be included

  • Updated unit tests, if applicable

  • Updated documentation in applicable sections ready for compilation and deployment to readthedocs.

6.1.6.1.3. Git workflow and interacting with the main repository

OpenFAST development should follow “Git Flow” when interacting with the github repository. Git Flow is a well-defined and widely adopted workflow for using git that outlines safe methods of pushing and pulling commits to a shared repository. Maintaining Git Flow is critical to prevent remote changes from blocking your local development. This workflow is detailed nicely here and the chart below provides a high level perspective.

../../_images/GitFlowFeatureBranches.png

Reference: http://nvie.com/posts/a-successful-git-branching-model

6.1.6.1.4. OpenFAST Specific Git Flow

It is important to consider how your current work will be affected by other developer’s commits and how your commits will affect other developers. On public branches, avoid using git rebase and never force push.

In OpenFAST development, the typical workflow follows this procedure:

  1. Fork the OpenFAST repository on GitHub

  2. Clone your new fork

git clone https://github.com/<youruser>/OpenFAST

  1. Add OpenFAST/OpenFAST as a remote named upstream

# This adds the remote
git remote add upstream https://github.com/OpenFAST/OpenFAST

# This downloads all the info in the remote, but it doesnt change
# the local source code
git fetch --all

  1. Create a feature branch for active development starting from the OpenFAST dev branch and check it out

git branch feature/a_great_feature upstream/dev
git checkout feature/a_great_feature

  1. Add new development on feature/a_great_feature

git add a_file.f90
git commit -m "A message"
git push origin feature/a_great_feature

  1. Update your feature branch with upstream

git pull upstream dev
git push origin feature/a_great_feature

  1. Open a new pull request to merge <youruser>/OpenFAST/feature/a_great_feature into OpenFAST/OpenFAST/dev