-
Notifications
You must be signed in to change notification settings - Fork 100
WIP: Jira & Git flow, rules and recomendations
Master branch is the bleeding edge branch and should be treated as unstable. However each version tag can be treated as stable.
It's highly recommended you create a feature branch either on ticket or epic level. Feature branches should be located on the biosistemika/scinote-web repository.
It's advisable that you (as a developers) fork your version of scinote-web onto your namespace (e.g. my-awesome-gh-profile/scinote-web), and open development branches on your own repository, while keeping the main branches (master, feature branches) in sync with the branches on biosistemika/scinote-web).
Your development branch should consist of your initials, ticket number and (optional) short description.
For example: mm-sci-1234-implementing-crypto
Feature branches should have a name like this: features/name-of-the-feature.
At least one of the commits should have the ticket number in the title/description (e.g. git commit -m 'Fix SCI-XXXX'). This helps with Jira hooks, and our automated process. At this point we're not squashing the commits, but using normal merge commits.
Pull request should be named the same as ticket title. Ideally, pull request will have a name like this:
My amazing contribution [SCI-XXXX]
The pull request description should include the following:
- link to Jira ticket
- sentence or two about what was done
- some background/reasoning (optional)
- todo (optional)
You should also add a label to your pull request; the label should be the target branch to which the pull Request is being opened against. This helps us when viewing all pull requests to quickly distinguish to which branches they are being requested to be pulled.
- Choose an issue from sprint backlog [Jira]
- Assign it to yourself, move issue to In Progress [Jira]
- Develop
- Commit and push
- Open pull request [GitHub]
- (GitLab only) move your ticket to 'Ready for Merge' column [Jira]
- Wait for code review
- Have a vigorous debate with your reviewer
- If there are requests for changes in your pull request, perform the changes as new commits, re-push to your remote repository.
- Merge when:
- reviewer approved you PR
- all checks pass
- Ticket will be magically moved to 'Ready for Release' column in Jira (actually by GitHub/GitLab webhook, no magic really there)