Pull Requests Workflow » History » Revision 7
Revision 6 (Miguel Gonzalez, 08/11/2025 03:26 AM) → Revision 7/13 (Miguel Gonzalez, 08/11/2025 11:56 AM)
# 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) ``` shell git checkout -b new_branch ``` ### Working a task #### Daily and before any commit 1. ```mergeFromDev``` (or ```rebaseFromDev```) * git checkout Development * git pull * git checkout task_branch * git merge Development 2. 1. 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``` 1. Create pull request 1. 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 1. Review changes 1. 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 committed) 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.