Git Workflow

Branching Policy

DO NOT make changes directly to the main branch.

The main branch should always remain in a deployable, stable state. All development work must be performed in a separate branch and reviewed before being merged.

Standard Workflow (GitHub Desktop)

1. Pull the latest changes

   • Open GitHub Desktop.
   • Ensure you are on the main branch.
   • Select Fetch origin and then Pull origin if updates are available.

2. Create a new branch

   • Select Current Branch -> New Branch.
   • Name the branch according to the work being performed.

   Examples:

   feature_updateCompressorData
   fix_pressureCalculation
   docs_namingConventionUpdate
   

3. Switch to the new branch

   • Verify the new branch is selected before making any changes.

4. Make your changes

   • Edit project files as needed.
   • Save your work.

5. Commit your changes

   • In GitHub Desktop, review the changed files.
   • Enter a short, descriptive commit message.
     • If your commit finishes a task, include in the description Fixes #<Issue Number> or Closes #<Issue Number>
   • DO NOT COMMIT LARGE DATA FILES

   Examples:

   Add compressor efficiency calculations
   Fix pressure ratio equation
   Update naming convention documentation
   

6. Push the branch

   • Select Push origin to upload your branch to GitHub.
   • If you have not finished work, still push to your branch to save your work online. This lets you continue from another computer.

7. Create a Pull Request

   • Only submit a Pull Request (PR) when you are done with work on your branch
   • Select Create Pull Request in GitHub Desktop (or on GitHub).
   • Provide a brief description of the changes.
     • Include in the description the task the PR finishes Fixes #<Issue Number> or Closes #<Issue Number>
   • Request a review so changes can be merged. One reviewer is required to merge to main.

8. Wait for Approval

   • Merge the Pull Request into main only after it has been reviewed and approved by one other member. The approver may merge for you.
   • Resolve any comments that may prevent the merge.

9. Update your local repository

   • After the Pull Request is merged:
     • Switch back to the main branch.
     • Pull the latest changes.
     • Delete the completed feature branch if it is no longer needed.

Updating your branch

• If there are changes to the main branch while you are working on your own branch, you can pull the changes to your branch by clicking Ctrl + Shift + U or by going to Branch -> Update from Main.

Branch Naming Convention

• Use lowercase prefixes followed by a descriptive camelCase name.
• You can name based on the task you are making or any other name you see fit. Potential examples below.

dataStructure
hpc_firstStageRevisions
initialGasturbModel
ansysAnalysisCfd

Commit Message Guidelines

• Keep commit messages short and descriptive.
• Break commits up; don't submit one mega-commit. Check which files go together in a commit and describe the work you did.
• Remember to include the tasks the commit closes with Fixes #<Issue Number> or Closes #<Issue Number>. Also include this on the PR in case you forget to include it in the commit messages.

Good Examples

Add turbine performance report. Fixes #5
Fix compressor efficiency calculation. Closes #10
Update project documentation. Closes #8
Refactor folder organization. Fixes #101

Avoid

Stuff
Update
Changes
Fix
asdf

Important Rules

• Never commit directly to the main branch.
• Always create a new branch before making changes.
• Pull the latest changes before creating a branch.
• Keep Pull Requests focused on a single task whenever possible.
• Write clear commit messages so project history remains easy to understand.
• Delete completed branches after they have been merged.
• Always link the commit or PR to the task with Fixes #<Issue Number> or Closes #<Issue Number>. If you forget, close the task manually when merged.