Implementing continuous delivery requires a well-defined Git workflow that can manage features, updates, peer review, testing and deployment in an efficient manner. In this blog post, we will explore some common approaches to Git workflow for continuous delivery.

Git Flow is the most common workflow for continuous delivery and is often considered the industry standard for good reason. It involves packaging features and tickets together into discrete releases. This maps nicely to Scrum sprints as the deliverable from each sprint is the release of all of the component features.

Below is an illustration of what this would look like. Each ticket would have its own feature branch and can be worked on independently. Once ready for testing, they can be merged to the develop branch for user acceptance testing. Then deployed to production in a single release by merging develop to main (always via a pull request of course!).

There are some velocity drawbacks to this approach in the real world. For example, a small bug in a feature could hold up an entire release, or you may have to remove the feature from the release entirely, delaying the feature by a sprint. Rolling back a release means rolling back all changes made on the release branch.

Another common approach is to release each feature or ticket separately. The develop branch is never merged directly to production, just the feature branches.

Each feature branch can be tested, peer reviewed and released independently of each other. You will never have to hold back on an entire release because of a single feature. If something breaks, you can just roll back the offending feature.

This might look like below. Tickets can be worked on and tested independently, then released at any time. Even out of order, tickets can be released at any point in time, once they are ready for release. Each feature branch should be peer reviewed and merged to main via a pull request.

There are some drawbacks to this approach. Branches can easily become out of sync, causing merge conflict problems.

For example, if you are working on two features that require a common component, the two branches will quickly get out of sync with one another. This happens in Git all the time, but with this approach, these merge conflicts cannot be fixed as the work is being done. You have to wait until one of the feature branches is released to production. Then you can merge the main branch back into your feature branch.

Ultimately, when it comes to implementing continuous delivery in software development teams, deciding on the right Git workflow is a critical component. The key is to find the workflow that works best for the project, making tradeoffs between the benefits and drawbacks of each approach.