Project

General

Profile

Pull Requests Workflow » History » Version 5

Miguel Gonzalez, 08/11/2025 02:57 AM

1 1 Miguel Gonzalez
# Pull Requests Workflow
2
* Recommended: Github Pull Requests extension for VSCode
3
## Developer Steps
4
### Starting a task
5 4 Miguel Gonzalez
* Create a branch from development named 'task_number' - 'short_description' (or just the description if there is no associated task number)
6 2 Miguel Gonzalez
``` shell
7
git checkout -b new_branch
8
```
9 1 Miguel Gonzalez
10 2 Miguel Gonzalez
11
12 1 Miguel Gonzalez
### Working a task
13
#### Daily and before any commit
14 5 Miguel Gonzalez
1. ```mergeFromDev``` (or ```rebaseFromDev```)
15 1 Miguel Gonzalez
1. Resolve conflicts
16 4 Miguel Gonzalez
17 1 Miguel Gonzalez
#### Pushing code
18 5 Miguel Gonzalez
* Push whenever there is a distinct and stable change (not the entire task; just a specific, concise, and related chunk of changes)
19
1. ```commitAndPush```
20 1 Miguel Gonzalez
1. Create pull request
21
1. Set yourself as owner of the pull request
22
* Be on the lookout for changes requested
23
24
#### Finishing a task
25
* When the task is considered finished and closed, the branch is deleted
26
* Any future fixes to this functionality will be considered a new task with a new branch
27
28
## Reviewer Steps
29
1. Choose an open pull request
30
1. Review changes
31
1. Recommend changes or approve pull request
32
  * Be on the lookout for the owner of the request implementing the changes (repeat steps 2 and 3 after changes are commited)
33
  * When code is acceptable, merge the branch into Development
34
35
## Keep in mind
36
* If using VSCode extension, you might need to manually refresh at some points throughout the process.
37
* 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.
38
39 2 Miguel Gonzalez
## Merge vs Rebase
40
* Merge creates a more convoluted commit and branch history but is safer.
41 5 Miguel Gonzalez
* Rebase makes commit history more linear and easier to read through but can cause issues if done incorrectly.
42
* 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.