Git workflow for somewhat large team

Question

The team I am on is using the git implementation in Azure DevOps. We have been using almost the GitFlow model. We are using story branches instead of feature branches, and the long-lived develop and master branches.

The develop branch is deployed to the development environment, and the master branch is deployed to the QA (and later to production) environments.

When a developer completes coding for the story, a pull request is created into develop. Assuming all goes well with testing, the developer would then create a pull request from develop to master.

My question comes in when there are multiple developers working in the same repository. Developer 'A' completes a PR into develop, but that code is not QA-ready (not fully tested, bugs, etc). Developer 'B' then completes a different PR into develop, and would like to get that code into master. We currently have developer 'B' cherry-pick the PR into master, but that leads to some interesting history.

We would like to be able to merge individual stories to master as the stories are ready. Is there a different workflow that would better support this?

I've been through a number of articles today, GitLab flow seems to be the closest, but seems to want to take the latest master commit into production.

Recent Edits

(I'm adding these edits to try to cover some of the recent comments, hope that's acceptable)

Our current workflow is that developers work on story (or potentially bug) branches created from 'develop'. When that code is ready, a PR is submitted to merge the code into 'develop'. That is then deployed to the development environment for initial testing. Assuming that testing goes well, the developer performs a cherry-pick to create a PR into 'master'. The 'master' branch is deployed to the QA environment, and later to production.

This is wrong on a number of levels, Stop cherry-picking for one.

It is up to the individual developer to say when code is ready to go to QA. Code is deployed to QA a few times a day, and to production a few times a week.

I am hoping at some point we move away from the 'develop' branch, and just move to 'master'-based development with story branches. I'm afraid we're not there yet.

Answer 1

What worked for me for several years is this:

• Every developer uses their own branch per PR (feature branches).
• Every day (or more often), the developer does git pull --rebase develop (or whatever other branch the PR is slated for). This way, any changes that might have happened in the target branch are always addressed early, and after resolving them, the branch is always technically ready to merge.
• Merging to the target branch is git merge --ff-only --squash, so the common history is a history of merges. If anyone wants feature development history, they can check out the feature branch.

Answer 2

In GitFlow the develop branch is supposed to be continuously "work in progress." At some point you need to cut a release branch that contains all of the items in the next deployment. After a new release branch has been created, the develop branch is open for work to be included in the release after that. The master branch gets updated when deploying to production.

It sounds like you are missing "release" branches. This allows you to isolate a group of stories in order to send them through user acceptance testing before shipping them out to production. Now Developer B, whose story has been through testing, gets included in a release branch, and Developer A is free to merge a new story into the develop branch in order to be included in the release after.

Answer 3

This approach works well for managing development and change control for a self hosted product, such as a website, or a Single Service in a Service oriented architecture. It requires that you can release small, and in isolation, and that you have good automated testing on deployment to reject broken deployments.

When i am following this branching and releasing strategy, these are the outcomes that we consistently get:

1. Small, frequent incremental change.
2. A focus on simple clear design, testable and valid changes.

In summary, if you are always less than a few days from going live, you are always thinking about how am i going to demonstrate that this change delivers the expected functional change, and that it works robustly without errors.

These are the basic rules that we follow:

• The Master branch contains all changes that are already deployed, and successfully running in the live environment. Everything else are isolated in their own separate branches, each managed by their own story / task / bug ticket.

• Each branch is intended for a small piece of work. Ideally something that can be completed in under 5 days in total for development, testing, QA and release. The goal is to release small, frequent, low risk changes.

• This is the opposite of continuous integration. Every change is managed in complete isolation from all other changes that are under development. As the confidence in the changes improves, changes are deployed into QA and staging environments and then deployed into production - and only merged into master after they have successfully deployed into production.

• We continually incorporate all production releases, the build server fails builds if they do not have all of the changes available in master.

It does not work well if you are releasing a product to other teams to incorporate as an input into their project, or are releasing shrink wrap software that customers install themselves. The high rate of releases will upset your customer base, and you will be missing the important successful deployment that validates that the newly deployed code is successfully running