Pull Requests Workflow » History » Revision 5
Revision 4 (Miguel Gonzalez, 08/11/2025 02:43 AM) → Revision 5/13 (Miguel Gonzalez, 08/11/2025 02:57 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```) Checkout local Development 1. Pull from remote Development 1. Checkout task_branch 1. Rebase/merge from development 1. Resolve conflicts #### Pushing code * Push whenever there is a distinct and stable change (not the entire task; just a specific, small, concise, and related chunk of changes) 1. ```commitAndPush``` Commit 1. Push 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 ## 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 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.