opsy_

Cool concept, I think it's a good mission & target, too many platforms are just content farms or for keeping up appearances.

And awesome to see what you're doing with Flutter! Looks like Map support has come a long way. Loaded well for me on desktop.

UX feedback - definitely want some more onboarding for the web experience (as others have mentioned), and maybe a smoother intro into the big space. The map view is really cool, good for generating interest, but also a bit overwhelming (where to start?).

Looks like you're onto something.

I think (from working with git newbies) the core difficulty is not understanding the Git's fundamental data structure. If you have computer science training / data structure understanding, once you realize (1) Commits are nodes in a graph (2) branches are just pointers to a specific node, you're off to the races.

From there, I find it straightforward to conceptualize all the different commands. Commit/push/reset/merge/pull/rebase/etc are all just different graph manipulations. There's usually multiple ways to achieve the end graph you want.

If you don't understand the data structure, you have no good mental model and it's just a series of ritual. If something goes off the ritual path, you're in trouble.

Many past confused teammates of mine I've dropped in to help would disagree. reflog and reset, for better or worse, require what seems to be above-average comfort with git.

Can you expand on what that 90% is? I'd guess more the other way around.

Squash merges are perfect to me for the bulk of PRs- atomic test-passing iterations on the working product. Exactly what I want to see in my history. Useful for bisection. Good for reviewing line-based code changes as I can find all the related work for that feature.

They don't seem appropriate for long lived feature branches, or merging into release branches, but those aren't really being discussed here.

I think the implication is often efforts towards "idiot proofing" don't actually improve effectiveness at the end of the day. They simply add something else to trip on.

I'd roughly say that's the case with OPs aliases. Useful if you know what you're doing, or maybe would work with a strict team policy. Otherwise are just going to create more trouble (especially with that force pushing bit in there...).

ETA: I fully support usability! "real programmers just read the manual" arguments be damned.

Sure, unless you bork your local repo enough you need help from a teammate getting your work into a PR.

Not to say that doesn't make for a good learning moment.