... | ... | @@ -5,16 +5,25 @@ |
|
|
* Push your branch at least once a day so everyone knows what you're working on -- that will help us to avoid conflicts
|
|
|
* When your branch is ready to merge:
|
|
|
* Make sure **all** tests are passing
|
|
|
* Rebase your branch if necessary to fix any merge conflicts, e.g. `git pull origin master --rebase`
|
|
|
* Rebase your branch if necessary to fix any merge conflicts, e.g. `git rebase -i master`
|
|
|
* Use `git push -f` to overwrite the remote branch after rebasing
|
|
|
* [Open a merge request](https://code.briarproject.org/akwizgran/briar/merge_requests/new)
|
|
|
|
|
|
# Code review
|
|
|
|
|
|
* 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
|
|
|
* You should address all the reviewer's comments before merging
|
|
|
* If a comment is better dealt with as a separate ticket after merging, create a ticket and reply with the ticket number
|
|
|
* Let the reviewer know when all the comments have been addressed
|
|
|
* Once your branch has been merged you can delete the remote branch
|
|
|
* When reviewing a branch:
|
|
|
* Check out and run the code as well as reading it
|
|
|
* Make sure you understand what the code is doing and why
|
|
|
* Don't be afraid to ask questions
|
|
|
|
|
|
# Tests
|
|
|
|
|
|
* Before merging a branch, make sure the tests still pass
|
|
|
* Before opening a merge request, make sure the tests still pass
|
|
|
* To run the tests in Android Studio:
|
|
|
* Select 'Run > Edit Configurations' from the menu
|
|
|
* Click '+' and select 'JUnit'
|
... | ... | @@ -33,12 +42,13 @@ |
|
|
* When your branch is merged, label the ticket 'fixed' and close it, or include 'Closes #55' in your commit message to close the ticket automatically (you still need to update the label)
|
|
|
* As a rule of thumb, if a ticket takes longer than a day, break it into smaller tickets (mention the parent in the description)
|
|
|
|
|
|
* Every ticket should be labelled 'bug', 'feature', 'feature request', 'task' or 'document'
|
|
|
* Every ticket should be labelled 'bug', 'feature', 'feature request', 'task', 'document' or 'ux design'
|
|
|
* Bugs are mistakes that affect the user, e.g. potential crashes
|
|
|
* 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 either way they're worth documenting
|
|
|
* Tasks are work items that don't directly affect the user, e.g. refactoring or research
|
|
|
* Documents are work items that produce text rather than software
|
|
|
* Document tasks produce text rather than code
|
|
|
* UX design tasks produce designs rather than code
|
|
|
|
|
|
# Meetings
|
|
|
|
... | ... | @@ -54,4 +64,5 @@ |
|
|
* If you have a task that depends on an earlier task that's awaiting code review, base your new branch on the branch that's awaiting review
|
|
|
* When the first branch is merged, rebase the second branch onto master
|
|
|
* You can put the second branch up for review by selecting the first branch as the target, instead of master
|
|
|
* Add a note about the dependency to the merge request and change the target branch when the first branch is merged |
|
|
* Mention the dependency in the second merge request
|
|
|
* Remember to update the target branch when the first branch is merged |