Hacker News Reader

Comment by pard68 | Hacker News Reader

I work at a place that has a few very large code bases, we use trunk-based. I will never go back, "what is your git workflow?" Is a question on my list of things to ask potential employers now and the only good answer is "trunk". So much mental load is wasted on these other strategies.

View on HN

It gets even worse — convoluted GitHub action templates that no one can debug, attempting to impose on every newly created repository.

The projects at my company that use the complicated actions with gitflow are slower and less efficient.

When I release a service at my company I just do trunk based ,but I have to redo the GitHub actions initially to save it from itself. Over the long run it saves me a lot of time.

Whenever I even mention doing trunk-based people look at me like I'm an idiot and have no idea about anything.

Same if I say "I'm not doing TDD, because I think it's bad". I've seen so many people claiming to do TDD, but none of them ever actually did.

Trunk based development fits well with well defined sprints and continuous integration but I'm not sure that not committing into a release branch is the best strategy when the releases are kept small and the development continues with full force after the release is formed. In my experience it makes sense to fix found bugs in the release branch and then merge them back - expectation is that these fixes are really minor as the release is not created before mainline development has been validated and is ready for the release. No new features should be added into the release branch, only bug fixes. In such case merging back small release branch changes has not proven to be any pain at all.

I'm not really sure what the mental load is but having gone to Trunk felt like a mistake, I don't know if it was just designed wrong at the last place I worked at, but we have to do more than normal per release, and I'm not a fan of squashing commits, it means I can't just go back to a branch and merge the development branch back into it, I have to check out a brand new branch. I also preferred having "master / main" and "development" because if QA claims there's a bug introduced during the development phase, you can figure out if it's already in the main production branch or if it truly was introduced during development. Which is something you can't really do with "trunk based development" it's like all these people who praise it should just switch to SVN instead?

I think you're mixing up a lot of things.

Trunk-based development also doesn't mean that you are not allowed to create branches.

And you can still check out an older version.

They deleted every branch on merge, and had us rebase for merges. Before trunk based development was introduced, everyone on the team understood what the flow was. Afterwards, whichever developer was picked to cut a release, took half a day to figure it out to make sure they didn't screw up.

I would have rather just used SVN and called it a day.

Sounds like you can't agree on what you're doing and what your goals are.

> They deleted every branch on merge

Wait, this doesn't sound like trunk-based development.

This sounds like a traditional branch-based workflow.

> to cut a release, took half a day to figure it out to make sure they didn't screw up.

Do you remember what was making the process complicated?

In trunk-based development, you ideally can tag a release wherever you're at. Your trunk is always stable and releasable. If it's not, you fix it and then release.

> Wait, this doesn't sound like trunk-based development.

I'm not sure, I just know my employer had a third party managing releases for a while, then the guy who pitched Trunk based dev left, and we were left with people trying to follow the breadcrumbs.

GitHub "deletes" branches on merge, but it doesn't truly delete them - rather, it removes the branch, that's deleted, but the commits comprising the "pull request" are saved and referenced from that pull, so they never go away. They're slightly harder to find in GitHub and may disappear from your local copy, though.

There's a lot of other moving parts to trunk-based, they can only be taught by experience. I've written the tutorial where I have people make mistakes, and then fix them, but the problem is that they make mistakes in making mistakes.

Nothing is lost in git without great effort. Deleting a branch is simply removing the label from the history. Just take note of the hash of the latest commit on the "deleted" branch. It'll still be there and can be checked out in detached-head mode.

You can rebase your development branch or cherry pick commits from master into it.

And if QA finds something, there's nothing preventing testing another release to figure out where the issue is. Git bisect is useful there too.

There are plenty of issues with git, but trunk development isn't really one of them.

If you deploy your main branch on every commit, there is no "development phase". You should deploy more frequently and work on smaller changes. So when your QA (or a user, or a monitoring alert) finds a bug, you are pretty sure that the bug was introduced recently.

Reply on news.ycombinator.com