Mgm-seedbury at 15:14, 13 August 2025

2025-08-13T15:14:31Z

← Older revision		Revision as of 15:14, 13 August 2025
Line 1:		Line 1:
	~~= Pull Requests Workflow =~~
	* Recommended: Github Pull Requests extension for VSCode.		* Recommended: Github Pull Requests extension for VSCode.
	* To open .zprofile mentioned in the following steps run ''edit'' in terminal.		* To open .zprofile mentioned in the following steps run ''edit'' in terminal.

Mgm-seedbury: Added Pull Requests Workflow Page

2025-08-13T15:12:07Z

Added Pull Requests Workflow Page

New page

= 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:
<nowiki> function newBranch(){
git checkout Development
git pull
git checkout -b $1
git push --set-upstream origin $1
}</nowiki>
* Run ''newBranch (Bug|Feature)-###-short_description''.

=== Working a task ===
==== Daily and before any commit====
# Run ''mergeFrom''.
# Resolve conflicts (communicating with the relevant developers).

* Make sure the mergeFrom function in .zprofile is:
<nowiki> function mergeFrom() {
currentBranch=$(git rev-parse --abbrev-ref HEAD)
git checkout "${1:-Development}"
git pull
git checkout "${2:-$currentBranch}"
git merge "${1:-Development}"
}</nowiki>
==== 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:
# Create Pull Request.
# Set redmine title as title of pull request (if unavailable, set a short description).
# 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.
# The button with the word create has a dropdown arrow, click it and choose draft pull request.
# 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 ====
# Set draft pull request to ready for review.
# Stay on the lookout for any changes requested.
# 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 ==
# Choose an open pull request.
# Review changes.
# 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.
----

Pull Requests Workflow - Revision history

Mgm-seedbury at 15:14, 13 August 2025

Mgm-seedbury: Added Pull Requests Workflow Page