Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything as code: How we manage our company in one monorepo

kasava.dev

Post reply on HN
Print view View original

111–120 of 232 posts

Re: Everything as code: How we manage our company in one monorepo

#111

Post by catlifeonmars »

UltraSane wrote: post #90
sallveburrpi wrote: post #26

Earlier quoted context omitted.

squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess

"squash results in a cleaner commit history" Isn't the commit history supposed to be the history of actual commits? I have never understood why people put so much effort into falsifying git commit histories.

“Falsifying” is complete hyperbole. Git commit history is a tool and not everyone derives the same ROI from the effort of preserving it. Also squashing is pretty effortless.

Re: Everything as code: How we manage our company in one monorepo

#112

Post by catlifeonmars »

eddd-ddde wrote: post #20
giancarlostoro wrote: post #16

Earlier quoted context omitted.

I like keeping old branches but a lot of places ditch them, never understood why. I also dislike git squash, it means you have to make a brand new branch for your next PR, waste of time when I should be able to pull down master / dev / main / whatever and merge it into my working branch. I guess this is another reason I prefer the forking approach of github, let devs have their own sandbox and their own branches, and…

I'm very fortunate to not have to use PR style forges at work (branch based, that is). Instead each commit is its own unit of code to review, test, and merge individually. I never touch branches anymore since I also use JJ locally.

What is JJ?

Re: Everything as code: How we manage our company in one monorepo

#113

Post by conartist6 »

maxvirrozeito wrote: post #18
conartist6 wrote: post #9

I really want the world to move on from monorepos to multirepos. Git submodules set multirepos back by 10 years, but they still make more sense. The are composable!

For me, integrating features that spans multiple repositories means coordinating changes, multiple PRs, switching branches on many repos to do testing. Quite time consuming. I did use submodules but I find monorepo easier to manage

I don't doubt that it is. Monorepo tools are much better right now. But monorepos don't compose. They don't branch. They don't scale.

Re: Everything as code: How we manage our company in one monorepo

#114

Post by gorgoiler »

lorey wrote: post #30
eddd-ddde wrote: post #10

I am a huge monorepo supporter, including "no development branches". However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo. Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.

Very interesting points. Would you mind sharing a few examples of when cherry-picking is necessary and why atomic changes are a lie? I'm using a monorepo for my company across 3+ products and so far we're deploying from stable release to stable release without any issues.

If your monorepo compiles to one binary on one host then fine, but what do you do when one webserver runs vN, another runs v(N-1), and half the DB cluster is stuck on v(N-17)?

A monorepo only allows you to reason about the entire product as it should be. The details of how to migrate a live service atomically have little to do with how the codebase migrates atomically.

Re: Everything as code: How we manage our company in one monorepo

#115

Post by joshgachnang »

giancarlostoro wrote: post #2

I used to be against monorepos... Then I got really into claude code, and monorepo makes sense for the first time in my life, specifically because of tools like Claude. I mean technically I could open all the different repos from the parent directory I suppose, but its much nicer in one spot. Front-end and back-end changes are always in sync this way too. I guess I could work with either option now.

I've been a big fan of monorepos for awhile, but like the author, not a huge fan of using e.g. yarn workspaces. React Native can get pretty pissy with hoisting. I just started putting things like implementation plans and PRDs in the repo and I'm loving it so far. It helps give AI more of the context to make good choices.

Re: Everything as code: How we manage our company in one monorepo

#116

Post by catlifeonmars »

sethammons wrote: post #17

people talk about "one change, everywhere, all at once." That is a great way to break production on any api change. if you have a db and >2 nodes, you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes. While more obvious with a db schema, it is true for any networked api. At some point, you will have many teams. And one of…

> Having all the context for AI in one place is hard to beat though.

Seems like a weird workaround, you could just clone multiple repos into a workspace. Agree with all your other points though.

Re: Everything as code: How we manage our company in one monorepo

#117

Post by gbear605 »

esafak wrote: post #74
TheGRS wrote: post #50

Earlier quoted context omitted.

Not everyone develops and commits the same way and mandating squashing is a much simpler management task than training up everyone to commit in a similar manner.

Besides, they probably shouldn't make PR commits atomic, but do so as often as needed. It's a good way to avoid losing work. This is in tension with leaving behind clean commits, and squashing resolves it.

The solution there is to make your commit history clean by rebasing it. I often end my day with a “partial changes done” commit and then the next day I’ll rebase it into several commits, or merge some of the changes into earlier commits.

Even if we squash it into main later, it’s helpful for reviewing.

Re: Everything as code: How we manage our company in one monorepo

#119

Post by esafak »

mattbillenstein wrote: post #108
trevor-e wrote: post #65

Earlier quoted context omitted.

Good luck getting 100+ devs to all use the same logical commit style. And if tests fail in CI you get the inevitable "fix tests" commit in the branch, which now spams your main branch more than the meaningful changes. You could rebase the history by hand, but what's the point? You'd have to force push anyway. Squashing is the only practical method of clean history for large orgs.

This - even 5 devs. Also rebasing is just so fraught with potential errors - every month or two, the devs who were rebasing would screw up some feature branch that they had work on they needed and would look to me to fix it for some reason. Such a time sink for so little benefit. I eventually banned rebasing, force pushes, and mandated squash merges to main - and we magically stopped having any of these problems.

Rebase before creating PR, merge after creating PR.

Re: Everything as code: How we manage our company in one monorepo

#120

Post by alemanek »

UltraSane wrote: post #90
sallveburrpi wrote: post #26

Earlier quoted context omitted.

squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess

"squash results in a cleaner commit history" Isn't the commit history supposed to be the history of actual commits? I have never understood why people put so much effort into falsifying git commit histories.

Here is how I think of it. When I am actively developing a feature I commit a lot. I like the granularity at that stage and typically it is for an audience of 1 (me). I push these commits up in my feature branch as a sort of backup. At this stage it is really just whatever works for your process.

When I am ready to make my PR I delete my remote feature branch and then squash the commits. I can use all my granular commit comments to write a nice verbose comment for that squashed commit. Rarely I will have more than one commit if a user story was bigger than it should be. Usually this happens when more necessary work is discovered. At this stage each larger squashed commit is a fully complete change.

The audience for these commits is everyone who comes after me to look at this code. They aren’t interested in seeing it took me 10 commits to fix a test that only fails in a GitHub action runner. They want the final change with a descriptive commit description. Also if they need to port this change to an earlier release as a hotfix they know there is a single commit to cherry pick to bring in that change. They don’t need to go through that dev commit history to track it all down.

Post reply on HN