Best Git workflow suitable for our needs

Question

I need help with the workflow that is best suitable for our needs. We are a 3-4 person team and are working on 4 different projects.

We have three main branches:

• master - deployable production branch
• staging - features under QA on live data
• dev - features under QA on test data

Then for each feature, we create a feature branch

What we need:

• Sometimes we would like to create a release (for many features that have something in common) and would be deployed in the end of the month.
• Sometimes we would like to deploy a specific feature/change (without creating a release). This is what we do most of the time.

Now to the workflow:

1. I start working on some feature. I create a feature branch off from dev.
2. I finish my feature (with 30 commits).
3. I squash merge my feature into dev - so it becomes just one commit.
4. The feature is automatically deployed to a testing environment and QA tests out my feature on test data.
5. The feature tested OK, so I cherry-pick my feature commit hash to a staging branch. The feature is automatically deployed to a staging environment and QA tests out my feature on live data.
6. The feature passes QA (test and staging) and is either cherry-picked to master or to a release branch, which will be merged with master in the end of the month.

Here's a picture explaining what I have in mind:

Does this all make sense? Is there a better way to achieve this goal? Thanks for your time.

Answer 1

Seems very reasonable. We are using something very similar. My advise is just to keep the feature branches small. Maybe one days work. Longer brances means lower productivity due to a large number of merge conflicts. Mostly one feature branch equals one post it note on our scrum board.

One note is you write "I start working on some feature. I create a feature branch off from dev." This is a good approach 80% of the times. Remember you have the option to branch of a pending pull request. We have a rule on the team that we should get someone else from the team to review and merge pull requests. Sometimes PRs stay in the queue for a few hours. Since we are using quite small pull requests. Sometimes feature B depends on feature A, but feature A is not going to be merged for a few hours and thus not in dev. When you want to start working on feature B just merge off of A instead of dev. It is better to merge off dev if possible, but it is a good tool in your belt. You should in that case probably wait to create the PR for feature B before feature A is merged to dev because diffs will look like both A+B which is misleading.

Answer 2

Because we have to deploy specific features on testing and staging environments, I was thinking about something like:

Two main branches:

• master

• dev

  1. Feature branches are branched from dev
  2. When a feature is ready for testing, we add a tag testing/ISSUE-1234
  3. TeamCity notices the tag and deployes to testing environment
  4. When the feature passes testing, we add a tag staging/ISSUE-1234
  5. TeamCity notices the tag and deployes to staging environment
  6. When the feature passes staging, we make a pull request to dev branch and someone reviews code and logic.
  7. If the code review went well, he merges the branch into dev.
  8. On a monthly basis we merge the dev branch into master

How does this sound?