7.5.2. Workflow for interacting with the OpenFAST github.com repo

OpenFAST development should follow “Git Flow” when interacting with the github repository. Git Flow is a git workflow outlining 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.

7.5.2.1. Git Flow

The Git Flow process is well defined and adopted throughout the software development community. It 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

7.5.2.2. 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/OpenFAST repository on GitHub
  2. Clone your new fork: git clone https://github.com/youruser/OpenFAST
  3. Add OpenFAST/OpenFAST as a remote: git remote add upstream https://github.com/OpenFAST/OpenFAST
  4. Create a feature branch for active development: git branch feature/a_great_feature or git checkout -b feature/a_great_feature
  5. Add new development on feature/a_great_feature: git add a_file.f90 && git commit -m "A message" && git push
  1. Update your feature branch with OpenFAST/dev: git pull upstream dev && git push
  2. Create a GitHub pull request to merge youruser/OpenFAST/feature/a_great_feature into OpenFAST/OpenFAST/dev

7.5.2.3. Pull Requests

New pull requests should contain

  • A description of the need for modifications
    • If the pull request fixes a bug, the accompanying GitHub issue should be referenced
  • A highlight 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.