Best (in your opinion) GIT workflow for case when releases are done on demand (in most cases 1-2 tickets at once)

Question

I'm rather a Git newbie and I'm looking for your advice.

In the company I work for we have a "workflow" where we have a single Git repo for our project with 2 branches: master and prod. All devs work on the master branch. If a ticket is done (from the dev perspective), we push to the repo. If all tests are passed, we make a release.

The issue is that in most cases, the request from business guys sounds like: "please release ticket A or A && B".

In most cases, I end up doing something like

git checkout prod
git cherry-pick --no-commit commit_hash
git commit -m "blah blah to prod" -a

As you can see this is not a perfect solution, and I'm under a huge impression this is a perfect way to nowhere especially when change A depends on changes B and C.

Do you have any suggestions how to handle releases on demand if more devs works on the same branch and the flow looks like I described above? All suggestions are welcome.

I cannot change business processes and it will have to stay as it is - unfortunately.

Answer 1

We used a workflow like yours for two years and recently abandoned it. We found four problems with it, each of which becomes exaggerated the longer you use the workflow. It was a staggering waste of time, requiring nearly full time effort by our (admittedly small) release staff to manage. Here's what you're going to hit in a few months, if you haven't already:

1. Your master and prod branches don't share commit history, meaning they can't be easily merged into one another. This would be especially evident in your version of this workflow, as you're cherry-picking with the --no-commit flag, and then recommitting the files. You are, in a sense, maintaining two distinct git repositories over the same set of code. This sounds manageable until you hit...

2. Because master and prod have different histories, but prod is a subset of master's changes, your branches will diverge over time. Sometimes new features get scrapped. Sometimes the business guys will change the priorities. Sometimes an idea seems great until you get 40 commits in and realize it breaks everything. Bugs will be introduced in the master branch that aren't reproducible on prod, and some of them will be artifacts of code that never sees prod at all. Without constant upkeep, master's integrity degrades. It's annoying, frustrating, and prevents real work from getting done. Even worse...

3. You'll end up fixing merge conflicts in master that don't exist in prod. When you cherry-pick these commits over to prod, you stand a small chance of introducing bugs during the cherry-picking process. Your master code is almost your prod code, but the small differences could create Unintended Consequences. The problem is exaggerated if your developers aren't particularly careful about whitespace or like to 'experiment'. If Genius Developer Susie (who really is quite bright but tends to refactor legacy files to be more readable) checks in a bunch of whitespace changes along with a legitimate code fix or two, you're going to put your production branch in a weird gray state between what it was before and what it is on master.

4. Finally, if you combine -1-, -2-, and -3-, you hit the worst problem we encountered: It's difficult to compose, test, and release emergency fixes and features. When it's a crisis -- you just introduced a security hole in your application; bizdev just signed MoneyBags McEnterprise for the GDP of a mid-sized nation and all they need is a brand new suite of tools by COB -- you need to fix prod because that's what has to work, but you can't. Not easily. All your devs are running master locally. They can run prod by switching branches, but your test framework is hardwired to master's code and it's going to choke all over the new parts of prod. That's okay, you can just write it on prod and cherry-pick it back over to master, right? Hmmmm. Not without hitting merge conflicts and divergent files. How about feature branching prod and just outright merging it into master? Oh yeah, they don't share history...

It's possible we simply didn't think hard enough about these problems. Someone out there, I promise you, is careful enough about commits and history to make this work, and you might hear from them in other answers. All the same, this workflow wasted buckets of time over the two yeras we used it. We reformulated our workflow around a few key ideas:

First, branches in git are cheap and easy, so we use them for every feature or case. We developed a naming scheme whereby developers push case-specific branches (case numbers provided by our issue tracking system) to a sharable place. We use gitorious to give each developer a personal remote repository, but there's no reason you couldn't push these "in flight" features and cases to a shared origin. It requires some organization and tracking, but much less then that required by the problems described above.

Second, these feature branches should be cut off production, not master. Unless a feature or fix depends on another change set that is "in flight", it should be based on the most upstream branch that shows the problem or requires the feature. For us, that's always production.

Third, master, or whatever we're calling our main development integration branch, is simply a collection of "in flight" feature branches merged on top of production. It exists for integration testing and to identify merge conflicts and dependencies between feature branches earlier. It is not something upon which we base new code. We reset it with every release, and automated the tracking and merging of "in flight topics". We also maintain a separate next branch for the QA department, which is cut off production and contains only those feature branches that are going out in the next release.

It's a workflow we adapted from the git project itself. It's distributed and quite a paradigm shift for us. It might work for you, but if it doesn't, I would still recommend seeking another workflow. Your current one will degrade over time, to the point where you could end up fighting the version control as much as you fight the code.

Answer 2

A common reference for branch workflow is A Successful Git Branching Model