Minimum Viable Git for Trunk-Based Development

I don't think you will need to reclone if did nothing wrong. You can always use `git reset --hard origin/...`, and if that does not work the you definitely did something wrong.

> But in Linus’s own words, Git is “the information manager from hell.”

That git is not the same git we have today, and it was handed over to another person quite early in the development. Although I agree that git ux is sometimes confusing.

> Limit your Git actions ... for peak Git efficiency

I pretty much disagree, if I can give my two cents, read the manual. Git have some really handy tooling that can help with non-git issue (e.g.: `git bisect`). Limiting your knowledge brings no benefit.

I like some point of the text, but overall I don't like the premise. it exaggerate a lot a problem to prove a point.

    git checkout master; git pull

    git checkout -b fb

    git commit

    git commit

    # new changes arrive on master branch
    
    git checkout master; git pull; 

    git checkout fb; git merge master

    git commit

    # "went to the git brownbag and heard about rebase for the first time, 

    # missing that part up front about not intermingling merges with rebases 

    # and not having a good mental model of git

    git rebase master

    # WTF conflict everywhere! rebase sucks

> This isn’t grade school, you don’t have to show your work As you become an efficient engineer, the path you took to get to the final state of a pull request becomes far less important — and is academically interesting at best. You shouldn’t have to show your work like you did in school. Land the feature or bug and move on to the next one. The code speaks for itself (alongside some judiciously placed comments).

> Having granular annotations of all your work is unnecessary, ...

This premise underlies the particular workflow that the posted article assumes, and all the described command+option incantations are directed to it.

But there is another, very different git workflow used by a project we've all heard of, and that is the Linux kernel core code. The trunk.io workflow is unsuitable for Linux due to different requirements. Some of which being:

1. Commitment to support for indefinite future.

2. Large, complex feature PRs.

3. Human review of PRs, by maintainers fully empowered to reject.

4. A low-level programming language, in which subtle bugs are easily introduced.

Also different luxuries:

1. Willingness to put off merge of a "hot" new feature indefinitely.

So, kernel PRs are structured as a linear series of numbered patches meeting the requirement that each step along the way compile cleanly. This is primarily to ease the task of the maintainer responsible for the subsystem involved, and who will have deal with the fallout of bugs introduced by the PR. Example:

https://lore.kernel.org/rcu/

Credential: I have written code for the Linux kernel core, and it was merged, and it was buggy.