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

Trunk-Based Development

trunkbaseddevelopment.com

Post reply on HN
Print view View original

51–60 of 108 posts

Re: Trunk-Based Development

#51

Post by giancarlostoro »

andix wrote: post #47
giancarlostoro wrote: post #42

Earlier quoted context omitted.

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"…

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.

Re: Trunk-Based Development

#52

Post by jfim »

giancarlostoro wrote: post #42
pard68 wrote: post #22

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.

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"…

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.

Re: Trunk-Based Development

#53

Post by [deleted] »

giancarlostoro wrote: post #42
pard68 wrote: post #22

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.

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"…

[deleted]

Re: Trunk-Based Development

#54

Post by c-hendricks »

I've been pushing and using trunk for years. To think someone looked at the graph for git-flow and said "yes please" is madness.

That said, trunk-based is probably not great if you actually do need to support multiple versions of a piece of software simultaneously.

Re: Trunk-Based Development

#55

Post by brirec »

TFA advocates strongly against long-lived branches, which I understand and agree with, but with one exception: major/LTS versions should have their own branch, so that hotfixes can be cherry-picked from main (or, rarely, applied directly to the major version branch.

Re: Trunk-Based Development

#56

Post by andix »

redcobra762 wrote: post #2

Wait so no develop branch? The utility gained by having “what’s in production” and “what we’re working on” as separated feels hard to part with.

If there are multiple environments it quickly gets impossible to keep track of "what's in production" as a branch.

Two possible solutions: Git tag everything that's getting deployed. Or just keep track of the commit hash that is deployed.

Re: Trunk-Based Development

#57

Post by andix »

ToJans wrote: post #20
willsmith72 wrote: post #3

Earlier quoted context omitted.

if that's the only reason for the branch, you can just as easily determine which commit is on which environment with tags

I've been working on my product for over 8 years, sometimes alone, sometimes with a tiny team. I have a mono-repo with one master branch - that auto-deploys to test - and one release branch that auto-deploys to staging. I can hot-swap my staging and production environment with the click of a button. Simple, and it allows us to deploy a hotfix of needed, and we've done some major work on master that needs to be valida…

Sounds neat, but I still think complexity is removed if the deployment is not directly linked to the code repository. For me the code repositories purpose is to build software, and operation is not it's responsibility.

I prefer having a gitops repository that describes the environment. Completely decoupled from the source code repository. If some automation directly from the source repository is required, a CI job can automatically update the gitops repository and trigger a deployment.

Separation of concerns.

Re: Trunk-Based Development

#58

Post by andix »

giancarlostoro wrote: post #51
andix wrote: post #47

Earlier quoted context omitted.

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.

Re: Trunk-Based Development

#59

Post by genman »

pard68 wrote: post #22

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.

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.

Re: Trunk-Based Development

#60

Post by AdrianB1 »

How does this look like when you have multiple active versions of an application? In some cases there are apps deployed in different environments (or to different clients) in different versions and having a single place to make all commits is not feasible.

How do things that have LTS versions in parallel with "regular" versions organize?

Post reply on HN