From 014eb55fafee1cba19d836e8f41fb4ff49b80eb4 Mon Sep 17 00:00:00 2001 From: Lars Johan Folde Date: Tue, 6 Oct 2026 15:37:44 +0200 Subject: [PATCH 1/2] docs: add gitub pull request template --- .github/pull_request_template.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 .github/pull_request_template.md diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 0000000..657fa22 --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,9 @@ +### Description + + + +--- + +### Issue + +Closes: # From f9424ad1891e7c862550e3069acd3ee94440283e Mon Sep 17 00:00:00 2001 From: Lars Johan Folde Date: Wed, 7 Oct 2026 11:49:06 +0200 Subject: [PATCH 2/2] docs: document our git workflow --- docs/git-workflow.md | 63 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 docs/git-workflow.md diff --git a/docs/git-workflow.md b/docs/git-workflow.md new file mode 100644 index 0000000..c5f3755 --- /dev/null +++ b/docs/git-workflow.md @@ -0,0 +1,63 @@ +# Git Workflow + +This document outlines how we use Git, and general guidelines for how we ensure +we work effectively towards our larger goals. + +## Branches + +### Branch names + +We tie our branches to the `github issue` we are working on. This can be done +either from the issue page by clicking `Create a branch` from the right hand +menu, or by manually naming it using this convention: + +```git checkout -b -``` + +We always use issues, so if you are working on anything, make sure you have set +up an issue first. This is a part of our documentation strategy. + +### Branch lifetimes + +Branches shouls only live as long as A) the issue remains open, or B) as long as +the issue is being actively worked on. When a pull request is merged into main +the branch must be deleted. Inactive branches should be cleaned up as we go. + +--- + +## Pull Requests + +### Pull requests into main + +All merges into main must be done using `pull requests`. Before a pull request +can be merged it must be approved my a member of IT2810-H26-T24. The pull +request author cannot review their own code. + +If a pull request has been approved, and a new change was made before it got +merged, a new approval is needed. The approved code is what gets merged. + +Pull requests on issues that have two assignees should by default be approved by +the other assignee. + +### Merge strategy + +We `Merge and Rebase` pull requests into main. This keeps all commits from all +stages of the workflow, which makes debugging easier in case anything goes wrong +or if questions are raised. + +--- + +## Issues + +### Issues and sub-issues + +During our Monday meetings we set up a milestone for our next submission. We +then create a few issues with their own sub-issues to track our development and +progress. + +### Two assignee system + +The issues that either relate directly to the next submission, or issues that +are larger in scope should have two group members assigned. The rationale for +this decision is to ensure you always have a member to bounce ideas from, and to +have someone who has spent some time learning about the topic you both are +working on to review your code.