Git Branch Management using Git Flow
Interactive Design uses a simplified version of Git Flow. The diagram above provides a picture of the development workflow.
| Branches | ||
| Purpose | Naming convention | |
|---|---|---|
| Main | Mirrors production (live sites) |
main, master on older themes |
| Develop | Contains all in-progress work | develop |
| Feature | Where new development work happens | feature/feature-name |
| Hotfix | Fixes that need to go to live during development | hotfix/hotfix-name |
| Release Tags | ||
| Purpose | Naming convention | |
| Dev Release | Shows changes on www-staging or id-presents
|
dev-1.0.0, where 1.0.0 is your version number in package.json
|
| Prod Release | Shows planned changes on live |
1.0.0, where 1.0.0 is your version number in package.json (no prefix) |
| Hotfix Release | Shows emergency changes on live |
hf-1.0.0, where 1.0.0 is your version number in package.json
|
- Make sure Git Flow is set up in Tower.
- Start your feature branch.
- When you are ready for code review, push changes and open a pull request on GitHub.
- Use a draft pull request if you want to share code before it is ready to be code reviewed.
- After your code review is approved:
- Pull and merge any changes from develop into your branch.
- Update the version in
package.json - Run
grunt version - Run
grunt build - Update the CHANGELOG.md with a brief summary of your changes. Use the same version as in package.json in this format:
[1.0.0]
- Commit and push your changes, then merge your pull request once all checks pass. This will cause GitHub Actions to create a release for you.
- Go to the releases page, and find your release tag number. Request a deploy from this tag.
| Step | Screenshot | ||
|---|---|---|---|
| Before you start working on a repository, set up Git Flow in Tower. |
|
||
| Select "Start Feature" from the Git Flow button. |  |
||
| Once the feature is ready for review, create a Pull Request. You can also open a draft pull request at any time. |  |
||
After your code review, bump the version just before merging.
|
Screenshot in progress | ||
| Github Actions will kick in and check for a version bump and an entry in the changelog. |  |
||
After the PR has been approved, another Github action will create a dev- prefixed tag based on the updated version number. |
 |
| Step | Screenshot |
|---|---|
Update CHANGELOG.md, bumping up the version number to the next minor version number. |
For Example, if the previous feature version is 0.1.4, this version number will be 0.2.0. |
Update package.json with the same version number. Run grunt version && grunt build. Commit and push the changes to develop. |
NOTE: This is the only time that a commit should be directly applied to the develop branch. |
Create a Pull request from develop to main
|
 |
Once the pull request has been approved, to to the Code tab, and click on Releases on the right sidebar. Click on Draft new release
|
 |
| Follow the steps. |
 Larger View
|
Bounce over to slack and click on the + button. Select Request a deploy
|
 |
| Fill out the form, click submit, and someone from the Dev team will deploy. Use the tag you created in the release. |  |