This repository has been archived by the owner on Oct 1, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 54
HOWTO: Fixing a bug
Z edited this page Aug 14, 2014
·
1 revision
This article describes standard Snow Crash issue fixing procedure. Assuming the issue fix should go into master
(default), in the rare case some other branch should be used, substitute master
mentions with the appropriate branch.
- Reproduce the bug using the
snowcrash
CLI tool - If the bug does not have an GitHub issue create a new one
- Pull the latest
master
fromupstream
- Create bug fixing branch with the name
<your github user name>/<issue name>
– the<issue name>
can be some reasonable abbreviated version of the issue name - In the new branch, create a unit test reproducing the issue (the test must be failing)
- Fix the issue (therefore the unit test)
- Verify all the unit tests and integration tests are passing
- Commit the fix, use descriptive commit message including any additional comment, use a keyword in the commit message to close the respective issue – the issue will be closed automatically once the commit is merged.
- Push into origin, verify all CI tests are passing,
- If needed, rebase the fix branch on top of the actual original branch
- Create a pull request, be as much descriptive as possible
- Take a break, code review may take some time and not happen immediately
In the case a change to a PR code is needed:
- Perform the change
- Commit with some reasonable message & push to origin
- Do not rebase (squash) the commit immediately as it will be easier to do the review
- Once the PR code review is OK, it is generally a good idea to squash all the review fix commits into the original issue-fixing commit
- Follow Snow Crash Coding Standards
- The tests blueprint snippets should be valid blueprints, unless you are performing an invalid blueprint test