Pull Requests Workflow¶

• Recommended: Github Pull Requests extension for VSCode

Developer Steps¶

Starting a task¶

• Create a branch from development named 'task_number' - 'short_description' (or just the description if there is no associated task number)

git checkout -b new_branch

Working a task¶

Daily and before any commit¶

1. mergeFromDev (or rebaseFromDev)
2. Resolve conflicts

Pushing code¶

• Push whenever there is a distinct and stable change (not the entire task; just a specific, concise, and related chunk of changes)

1. commitAndPush
2. Create pull request
3. Set yourself as owner of the pull request

• Be on the lookout for changes requested

Finishing a task¶

• When the task is considered finished and closed, the branch is deleted
• Any future fixes to this functionality will be considered a new task with a new branch

Pull Request Best Practices¶

• Write a clear, concise, and descriptive title
• Link to issue # in description
• Reproduction steps if applicable

Reviewer Steps¶

1. Choose an open pull request
2. Review changes
3. Recommend changes or approve pull request

• Be on the lookout for the owner of the request implementing the changes (repeat steps 2 and 3 after changes are commited)
• When code is acceptable, merge the branch into Development

Keep in mind¶

• If using VSCode extension, you might need to manually refresh at some points throughout the process.
• Once you've created a pull request, you can push commits from your task branch to add them to your existing pull request. These commits will appear in chronological order within your pull request and the changes will be visible in the "Files changed" tab.

Merge vs Rebase¶

• Merge creates a more convoluted commit and branch history but is safer.
• Rebase makes commit history more linear and easier to read through but can cause issues if done incorrectly.
• Rebase can make solving conflicts more complicated. If there are multiple commits before rebasing, will need to resolve merge conflicts for each one. Can be mitigating by always rebasing before committing.