Commit graph is just a data structure. Sometimes it represents a "history", sometimes other things.

Personally, I like it when project's repository represents the history of the project rather than the history of random things developers do on their machines, but you do you.

I am thinking of remote. Edits before pushing OK with me (they ate equivalent of recloning and redoing anyway)

Remotes aren't equal either. Sometimes the remote is my other machine, sometimes it's a fork on a forge used for producing CI artifacts.

It's a good rule of thumb to consider shared branches to be append-only, but not every remote branch is "shared" and, as with any proper rule of thumb, you can always find exceptions.

Ok I amend to what I think I really mean: don't edit history for anything deployed to prod (or released to public or customers) already.

There is history that has already happened (e.g. what has been merged to master) and history that will happen (e.g. unmerged pull requests).

You probably shouldn’t be committing things that are broken…

You should be committing things that are broken all the time. Git works great as a persistent navigatible undo buffer, and you should commit every time you're in a state that you might want to return to.

Squash all your temporary commits before you push.

No, you don't commit trash to a public branch, EVER, if you can help it. Your commits are as perfect as you can make them, and that does not mean squashed in a trash compactor. That means one logical idea per commit, compiles and works as perfectly as you can make it. Use stgit, and this is easy. You do not break git bisect. No need to squash your trash in a trash compactor. Your standards are lower than mine, not higher.

This is likely saying you shouldn't save a word document that contains spelling mistakes.

With tools like GitHub Actions and some added constraints, it's not always possible. You literally need a commit to trigger the CI workflow and it starts to trash your branch. Besides, aren't we all familiar with git commit -m "typo"?

> With tools like GitHub Actions and some added constraints, it's not always possible. You literally need a commit to trigger the CI workflow and it starts to trash your branch

I'm with you on your overall point, but as a side note: this state of affairs is so tragic. It's been normalized for there to be test suites that nobody can run except the CI runner, and the only real way to run all the tests is to have GitHub do it. It's pure lock-in, and it's very sad that everything's moved this way.

CI actions should be a simple file of "action: command" lines, with at most a separate file that describes when given actions should run. All actions should be runnable locally just as easily as they are in CI. Or if the actions are so complicated they need a complex-ish environment, that environment should be the kind of thing you could run locally too with your hypervisor of choice, without having to think about it. But every VCS host that has an actions/pipelines product is financially incentivized to encourage you not to set things up this way, to preserve their lock-in.

Commit yes you absolutely can. Merge to trunk? Probably not, depends on your strategy.