Branching and development

We are using a simplified branching structure (not Git Flow) because development typically only involves 1-2 people.

master is always kept in a state that is ready for merging to production and pushing live.

Development

Features and bug fixes are worked on on branches, and submitted via pull requests.

If you have write access to the repo.

Developer creates a branch off of the develop branch.
Naming
- begins with the name of the story in Jira, e.g DOT-1234, following by an underscore, following by short text reasonably indicative of which issue it relates to, in plain english.
- e.g. DOT-1346_safari-timepicker
During dev, push the branch to restarters.dev, and check out to that branch for someone to feature test - we have multiple app instances available to test features concurrently
Regularly (e.g. daily) merge develop in to the feature branch, so the feature branch doesn't diverge too far away
When the feature has been signed off by the tester, a pull request is created against develop from the feature branch
- Code review discussion takes place on the PR.
- Review requested from relevant other dev
When code review complete, merged in to the develop branch

We make any hotfixes directly on the live server:

Make the fix on the live server on the production branch.
Push the changes to master.
Merge master into develop.
Run the smoke test as per below.
Notify whoever needs to know that the hotfix is now live via Slack (as well as Jira).

Moved here.

IN PROGRESS: rename dev2 to develop
Review if we want to do rebasing
- "Utilizing git rebase during the review and merge stages of a feature branch will create enforce a cohesive Git history of feature merges." (https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow)
- "But, if you’re partial to a linear history, it’s possible to rebase the feature onto the tip of master before executing the merge, resulting in a fast-forward merge." (https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow)
DONE: introduce the release branch into the process
DONE: git flow doesn't say anything about how to manage QA of multiple feature branches at once
- We can push to different branches on dev, accessible by different ports.