OAT

Pull Requests Workflow » History » Revision 9

Revision 8 (Miguel Gonzalez, 08/11/2025 04:00 PM) → Revision 9/13 (Miguel Gonzalez, 08/11/2025 06:11 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 the following function to .zprofile: 
 ``` 
 function newBranch(){ 
   git checkout Development 
   git pull 
   git checkout -b $1 
 } 
 ``` 
 * Run ```newBranch tracker-###-short_description``` task_number-short_description``` 
 ### Working a task 
 #### Daily and before any commit 
 1. Run ```mergeFrom``` 
 1. Resolve conflicts (communicating with the relevant developers) 

 * Make sure the mergeFrom function in .zprofile is: 
 ``` 
 function mergeFrom() { 
     currentBranch=$(git rev-parse --abbrev-ref HEAD) 
     git checkout "${1:-Development}" 
     git pull 
     git checkout "${2:-$currentBranch}" 
     git merge "${1:-Development}" 
 } 
 ``` 
 #### Pushing code 
 * ```commitAndPush``` 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. 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 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. 

 #### Finishing a task 
 1. Set draft pull request to ready for review 
 2. Stay on the lookout for any changes requested. 
 3. If the request is deemed acceptable, it will be approved and the reviewer will take the next steps. 

 #### Multiple developers working in one task 
 * Both developers will work in the same branch 
 * If you need changes made by the other developers and before any commits run ```git merge```, then resolve conflicts. 
 * Only one pull request per branch, communicate accordingly. 

 ## 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 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.