The idea of post-merge code review is horrifying to me. I guess this is the "move fast and break things" attitude in action.
Deploy now, catch bugs...sometime, maybe (TM)!
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.
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.
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 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.
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.
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.
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?).
> 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.
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.
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”.
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.
https://www.atlassian.com/git/tutorials/comparing-workflows/...
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.
(OK, "git flow" was in a way even worse; that was Atlassian trying to usurp the generic "git" name for their own particular flow.)
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.
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.
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.
Given the state of literally all software I use, this seems to be the default behaviour.
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.
At least having another pair of eyes check text-only changes has caught so many typos, etc, and only takes a couple minutes.
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.
See the books Accelerate: The Science of Lean Software and DevOps, and The Toyota Way for more.
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.
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.
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.
(Confession: At least I "think* this is an example of getting them confused. They are different things, right...? The same difference you mentioned?)
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.
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'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.