Pull Requests Workflow » History » Version 9
Miguel Gonzalez, 08/11/2025 06:11 PM
| 1 | 1 | Miguel Gonzalez | # Pull Requests Workflow |
|---|---|---|---|
| 2 | * Recommended: Github Pull Requests extension for VSCode |
||
| 3 | 8 | Miguel Gonzalez | * To open .zprofile mentioned in the following steps run ```edit``` in terminal |
| 4 | 1 | Miguel Gonzalez | ## Developer Steps |
| 5 | ### Starting a task |
||
| 6 | 8 | Miguel Gonzalez | * Add the following function to .zprofile: |
| 7 | 1 | Miguel Gonzalez | ``` |
| 8 | 8 | Miguel Gonzalez | function newBranch(){ |
| 9 | git checkout Development |
||
| 10 | git pull |
||
| 11 | git checkout -b $1 |
||
| 12 | } |
||
| 13 | ``` |
||
| 14 | 9 | Miguel Gonzalez | * Run ```newBranch tracker-###-short_description``` |
| 15 | 1 | Miguel Gonzalez | ### Working a task |
| 16 | #### Daily and before any commit |
||
| 17 | 8 | Miguel Gonzalez | 1. Run ```mergeFrom``` |
| 18 | 1. Resolve conflicts (communicating with the relevant developers) |
||
| 19 | 1 | Miguel Gonzalez | |
| 20 | 8 | Miguel Gonzalez | * Make sure the mergeFrom function in .zprofile is: |
| 21 | ``` |
||
| 22 | function mergeFrom() { |
||
| 23 | currentBranch=$(git rev-parse --abbrev-ref HEAD) |
||
| 24 | git checkout "${1:-Development}" |
||
| 25 | git pull |
||
| 26 | git checkout "${2:-$currentBranch}" |
||
| 27 | git merge "${1:-Development}" |
||
| 28 | } |
||
| 29 | ``` |
||
| 30 | 1 | Miguel Gonzalez | #### Pushing code |
| 31 | 8 | Miguel Gonzalez | * ```commitAndPush``` whenever there is a distinct and stable (tested) change (not the entire task; just a specific, concise, and related chunk of changes) |
| 32 | * If first commit of task create a Draft Pull Request |
||
| 33 | 1. Create Pull Request. |
||
| 34 | 1. Set redmine title as title of pull request (if unavailable, set a short description). |
||
| 35 | 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. |
||
| 36 | 1. The button with the word create has a dropdown arrow, click it and choose draft pull request. |
||
| 37 | 1. Set yourself as asignee of the pull request. |
||
| 38 | * If a pull request is already open, push normally and the changes will be automatically added to the open pull request. |
||
| 39 | * Be on the lookout for changes requested. |
||
| 40 | 1 | Miguel Gonzalez | |
| 41 | #### Finishing a task |
||
| 42 | 8 | Miguel Gonzalez | 1. Set draft pull request to ready for review |
| 43 | 2. Stay on the lookout for any changes requested. |
||
| 44 | 3. If the request is deemed acceptable, it will be approved and the reviewer will take the next steps. |
||
| 45 | 1 | Miguel Gonzalez | |
| 46 | 8 | Miguel Gonzalez | #### Multiple developers working in one task |
| 47 | * Both developers will work in the same branch |
||
| 48 | * If you need changes made by the other developers and before any commits run ```git merge```, then resolve conflicts. |
||
| 49 | * Only one pull request per branch, communicate accordingly. |
||
| 50 | 2 | Miguel Gonzalez | |
| 51 | ## Reviewer Steps |
||
| 52 | 5 | Miguel Gonzalez | 1. Choose an open pull request |
| 53 | 1. Review changes |
||
| 54 | 1 | Miguel Gonzalez | 1. Recommend changes or approve pull request |
| 55 | * Be on the lookout for the owner of the request implementing the changes (repeat steps 2 and 3 after changes are committed) |
||
| 56 | 8 | Miguel Gonzalez | * When code is acceptable, merge the task_branch into Development and delete the task_branch |
| 57 | 1 | Miguel Gonzalez | |
| 58 | 8 | Miguel Gonzalez | * 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. |
| 59 | |||
| 60 | 1 | Miguel Gonzalez | ## Keep in mind |
| 61 | * If using VSCode extension, you might need to manually refresh at some points throughout the process. |