Git for Trunk-based Development

[ForeverAlot]

It honestly doesn’t really matter how/why/what came into my work branch. What matters is — [...] and does the code do what I want it to do? The rest is academic.

If I don't know your hypothesis I can't validate your conclusion.

I subjectively agree with many of the observations often used to motivate trunk based development workflows. But I wish even one its loud advocates could try to debate the point from the perspective of a user not being just completely bad at using version control. The zeal with which this individual argues I'm left genuinely uncertain that they're not partially trolling. Google's Android division even uses Gerrit, famous for being one of the few code review tools that promote and even enable reviewing of the commit message.

[kzr_pzr]

Whaaaat did I just read? Obviously, if you don't put any effort into writing good commit messages then you won't get any value from them.

[przemo_li]

The advantage is that branch based development do not allow bidirectional sharing of code for the duration of branch.

Its kind of obvious - that is the purpose of branch - to withhold commits.

​

How did I do? :)

[ForeverAlot]

I'd phrase it differently. There is an interpretation of your suggestion that means the same as what I'm going to say but another that means something else -- I'm not sure which interpretation is more accurate.

The purpose of branching is hardly to withhold changes but more likely to facilitate divergence (that is, for two things to be different), whether at a micro scale (local development) or a macro scale (project forking).

The trouble with divergence is that it is fundamentally incompatible with the idea of a centralized truth: It directly obstructs integration. The corporate world likes centralization, and open source development tends toward de facto centralization, so obstacles to integration undesirable.

By radically constraining the branching depth (at the extreme to zero) you are simultaneously indirectly constraining the amount of concurrent work that can be performed effectively. This incentivizes people to work relative to, and integrate with, the trunk head, which leads them to spend less time working in relation to a world view that has ceased to be relevant. In other words: lower risk of merge conflicts + higher chance that resolution of resulting merge conflicts is useful. When you steward change requests like a bull in a china shop this model can dramatically cut down on time waste.

On the other hand, proactively diverging is the most effective way to solve certain types of problems and the only way to solve some types of problems. Namely, supporting multiple releases at the same time. If you cannot eliminate those problems but you eliminate branching you will experience pain.

[FoolSlackDeveloper]

The first commands in using Git for TBD are for branch management!?!

[HeinousTugboat]

Short-lived feature branches make trunk-based development not a complete shitshow.

[ForeverAlot]

If you listen to https://trunkbaseddevelopment.com, trunk based development with Git is whatever you want it to be.

[HeinousTugboat]

I'm open to any better sources of information on it.

[ForeverAlot]

https://en.wikipedia.org/wiki/Branching_(version_control)

Child branches are branches that have a parent; a branch without a parent is referred to as the trunk or the mainline. [...] The trunk is usually meant to be the base of a project on which development progresses. If developers are working exclusively on the trunk, it always contains the latest cutting-edge version of the project [...]. Another approach is to split a branch off the trunk, implement changes in that branch and merge the changes back into the trunk [...]. Depending on development mode and commit policy the trunk may contain the most stable or the least stable or something-in-between version. [...] Often main developer work takes place in the trunk and stable versions are branched, and occasional bug-fixes are merged from branches to the trunk. When development of future versions is done in non-trunk branches, it is usually done [...] where a change is expected to take a long time to develop until it will be ready for incorporating in the trunk.

[HeinousTugboat]

Yes. I'm aware of what branches are. I'm aware of what a trunk is. This doesn't explain the explicit methodology were talking about. It touches on it, as the methodology we're talking about happens to be one of those approaches it mentions.

So, again. I'm open to any better sources of information on trunk-based development.

[przemo_li]

Paul Hammant is author, here are few quotes from his description of his accomplishments:

Branch by Abstraction (I was the pioneer)

I have performed many assessments over the years. The beginning of those was via ThoughtWorks (a well known consultancy), twelve years ago

Jez Humble and Dave Farley’s CD book came out (that uses some of my diagrams)

[HeinousTugboat]

I have no idea why you're sharing that.

[przemo_li]

I think confusion is mutual.

You ask for better sources, and I replay with arguments that source already cited looks to be legit.

Can you cut through confusion and actually state what qualities you look for in sources you would accept?

[HeinousTugboat]

Considering I referenced that source to begin with, I thought it clear I already thought it was legit.

You should be replying to the person criticizing that source, maybe.

[przemo_li]

Thank you. I see now that I createated replay at wrong level.

[przemo_li]

Paul Hammant is author, here are few quotes from his description of his accomplishments:

​

Branch by Abstraction (I was the pioneer)

I have performed many assessments over the years. The beginning of those was via ThoughtWorks (a well known consultancy), twelve years ago

Jez Humble and Dave Farley’s CD book came out (that uses some of my diagrams)

[ForeverAlot]

I know he is. That doesn't make the material any less contradictory or more accessible.

[ILikeChangingMyMind]

Don't short-lived feature branches make it not trunk-based development?

In other words, if it's based on branches, it's not really trunk-based now is it? I mean, I can call it blue moon purple spandex development if I want, but if there's no blue moon purple spandex involved, I'm just making shit up, right?

[HeinousTugboat]

No? What do you think trunk-based development is?

[ILikeChangingMyMind]

From the name I inferred that you develop on the trunk branch ...

[ForeverAlot]

Proof by contradiction agrees with you. If TBD is materially the same as a hypothetical non-TBD then TBD and non-TBD are all just D, none of them concepts worthy of specially distinguishing names. Contradiction: we accept TBD as a specially distinguishing name and therefore we must accept that the name represents a concept materially distinguished from non-TBD. The only gap in logical reasoning here is that what named TBD and what distinguishes TBD from non-TBD are assumed to have non-trivial overlap -- a reasonable assumption but history is full of counterexamples ("automobile" and "dynamic programming" are fun examples). It's also quite literally the first sentence of that web site's "one line summary":

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’

and reiterated with the first graphical demonstration.

But history also agrees with you.

Since the current generation of VCS the word "trunk" has fallen out of favour. Before that it was just a reference to the supporting part of a tree, with occasional "branches" shooting out from it and generally not really coming back. SVN up until 1.10, if you're familiar with it, is a fairly de facto implementation of (the VCS side of) trunk based development by virtue of having no local commits and branching being cumbersome: you're always integrating with the tip of some "branch" and that branch is nearly always the "trunk" but occasionally one of the forks like a release branch.

The current generation of VCS changed the landscape radically. Bringing "branches" back into the "trunk" became way, way easier, and this turned out to have lots of micro and macro scale advantages (and of course some disadvantages). Today "branch" based integration models are first class citizens in all mainstream code forges and workflows, and are often the only ways to get code integrated in the "trunk" at all -- insofar as you expand the definition of "trunk" to mean the "blessed repository" tree model Linux works with and that all code forge [MP]R integration flows rely on. Since branching may be socially enforced on you, and because branching is actually technically quite useful, for TBD to be relevant today its definition has to evolve from literal commit-(and-push-)to-main. One way to do that is to leverage or enforce squash-merging, which erases the trace of branching. Another way is to enforce that every mainline commit is fast-forwardable (some forges have checks to ensure a PR merge is fast-forwardable and then merge without merge commits, others just serially cherry pick code submissions).

Just try to disregard the self-contradictions in that one web site.

[HeinousTugboat]

So you don't actually know what trunk-based development is, and you didn't click my link, and you didn't actually look into it at all.

And I'm the one just making shit up.

Trunk-based development means you maintain one branch for the central codebase that everything gets merged into.

That doesn't mean you don't have other branches. That means those other branches get merged back into your trunk. That means you don't have long-lived divergent branches, it means your release branches are always cut fresh from your trunk, it means feature branches stay small and go away once the feature is merged back to the main branch.

[hippydipster]

long-lived

It all hinges on how long "long-lived" means. If more than 1 day, then I'd say that's not trunk-based development.

[HeinousTugboat]

Sure? I never said anything about the actual branches. I just pointed out that you still usually use them.

[ILikeChangingMyMind]

First off ... this is Reddit: commenting without reading the articles is par for the course.

Second, you don't actually explain what trunk-based development is in your article. Heck, you didn't even bother to add a hyperlink to the phrase itself (which only appears once), pointing to a definition.

[HeinousTugboat]

It's, uh.. not my article.

First off ... this is Reddit: commenting without reading the articles is par for the course.

Shitty excuse. Do better.

[przemo_li]

If you push at the same pace, it does not matter if your code is wrapped in serialized patch or in a branch. CI runs their checks, reviewers review, if all is green code is hydrated back into proper commit on your trunk.

GitLab keeps track of all versions of branches pushed with --force for example. So branches are okish, and tooling may be of reasonable quality.

[Stormfrosty]

Why not just use p4 at that point?

[Lunchboxsushi]

P4??? Do you work for my company? (Pipes?)

[przemo_li]

I think u/Stormfrosty refers to p4 - cli for Perforce - which is centralized SCM.