From 8772d0e61ebc002f80c26dab66b6aacf377d1501 Mon Sep 17 00:00:00 2001 From: akwizgran Date: Fri, 4 Dec 2015 15:33:14 +0000 Subject: [PATCH] akwizgran created page: development workflow --- development-workflow.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 development-workflow.md diff --git a/development-workflow.md b/development-workflow.md new file mode 100644 index 0000000..ce1f2f7 --- /dev/null +++ b/development-workflow.md @@ -0,0 +1,24 @@ +Branches + +* Always work on a branch +* Name your branch after the ticket you're working on, e.g. `55-key-manager-refactoring` +* Push your branch at least once a day so everyone knows what you're working on -- that will help us to spot conflicts early +* When your branch is ready to merge, rebase it onto master + * Howls of outrage: you can't rebase a public branch! + * But nobody else is working on it, so it's actually fine + * You can use `git push -f` to overwrite the remote branch after rebasing +* When your branch is rebased onto master, open a merge request +* At least one other person must review your code before it's merged to master +* Don't push directly to master unless it's an emergency and the change is very simple + +Issues + +* Every ticket should be labelled 'bug', 'task', 'feature', 'feature request' or 'document' +* Bugs are mistakes that affect the user, e.g. potential crashes +* Tasks are work items that don't directly affect the user, e.g. refactoring or research +* Features are work items that directly affect the user +* Feature requests are features that someone has asked for -- we might or might not implement them, but they're worth documenting +* Documents are work items that produce writing rather than software +* When you start working on a ticket, assign it to yourself +* Label your ticket 'in progress' while you're working on it, then 'in code review' while it's being reviewed +* When your branch is merged, label the ticket 'fixed' and close it