More details on atomic commits ([https://www.freshconsulting.com/atomic-commits/](`https://www.freshconsulting.com/atomic-commits/) )
*More details on ReleaseFlow *([https://devblogs.microsoft.com/devops/release-flow-how-we-do-branching-on-the-vsts-team/](https://devblogs.microsoft.com/devops/release-flow-how-we-do-branching-on-the-vsts-team/) & [https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/release-flow](`https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/release-flow) )
Branching and merging is used when working with any code base within Workflow Doctor to allow for changes to be made to applications without affecting the current live version.
Release Flow
WFD follow a style of branching and merging named Release Flow, popularized by Microsoft. The broad concept of Release Flow is to keep one singular long term 'master' branch. Any features/hotfixes are created in short term topic branches from the master branch, and merged back in via a pull request once complete.
The general development flow follows
1. Branch
The first step when developing is to create a new branch, the branch should be prefixed with **hotfix **or **feature **based on what the development work is. These short lived topic branches are used whenever we want to update any code.
2. Push
Once ready to ship changes to the rest of the team the local branch is pushed back to the server.
3. Pull Request
Azure Dev Ops pull requests are used to control how branches are merged into master. Pull request ensure all branch policies are met (including a validation build).
4. Merge
Once all build policies are satisfied the code is merged into master.
Development Releases
When ready to release a version of the source code, a deployment branch is created from master. This is normally named `release/. Once a release branch has been created no new features should be included in that branch.
The release branch should only be updated with any hot fixes found during pre-release, and updates to documentation etc.
A release branch stays active, until there are no more clients running on that version of the code. Once all clients are no longer using the code, the branch can be deleted.
Releasing Hot fixes
Obviously, some changes need to go into production more quickly than others and waiting for a development cycle may not be feasible. In that case, 'cherry picking' is used.
The hot fix would be developed as normal from a new branch against master and then merged using a pull request.
After the pull request has been validated and merged into master, it can be cherry picked into the relevant release branches.
Cherry picking creates a new branch and pull request against the target branch, this can then be validated and merged as normal.
Feature Flags
Due to the nature of keeping one single master branch that all new development work is added to, feature flags become important to hide pieces of functionality that may not be fully ready for production.
In .NET Core, there is a Microsoft produced FeatureManagement tutorial that be followed here ([https://docs.microsoft.com/en-us/azure/azure-app-configuration/use-feature-flags-dotnet-core](https://docs.microsoft.com/en-us/azure/azure-app-configuration/use-feature-flags-dotnet-core))