Pull Requests Workflow » History » Revision 8
Revision 7 (Miguel Gonzalez, 08/11/2025 11:56 AM) → Revision 8/13 (Miguel Gonzalez, 08/11/2025 04:00 PM)
# Pull Requests Workflow * Recommended: Github Pull Requests extension for VSCode * To open .zprofile mentioned in the following steps run ```edit``` in terminal ## Developer Steps ### Starting a task * Add Create a branch from development named 'task_number' - 'short_description' (or just the following function to .zprofile: description if there is no associated task number) ``` shell function newBranch(){ git checkout Development git pull git checkout -b $1 new_branch } ``` * Run ```newBranch task_number-short_description``` ### Working a task #### Daily and before any commit 1. Run ```mergeFrom``` 1. Resolve conflicts (communicating with the relevant developers) ```mergeFromDev``` (or ```rebaseFromDev```) * Make sure the mergeFrom function in .zprofile is: ``` function mergeFrom() { currentBranch=$(git rev-parse --abbrev-ref HEAD) git checkout "${1:-Development}" Development * git pull * git checkout "${2:-$currentBranch}" task_branch * git merge "${1:-Development}" Development } ``` 2. Resolve conflicts #### Pushing code * ```commitAndPush``` Push whenever there is a distinct and stable (tested) change (not the entire task; just a specific, concise, and related chunk of changes) * If first commit of task create a Draft Pull Request 1. ```commitAndPush``` 1. Create Pull Request. 1. Set redmine title as title of pull request (if unavailable, set a short description). 1. Use the description to explain more in depth the changes done. Remember to keep it updated with any changes as you go, and include reproduction steps if applicable. 1. The button with the word create has a dropdown arrow, click it and choose draft pull request. 1. Set yourself as asignee owner of the pull request. * If a pull request is already open, push normally and the changes will be automatically added to the open pull request. * Be on the lookout for changes requested. requested #### Finishing a task 1. Set draft pull request to ready for review 2. Stay on * When the lookout for any changes requested. 3. If the request task is deemed acceptable, it will be approved considered finished and closed, the reviewer will take the next steps. #### Multiple developers working in one task branch is deleted * Both developers Any future fixes to this functionality will work in the same be considered a new task with a new branch ### Pull Request Best Practices * If you need changes made by the other developers Write a clear, concise, and before any commits run ```git merge```, then resolve conflicts. descriptive title * Only one pull request per branch, communicate accordingly. 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) * When code is acceptable, merge the task_branch branch into Development and delete the task_branch * You can see the commits in a draft pull request and recommend changes midway, only when marked for review by the developer will you be able to actually approve and merge the request. ## 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.