Document our Git workflow

.github/pull_request_template.md

@@ -0,0 +1,9 @@
+### Description
+
+<Provide a description of your changes here>
+
+---
+
+### Issue
+
+Closes: #<issue number>

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 <issue-number>-<issue-name>```
+
+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.