Hacker News Reader

Hacker News

Comment by elyobo | Hacker News Reader

Parent Full thread

elyobo

I have two long lived branches, develop and master.

* major features are done in feature branches, w/rebasing prior to merge

* minor stuff directly in develop

* master is auto deployed following successful CI, whenever we merge develop in to it

* we merge frequently, but not automatically

* we tag releases manually when we do merge

It's a more minimal version of git flow. Small teams so not much problem.

We could probably just drop the develop / master split and still be fine, but would force all changes to be in feature branches instead.

View on HN

This still sounds like an anti-pattern to me, at least in a typical web app. I’ve seen a very similar workflow used in a previous org, and the main benefit was that it limits the number of times you have to cross your fingers and hope for the best (which is obviously masking other reliability problems). Merging each feature branch wasn’t scary because it wasn’t going to deploy yet, but that means it incentivizes somewhat of a “not my problem” culture. Then at some point someone builds up the courage to merge the develop branch to master and you hope for the best. Repeat every few days.

There was also some wishful thinking about doing more qa testing than anyone actually did. The develop branch would immediately deploy to the staging environment, so someone might have tested new features there before they ship to production. But if there’s no rigorous process around exactly what needs to be QA’d and whose responsibility it is, then let’s be realistic, it’s not gonna happen.

The downsides are that release times were less predictable, deploys were bigger which means potentially more difficult to trace down bugs that do show up and roll back when needed, and things would get delayed for no reason. Oops, I thought I shipped that thing for marketing a few days ago but nobody deployed the develop branch since then.

Developing small features right into develop sounds like a bit of an issue on its own too. Seems like you’re not quite confident enough to deploy it right away, but it’s also presumably circumventing the regular code review process so it’s not going to get reviewed.

The only reason I can see for why these downsides would be worth it, is if you have some hard constraint that you can’t deploy very frequently (for instance releasing a downloadable desktop app or mobile app), and/or you have a formal, rigorous manual QA process when merging from develop to master.

In my experience, an additional gap between working directly on master is many teams don't understand the concept of promoting builds. So e.g. you can build on every commit, then _after the fact_ promote one to an actual release (without re-building). This isn't suitable for _every_ situation, but it is for all the ones I've encountered so far.

Relatedly is "release branches". An alternative is to simply tag the release that went out, which is the same thing. If it needs a hotfix, you branch off the tag, fix it there, then apply that fix (cherry-pick or redo) back to master.

Overall, IME the biggest benefit is the cultural changes it instills in the team: Everything must be good enough to release, and everything goes to the same place. For projects that can afford it (again, most can I bet) its a huge drop in mental effort to understand the state of the world at any given time.

I don’t get it. I manage multiple teams that are doing web apps. Many of those use Gitflow like life cycles and none of them has issues based on their lifecycle. Some of them do release branches, some not. Some do ff-only other don’t. Doesn’t really matter as long as it is efficient (simple) enough. Of course we are also not only deploying the long lived branches but actually every push results in some sort of ephemeral environment being spun up tested and spun down again (or stick around in car of failures) so Feedback on what is happening is quite direct but any way. If you help teams find a pragmatic lifecycle for them you can avoid all the perceived issues of any cv lifecycle.

One exception might be the occasional group of optimists trying their hand at micro repos. These are just bound to blow up :-D unnecessary conplexity and all...

Indeed. i have been using Gitflow for the last 4 years on more than 14 repositories with teams spanning from 2 to 30 commiters and it worked. I honestly do not see what is the problem with having the code running on production on master, develop harboring the code deployed on review branch, and release/tags branches deployed on QA environment. Moreover each team can adapt the model to it's own workflow...

> * major features are done in feature branches, w/rebasing prior to merge

Rebase in a feature branch, that can be long-lived and have many commits, seems like a painful experience to me.

You can end up solving the same conflict more than once, or even solving conflicts that don't exist in the final result. no-ff merge commits are usually easier to solve.

Am I missing something? Is there an easier rebase strategy?

Sometimes it's painful, normally it's not, and yes - the longer lived it is the more painful it's likely to be.

no-ff merges are easier, but leave a messier non-sequential history of when things actually go out which is sometimes confusing when understanding why things are the way they are; I generally, but not always, judge it to be worth the pain!

Same. I think people just have different ideas of what "long lived" means. To some it might be a few days of work, to some weeks.

We actually merge the master into our long lived feature branches first. Then run all the tests on that branch, if it's good it can be directly merged into master (master is locked, and you need permission to commit anything to it).

I think so. Sometimes we have long-lived branches with multiple contributors for new features. Is this some kind of anti-pattern? We don't use feature flags, they seem hard to maintain and restrictive in terms of what you can do (e.g. structural changes). OTOH, because we're a small team, when there's a lot of work in a new feature branch there's little work on master, so there's little hassle there too.

This is pretty much exactly what we do, except add in a third “qa” branch between dev and master, for the purpose of manual testing before things go to prod.

This is where GitFlow makes sense - when you have a QA and/or enduser acceptance process before code is committed to a master/release branch.

Also for DevOps you sometimes need to be able to branch off Master to apply a critical patch which then gets merged back into Dev later. You don't want to ever need to do that, but if subverting the normal process makes sense because you have all signoff parties gathered at the table - you do what needs to be done.

We use this pattern in a monorepo and it works great. Master is a reliable history of releases, and Dev is a reliable place to start your feature branch. Yes, someone has to own the decision about when and how to thoroughly integration test Dev before release, and do so often. But for 100 other reasons, this judgement call is necessary anyway.

> but would force all changes to be in feature branches instead.

So what? Those branches live for exactly as long as the minor stuff takes to develop and review.

I don't mean that as a problem, just that that's what I would do if I did it that way (and I don't see it as a problem, just the concomitant requirement for changing).

Cool! This is almost exactly what I've been doing and recommending for many years.

That model tends to break down as soon as you need more than one development branch.

Unsure how, but I've only had to work in small teams to relatively low complexity. Can you explain your use case for multiple development branches in the sense that I describe (just a combined endpoint for all merged features that have not yet been deployed).

Reply on news.ycombinator.com