Before you start full development, make sure you have a branch management strategy for delivering your code.  Questions you must address include:

1. 1. How will multiple developers co-develop?
   2. How will multiple versions co-exist in testing and production environments?
   3. How frequently do I anticipate code moving through the lifecycle? (hint: faster is better).
   4. How will features and bugs move to a build flow and how will build flows become release candidates that can deploy to production
   5. How will the source code strategy support canary deployments

Use the ‘master’ branch for in-progress release enhancements.  For an additional layer, you could use the Gitflow model with a 'develop' branch for in-progress release enhancements.  The 'develop' branch contents would then merge into 'master' when ready to create a release candidate with the potential to deploy to production.

For each enhancement/user story, create a feature branch from ‘master’ (or from 'develop' or appropriate release branch if enhancing an already deployed version).  Make the feature branch name meaningful/self-descriptive or include the story number.

Release branch name format = release/vX.Y (i.e. release/v1.0)

For production bug fixes, create a bugfix branch from the appropriate release branch.  If it doesn’t already exist, create the release branch from the appropriate Tag of the deployed version you want to fix.

When you complete, successfully unit test, and commit code enhancements to the feature or bugfix branch, create a pull request for review approval from at least one other team member (2+ is suggested).  When approved by at least one person (preferably though all approvers), merge the changes back to the corresponding master or release branch.  If merging back to a release branch, the developer must evaluate them.  They should determine if the code changes should merge back into master as is, an alternate version of the changes, or not at all, depending on the differing states of the impacted code versions.  Bottom line, make sure any bug fixes are also represented in master so the defect doesn't return in future releases.

When enhancing a release branch, ensure that you increment the patch version higher than the deployed version, either manually or automatically via the deployment process.

It's strongly encouraged to perform frequent bite-sized commits to the local repository (perhaps with each successful round of code & unit testing), with occasional-to-frequent pushes to the remote repository.

POM Version Format = X.Y.Z-SNAPSHOT (X Major, Y Minor, Z Patch)

At the start of a release development cycle (i.e. per sprint, every other sprint, etc.), set the application pom version (or appropriate version file if not Maven) to the appropriate version.  Ensure the major or minor version was incremented since the last production deployment version (unless already working from an existing release branch).  This allows for branching from a tag in the future in order to make production fixes/updates in parallel with an in-progress enhancement release development effort in ‘master’ branch.

Increment major version if major/significant enhancements are planned (i.e. incompatible API changes

Increment minor version if planned enhancements are not significant (i.e. backwards compatible changes)

Increment patch version if performing bug fixes (i.e. backwards compatible bug fixes)

Refer to Semantic Versioning for additional versioning direction.

Create a Tag when building a package for deployment.

Use a meaningful and unique tag name format.  Use values that allow you to trace back to the source and process you used to create the tag.

Tag Name Format = <service>-<POM version>-<uniqueId…> (i.e. inventoryms-1.0.15-12345678)

• How to configure branch in ECO
• Gitflow Workflow
• Comparison of the Gitflow and Github tagging and branching processes