Skip to content

Instantly share code, notes, and snippets.

@roxxydev

roxxydev/gitflow.md

Last active April 7, 2022 23:29
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save roxxydev/ff0db30b31413946eb17cc4e7b6e3ed3 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save roxxydev/ff0db30b31413946eb17cc4e7b6e3ed3 to your computer and use it in GitHub Desktop.
Download ZIP
Gitflow - taking into consideration monorepo
Raw
gitflow.md

Workflow:

  • master becomes now our develop branch (no need to rename)
  • we will have a separate "production" branch
  • we will have a separate "release" branch
  • we will have a separate "hotfix" branch for hotfixes
  • we will maintain and continue to use feature branches

Rule:

  • A. other devs (not working on the app) can continue to create MR for fixes and updates to master(the develop branch)
  • B. hotfixes once passed testing will be merged to production branch. This will have to be merged back to master
  • C. feature branches will only be merged to master if it has been tested fully and approved by devs and QA from different teams
  • D. for changes that is small like minor fixes, improvements that doesn't affect other modules will continue to be a separate branch e.g. fix/CX10-123, update/CX30-125, task/CX11-145. The test build SHOULD be from generated from these branches for QA to test. If it passed then that's the only time it will get merged to "master" (develop branch).
  • E. for the changes made in rule D., before the actual release of the changes, a regression test will have to be performed which we will be needing a separate branch for it and that will now be the "release" branch. If the build from release branch passed the regression testing then that will be the time the "release" branch will be merged to "production" branch.
  • F. if for instances that the QA reported an issue in release branch, it will not be merged to "production" until fix for the issue was created and approved. For addressing the issue reported, the developer will have to create fix for it in the release branch itself.

"Once develop has acquired enough features for a release (or a predetermined release date is approaching), you fork a release branch off of develop. Creating this branch starts the next release cycle, so no new features can be added after this point—only bug fixes, documentation generation, and other release-oriented tasks should go in this branch." - https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

  • H. once reported issue mentioned in rule F. is verified fixed and approved, the release branch can now be merged to master.

Note:

  • Devs can continue working on their own tickets similarly like mentioned in rule D.
  • Naming for release branch should be "release/v1.1.0"
  • "production" branch will contain the git tag similar to the version name specified in release branch
  • hotfixes branch is solely for addressing critical fixes
  • feature branches will have to rebase from master daily. It is still upon the devs on how frequent they want to rebase from master.
  • a final production build will have to be created and it SHOULD be the only one that will get promoted/published to store.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment