akwizgran created page: development workflow

akwizgran
2015-12-04 15:51:57 +00:00
parent 8772d0e61e
commit 05831c01d5

@@ -5,20 +5,21 @@ Branches
* 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
* 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
* Once your branch has been merged you can delete the remote branch
Issues
* Every ticket should be labelled 'bug', 'task', 'feature', 'feature request' or 'document'
* 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
* 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