Git | Branching model for a large project

Question

Our team has three back-end developers and two front-end developers. We're using Git as a version control system, Jira for issue and project tracking, and Stash as a Git repository. And finally, we're using SourceTree (with git-flow) as Git client.

The problem is about our branching strategy: We're using Vincent Driessen's branching model. Everyone creates a feature branch for each issue and merge it back to develop when it's done (via pull request and after a review on Stash). Other than that, we create bugfix branches for finished but not yet released issues, hotfix branches for released issues and release branches for finished sprints. No-one touches develop and/or master directly in this scenario. Our front-end team uses Sass as CSS pre-processor. And finally, we have TeamCity to build changes, and it looks for the changes on master branch.

---

Enough with the back-story, huh? Okay then, here's the problem: Let's say we have 50 issues in the sprint (10 for each of us), and at the end of the sprint, client wants to release only 35 of them (no need to ask why, it's the client). So, we need to exclude 15 issues somehow. Mostly, they are front-end issues. And because of our setup, everything is on develop branch at this moment. We have couple of alternatives now:

• Creating a release branch from develop and reverting those 15 issues (we need to either update TeamCity, or merge this branch back to master afterwards).
• Putting everything to master reverting on there (no need to touch TeamCity in this scenario).
• Cherry picking wanted issues onto master (this will probably end up with lots of conflicts as well).

But both of them has this restriction: Sass-to-CSS operation. If we choose the first option, and there're some front-end issues, there'll be a conflict for sure. If we choose the second option, we're loosing track of what is where and I think this is kind of abuse in the end.

And there's this big global restriction: We need to do our tests on develop (so, every finished issue needs to be on develop to test, this can't change) and we're releasing what's on master (there's a way to change this in TeamCity, but no-one wants to change it).

The question is this: How we can use Git continuously when there are some improvements and stoppage at the same time?

I can provide more details if you need, feel free to ask.

Answer 1

Hopefully I understood your problem well. I would see a 4th solution as more viable for your case:

• use develop the same as until now, having everything there, since you have to do your tests there
• set a production (or release) branch -> this will be your release branch, at least for now, until you can fully deploy everything (if your client will ever want that)
• since you said everything is on feature branches, you can easily merge these branches into the production one after they were tested on develop. Basically develop is your qa branch (for testing purposes). This is better than cherry-picking tens or hundreds of commits at the end of the sprint.

So what I'm basically suggesting is after merging the feature branches into develop, don't delete them, do eventual bugfixing related to a feature on that feature's branch, and then merge the branch into the production one.

Let me know if you think there are reasons why this approach won't work (apart from the fact that you have to change the release branch configuration).