-
Notifications
You must be signed in to change notification settings - Fork 9
Git Flow
Working from feature development to release
Note: Issue are tracked in the Nexus Project and not under the nexus-web repo.
Feature development should happen with user impact taken into account first and foremost, with the feature being described into separate issues as User Stories.
A collection of User Stories that all concern a larger goal can be bundled up as all part of a larger Epic issue.
Each Epic should place in its own Epic Branch, in which each User Story can be independently developed and added. When the Epic is complete, the branch can be moved to the pre-release phase by creating a pull request against the master branch, where regressive testing should be performed by the team.
Epic branch naming convention example: feature/820-resource-graph-navigation
branches should only be name-spaced (having a meaningful prefix such as bugfix/ or feature) when they're intended to be merged into master directly. If you're working on incremental additions to a feature branch, for example, simply name your branch 100-my-user-story.
For each branch with an associated issue, no matter what kind of branch it's intended to be, be sure to reference the issue number, followed by a dash, and then a descriptive title in kebab case.
Generally, all branches should have a corresponding issue, except for perhaps hotfixes and bugfixes.
Once you have your feature branch squared away, you might have conflicts or changes in master as other stuff has been merged into master while you were creating a nice feature. In order to resolve this problem
- make a branch off of your feature branch, and make sure it's not labeled with a protected prefix like
feature/such asupdate-feature/my-cool-feature-master - merge
masterinto your new branch - make a PR into your feature branch.
- ask for reviews and merge. 🚨 It's important to not squash and merge! 🚨
- profit!
Bugs or small fixes can be developed in their own branch and merged directly into the master branch after a reviewed pull-request, without the need for making an Epic Branch. The PR should be properly labeled with the issue it attempts to resolve with "fixes #123", for example.
bugfix branch naming convention example: bugfix/fix-list-styles
Describes a discrete the user would like to perform, using User Story keywords like AS A, I WANT, SO I CAN. These tasks should be subdivided so that a single developer could pick up a User Story without being dependant on the progress of another.
Epics are collections of User stories that together form a whole Feature that solves a Specific Problem, one that was likely addressed by getting feedback from users, and synthesising that feedback into a lowest common denominator.
Sagas are collections of Epics that deal with a broad set of features concerning a single topic, such as Data Visualisation. Sagas probably won't play into the daily workflow.
This phase is meant to capture feedback and fix issues that might arise from merging multiple Epic Branches together into the master branch. Here, the master branch is tested regressively, and deployed to a staging environment for feedback. Feedback should be catalogued as issues or applied as seen fit, and all bugs should be squished before moving on to the release phase.
Once we're satisfied that our features are bug-free, have all been merged into the master branch, and collectively empower our users by solving their Specific Problems, we can finally make a release.
Hurray! We've just made a release 🥳