5 ms·

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

by elyobo 7y ago

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.

chrisweekly 7y ago
Cool! This is almost exactly what I've been doing and recommending for many years.
crgwbr 7y ago
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.
- dwd 7y ago
  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.
babayega2 7y ago
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...
cactus2093 7y ago
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.
- theK 7y ago
  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...
xorcist 7y ago
That model tends to break down as soon as you need more than one development branch.
- elyobo 7y ago
  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).
evrydayhustling 7y ago
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.
pmoleri 7y ago
> * 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?
- elyobo 7y ago
  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!
- deleted 7y ago
  [deleted]
- Double_a_92 7y ago
  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).
  - pmoleri 7y ago
    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.
brown9-2 7y ago
> 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.
- elyobo 7y ago
  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).

by elyobo 7y ago

chrisweekly 7y ago

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

crgwbr 7y ago

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.

dwd 7y ago
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.

babayega2 7y ago

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...

cactus2093 7y ago

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.

theK 7y ago
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...

xorcist 7y ago

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

elyobo 7y ago
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).

evrydayhustling 7y ago

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.

pmoleri 7y ago

> * 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?

elyobo 7y ago
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!
deleted 7y ago
[deleted]
Double_a_92 7y ago
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).
- pmoleri 7y ago
  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.

brown9-2 7y ago

> 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.

elyobo 7y ago
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).