I agree with the middle ground comment. That is how we tend to do things where I work.

We have a modified GitFlow: main: is the source of truth and is what is in production. develop: is the constantly moving branch we make PRs against. You can commit directly here which is discouraged but it isn't a hard rule. ticket: is a branch for each JIRA ticket not each feature. release: We don't make these and just use tags on main. Each "release" is a merge from develop to main and that gets deployed. hot fix: These are made against main and merged back to develop when they are used. It is rare enough I have to look up our "official" procedure.

With that we can easily use PRs, release code in small hidden chunks, do code reviews, etc.

Seems like the big win they got was releasing small hidden chunks of a feature and deploying it to staging. They also gave up some nice things as well like code review before merging.

> ticket: is a branch for each JIRA ticket not each feature.

This kind of thing really grosses me out. Why can't you just include the issue number in relevant commit messages? Why does it matter what your branches are named?

Naming branches relevant to what they actually represent is incredibly important to me, personally. I don't care what you do but I refuse to play by this rule in particular, when it's a hard rule.

I've worked with lots of variants, and by far I find using both works best: feature/PROJ-124-user-edit or bug/PROJ-234-startup-crash

This unambiguously lets you trace back to the ticket (as either the author or owner), but keeps the branch readable (you don't have to go to the ticket to see what it is). It also makes the merge message (containing the branch name) much more useful when looking back months later.

It works with multiple branches per ticket (which I often do to make PRs easier): feature/PROJ-456-refactor-config, feature/PROJ-456-config-ui

It avoids having to worry about the text name. There's no worry about duplicates, either current or historically. It can also be short: just descriptive enough so someone looking at the branch list can see what's what, and you can find yours without memorizing ticket numbers.

The ticket is also very useful when you're cleaning up old branches: maybe there was a different fix and this was abandoned, or maybe it was blocked and then forgotten? The ticket can answer that.

It's very low effort: you naturally know the ticket when creating the branch. After that, you just work on the code, and when you're done the ticket number is right there for you - no searching, sticky notes or kanban board necessary.

Edit: the bug/ or feature/ prefix is optional, but keeps the display way nicer: most UIs will treat it like a folder and allow to collapse, keeping the top level organized and tiny. The classification is also easy and useful - at a glance you can see if it's mostly fixes or new features happening (without looking at your issue tracker). For products with released versions, release/1.0, release/1.1 etc works well for the same reason.

Sorry, I didn't mean to imply that the branch is named for the JIRA ticket. I personally like to have the ticket number in the branch name along with a description though. It was more that each ticket branch is for a small chunk of work that can be merged and deployed when a single ticket is complete not when the whole feature is complete.

Weird. In a GitHub-flow model I don’t care about branch names at all except inasmuch as that they need to be unique.

Branches pushed to origin are just a backup of the commit log that leads to a pull request - they’re ephemeral, belong to the pulled request author(s) and are nobody else’s business but theirs.

I don't know about Jira, but Gitlab has a pretty cool thing whereby it can detect the relevant issue when you git-push a branch to the repo, by looking at the branch name (e.g. 123-some-issue is linked to issue #123).

This works with Jira too. It automatically links to the ticket commits

Not gp, but I (almost) never read commit messages. And usually tickets are so amorphous that it's hard to come up with a good name for the branch,so I always use the ticket number.

Of course, I have no problem with well named branches, but when not doing it by ticket number, you tend to get nearly meaningless branch names: search, fix_color, tooltip, search2.

That said I'd never mandate it, it just seems easier.

I have the opposite experience across the board. The ticket number tells me nothing, I can't grep for context, git blame turns to utter noise.

I constantly read commit messages. Branch names are usually similar to commit messages: xyzzy/fix-menu-style or xyzzy/add-menu-tooltip.

If you just wrote a commit message that's just a ticket I'd block your review until you wrote a proper message and it's a hill I'm happy to die on.

But now the development is pretty much tied forever to the issue tracker. As to read the code history need to have the access to the issue tracker to understand the reasoning. Which to me sounds like a bad idea for the future.

> We have a modified GitFlow: main: is the source of truth and is what is in production. develop: is the constantly moving branch we make PRs against. You can commit directly here which is discouraged but it isn't a hard rule. ticket: is a branch for each JIRA ticket not each feature. release: We don't make these and just use tags on main. Each "release" is a merge from develop to main and that gets deployed.

If you're a huge team with a slow release process then I guess you need that develop/master split, but it's costly. When I've worked in a small team we've had a single master branch and every feature branch gets released and deployed immediately after merge (with a "lock" so that you don't merge your feature until the previous person has signed off their deploy), with each feature branch ideally representing a user-visible agile feature (i.e. up to 2 weeks' work) - IMO you don't gain a lot by merging something that doesn't have a user-facing deliverable (how can you be sure the code you're merging is right or not?).

The develop/main split for us is not costly I'm not sure what overhead others are incurring there. We run deploys on demand throughout each day. We don't have the same sign off process or block other deploys. We just send develop to staging and once it is confirmed good we merge it to main and then out to production.

> IMO you don't gain a lot by merging something that doesn't have a user-facing deliverable (how can you be sure the code you're merging is right or not?).

I disagree but to each his own. I think you can release small parts with testing around it. I often release half of a back end feature, then the other half, then the front end all in separate branches and releases. All I really need is to have the parts broken down into logical testable chunks.

> The develop/main split for us is not costly I'm not sure what overhead others are incurring there.

Mainly the mental overhead and the risk of confusion or mistakes. Presumably you still need some co-ordination to make sure two people don't try to release at once. (What do you do if someone else merges a feature to develop while testing on staging is ongoing?)

> we merge it to main and then out to production.

Hmm, so what you deploy to production is a different artifact from what you tested on staging? I'd find that worrying.

> I think you can release small parts with testing around it. I often release half of a back end feature, then the other half, then the front end all in separate branches and releases. All I really need is to have the parts broken down into logical testable chunks.

It's sometimes unavoidable, but my thinking is: yes you can unit test, but how can you possibly know that you're testing the right thing if your change isn't user-visible? You can confirm that your code works the way you think it works, but you can't confirm that it actually delivers the functionality you want. IMO it's only worth putting something in the shared branches once you know you're not going to significantly rework it (otherwise you're causing as many conflicts as you're avoiding), and you can only know that when you've actually tested it end-to-end.

Having develop and main seems like more of a pain than PRs to main and using release branches. This model is also very limiting if you need to support multiple releases in parallel. Maybe this does not apply to your team.

We really only have staging/production so it works great for us, we don't have to support multiple releases at the same time. I agree it gets more difficult if that is a concern.

I don’t see what it gains you even with that limit, though. You’re essentially using your main branch just to hold tags. If you rename “develop” to “main”, your big merges to main go away entirely and turn into zero effort branching.

One of my biggest concerns about long lived branches is that they drift. Tiny merge issues end up accumulating over time, or people forget to merge back a hotfixes, and you can end up with your dev branch behaving slightly different from your release branch. This model can work but it is more complex and more brittle in a world of cheap branching.

I have gone through the big move from long lived branches to “trunk based development” twice in two very large code bases. In both cases the move showed us many places the codebase had unintentionally diverged over the years because we had to reconcile all of it to establish the new “main”.

For us, whether you commit directly to develop or create a branch is more of a decision whether QA needs to be involved . Once you are done, you merge with squash so develop has no merges and later it's not even visible whether you just committed into develop or worked in a branch. Obviously this might not work if your work involves large changes but we work in tiny bits.

Yeah, feature flags are increasingly mainstream / worthwhile, but I hate the idea of giving up on not just CR before merging, but also "preview deploys" (from feature branches to ephemeral deploy envs).

Yes, a good middle ground is the slightly confusingly named “GitHub flow”: https://docs.github.com/en/get-started/quickstart/github-flo...

The main branch is always stable, releasable. Feature branches are branches off main, which are then merged back into main. No develop or release branches.

It is like trunk based development, especially if branches are kept short and regularly rebased onto origin/main, but with a point to run PR checks before merging.

This is how most people I know develop and have done for years but I've never heard anybody ever call it "github flow".

I also lifted an eyebrow at this. It‘s just „trunk based development with feature branches and prs“.

It reminded me of when Microsoft used to pay people to say "just bing it".

The term predates the Microsoft acquisition by a number of years.

See cousin comment: https://news.ycombinator.com/item?id=29609937

I think it acquired this name to distinguish from “git flow”, an alternative way to use git that is, put politely, somewhat of a maintenance headache.

https://www.atlassian.com/git/tutorials/comparing-workflows/...

I agree gitflow is annoying but this name sounds more like a cringey excuse to attach a Microsoft trademark to a common practice to me.

The term “GitHub flow” existed prior to the Microsoft acquisition. The GitHub documentation history would be definitive, but you can find articles dating back to 2014 discussing GitHub Flow vs GitFlow. The acquisition was in 2018.

I agree that the name isn’t the best. It is however at least specific. “Trunk based development” encompasses a class of development processes. Although I don’t think I’ve ever actually described a real world process as “GitHub Flow” because almost no one knows what it specifically is anyway.

Disclosure: I work for Microsoft.

Still just a cringey excuse to attach a trademark to a common practice, only sans the "Microsoft".

(OK, "git flow" was in a way even worse; that was Atlassian trying to usurp the generic "git" name for their own particular flow.)

> Still just a cringey excuse to attach a trademark to a common practice, only sans the "Microsoft".

I don't understand any of this sentence. Of course it's "sans Microsoft". It predated the acquisition by years.

But also I don't see the "cringe" here. "GitHub flow" was introduced as "this is what we do at GitHub". It is (or at least was?) the GitHib flow. https://githubflow.github.io/

> OK, "git flow" was in a way even worse; that was Atlassian trying to usurp the generic "git" name for their own particular flow.

Atlassian didn't even create GitFlow. https://nvie.com/posts/a-successful-git-branching-model/

I don't understand this mindset that starts with assuming everyone is essentially a bad actor.

> I don't understand this mindset that starts with assuming everyone is essentially a bad actor.

It's pretty hilarious how some people use "I don't understand..." to imply that whatever it is they don't understand is bad, apparently completely oblivious to how it actually speaks more to their own powers of comprehension.

I often say "I don't understand..." because I'm willing to concede that sometimes my viewpoint is incorrect and I'm interested in correcting my views. Also because sometimes saying "I don't understand" is enough to get someone who holds an invalid/incorrect/unhelpful belief to restate their viewpoint clearly enough that they can see the problem with it (but of course that requires the other party to actually engage in a constructive way). And sometimes I say "I don't understand" because it's just more polite than insulting the the misinformed person.

For example, when I said "I don't understand" to your "Still just a cringey excuse..." comment, what I was really saying was "this sentence is poorly written and hard to understand, and you also clearly don't understand the context of where the term actually came from".

When I said "I don't understand" about assuming people are bad actors, I was really saying "you seem to be using the assumption of bad intent to mask your ignorance about the things you're talking about".

So now, I'll say I don't understand why you're nitpicking my use of the phrase "I don't understand" instead of responding to anything of substance I said.

By this of course I mean that it's clearly easier for you to attack my intellect than for you to self-reflect.

Very similar to GitHub Flow is trunk based development:

https://trunkbaseddevelopment.com/

> Deploy now, catch bugs...sometime, maybe (TM)!

Given the state of literally all software I use, this seems to be the default behaviour.

I've found that to be a great middle ground on most teams.

If you want to stretch it a little more, you could selectively do post-merge reviews for things that might be low risk (ie a UI change that's behind a feature flag that only your team sees), and keep riskier changes (like a big refactor, a data migration, etc) on the pre-merge review flow.

We have pre merge review - but for trivial stuff, text / label changes, etc, put a "tiny" tag on the PR, and if urgent paste it to the slack channel asking for a glance and nod review...

At least having another pair of eyes check text-only changes has caught so many typos, etc, and only takes a couple minutes.

To make this process safer I usually recommend:

  1. Put all new code behind feature flags that are off by default in production.
  2. Make rolling back easy.
  3. Have extensive unit and integration tests.

Some of the deployment steps could be automated even further -- maybe the CI server automatically deploys Staging after a successful build.

See the books Accelerate: The Science of Lean Software and DevOps, and The Toyota Way for more.

> Put all new code behind feature flags

How is that even possible? A comma change in a feature can break things, are you going to put that change behind a feature flag?

"New code" isn't just "new files/functions", so it's not always feasible to keep it behind flags, unless you use a "copy on write" methodology to all code.

Parent commenter probably meant putting new features behind a flag. I work for a major feature management company and we heavily use our own platform. Yet we don't put "all code" behind feature flags but we do with features. It's nearly impossible to put "all code" behind feature flags.

Right, basically this. If you're shipping something new that could affect production, put it behind a feature flag so the code paths that are already live are unaffected. Continuously ship small changesets so that it's easy to roll back if necessary.

> If you're shipping something new that could affect production…

Which, again, is everything. I’m all for feature flags, but they cover very specific cases. There are many changes that feature flags cannot cover. The addition of the feature flags itself can introduce bugs. They are a great feature but only one small piece of protecting production.

What's makes you think that just because you code rewiew after it hits trunk that you deploy before review?

I think the problem people have with trunk dev is they don't grok that some projects don't have the same deployment strategy as them. There is a thing called a code freeze. This is a common practice. Not everyone does it.

Just because you do trunk dev does not mean you can't also have a feature branch to try stuff out or a release branch or any other number of branches. What trunk dev means is get your ode out there to other devs quick. Not necessarily get your code out to production or to QA or the customer quick. Those decisions can be independent of branch strategy.

It's easy to confuse continuous integration and continuous deployment because they're so often mentioned in the same breath. Aren't they collectively called "CI/CD"?

(Confession: At least I "think* this is an example of getting them confused. They are different things, right...? The same difference you mentioned?)

I'm guessing this is a reference to "MIME, someday, maybe" - http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.ht...

Context matters.

What is the cost of a bug getting into the wild vs what is the cost of keeping the bug rate very low?

If you're NASA or a high frequency trading company I'm guessing the cost of bugs can be very high. If you're making internal tools to automate admin tasks the cost of bugs is often very low.

> If you're NASA

I don’t think it's fair to pick something extra-ordinary to respond to the article. Obviously "no worries" doesn't apply if the stakes are high.

I'm not trying to say it's binary. That you're either NASA or your quality doesn't matter. NASA is only the furthest on one end of the scale that I could think of. There is a scale and you have to know where you are. There is always a trade off between the amount of work you can get done and the amount of QA process you have in place. With infinite resources it wouldn't matter but us programmers are expensive.

This is the way it's done at many major tech companies. Each individual commit is reviewed then merged directly into main/master.

I've never used them but the thought of feature branches seems absurd versus simply merging small changes. Very rarely can a "feature" not be broken down into small self-contained changes.