Gitflow

Gitflow is a version-control workflow designed to organize development around identifiable releases. Its two long-lived branches are typically main, historically called master, and develop. Main records released code, while develop integrates work intended for a future release. Supporting feature, release, and hotfix branches separate different types of change. These names are conventions rather than capabilities enforced by Git.

A developer starts a feature branch from develop, implements a change, and submits a pull request back to develop. Continuous integration runs compilation, unit tests, security checks, and other required validations. Repository protections can require successful checks and reviewer approval before merging. Teams should keep feature branches reasonably short-lived because isolation does not eliminate integration problems; it postpones discovering them until changes are combined.

When the planned features are ready, the team creates a release branch from develop. This branch accepts stabilization fixes and release metadata changes while develop can continue receiving work for the next version. After validation, the release is merged into main and its fixes are incorporated into develop. The released commit is normally tagged with a version such as v2.4.0. For an urgent production defect, a hotfix branch starts from the released production baseline, usually main, and the fix is incorporated into main and develop. An active release branch may also need that fix.

In the cloud, repository events connect these branch roles to pipeline behavior. For example, feature pull requests might run tests without production credentials, develop updates might deploy to a shared integration environment, and release branch updates might deploy candidates to staging. A protected main update or release tag can initiate a production release process with approval gates. These mappings are implementation choices: Gitflow does not require a dedicated environment for every branch or automatically deploy anything.

A practical AWS implementation can connect a GitHub repository to AWS CodePipeline through AWS CodeConnections, run validation with AWS CodeBuild, and deploy through AWS CodeDeploy to supported targets. Configure source filters and permissions deliberately so that feature changes cannot invoke production deployment roles. Separate AWS accounts for development and production can provide stronger isolation than branch naming alone.

For release integrity, build an immutable artifact from an identified commit and promote that same artifact through staging and production. Record the source commit, artifact digest, test results, and release tag. Do not assume that rebuilding after a merge produces identical output, or that a new merge commit is identical to the tested release candidate; verify the relationship between the released source and the promoted artifact. Environment-specific configuration and secrets should be supplied separately rather than maintained through divergent copies of application code.

Gitflow suits teams that need explicit release stabilization periods or coordinated versioned releases. Its costs include long-lived branch divergence, repeated merges, and delayed integration feedback. It is not synonymous with GitHub Flow, trunk-based development, or continuous deployment. For frequent small production changes, a simpler branching model may reduce coordination costs. In pipeline design questions, distinguish the branching policy from the mechanisms that enforce reviews, trigger builds, isolate environments, and authorize deployments.