Show HN: I made a git rebase TUI editor

Is there anyone else that enforces a simple "just squash & merge everything from PRs into main" across the entire team?

I'm comfortable git fooing w/e is necessary, but ever since we adopted this, git related conversations went to almost zero. It's great.

Yep, IMO this is always the best of the 3 strategies.

The PR is the unit of work, people get too hung up on the PR's individual commits.

Worst: rebase and merge - you end up with your coworker's broken WIP commits all over master, and have a terrible git revert story

OK: merge commit - you can revert, but there is a less intuitive `-m 1` flag (IIRC?) you have to pass into revert, and IMO you rarely need the intermediate history.

Best: squash & merge - you get one single commit representing the unit of work merging in, git revert is dead easy

Also setting the commit message in main to the `{title} (#{prNum})\n\n{prDescription}` format preserves all the good context from your PR and lets you get back to it if you need.

I think "every PR should be a single commit when merged" is a bit too dogmatic. If the PR is logically split up into bits of work that conceptually separate and that compile/run independently, then it makes sense to have those as separate commits. You might argue that those should then be separate PRs, but that's going a bit too far, I think. You can still revert it, it's just have to revert the individual commits and squash the revert commits.

IMHO the guideline should be "clean up your branch and rebase it before merging. Usually that means a single commit, but it can be multiple if that makes more sense to <future person> reading the history".

> IMHO the guideline should be "clean up your branch and rebase it before merging

In my experience, engineers tend to fall into 1 of 2 camps: 'Deep' Git knowledge who routinely dig through reflog and keep backup branches, commit early/often and autosquash logcal chunks until their PRs tell a Story through their commit history. The other side pretends git is p4; and has no concept of fetch vs pull vs rebase. A base assumption that branches are expensive and to be avoided.

I'd like to think probably fall in the middle, but nearly every engineer I've worked with falls on those edges based on the number of DMs i get asking for help after after the rote `git stash; git pull; git stash pop` throws conflict.

My local git copy can be a mess of branch and commits. But I want the main copy to have a clean history that embodies the project. Which means having only the main branch and a few others that represent main activities in flight, each changes can be tied to a ticket, a task, and people, and easily manage releases and reversions.