Project

General

Profile

Pull Requests Workflow » History » Version 13

Miguel Gonzalez, 08/11/2025 08:48 PM

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