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: Workflow

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

  • 1
    I have added a section about branching strategy. Sep 22, 2014 at 11:31

2 Answers 2


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.

  • I just tried this out today and it went horribly. Cheery picking the features from dev to staging and master went well. But when it came to reverting and merge'ing master into staging and dev, it began to conflict. We have to find another strategy where we'll merge.
    – Gaui
    Sep 23, 2014 at 18:13
  • Reverting? Why are you reverting? Sep 23, 2014 at 20:01
  • Some features don't pass through testing/staging
    – Gaui
    Sep 23, 2014 at 21:05
  • I'm trying out tagging a feature when it's ready for testing/staging. Gonna see how that works out.
    – Gaui
    Sep 23, 2014 at 23:36
  • I dont think you can expect to just cherry pick features to deploy except for very simple things. If a feature dont pass testing you just add more commits to dev until it is fixed. Sep 24, 2014 at 7:45

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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.