imho git is not a version control system but a version control tool. when we started using git trough a system mediating all the functionality trough a goal/workflow oriented approach our whole experience radically changed.
both fork and the intellij ide are great for that, handling the common cases solidly and building up so many convenience functions I can't live without them now, like whitespace aware conflict resolution or single line commits.
Right, git sort of make the easy thing easier, and the hard things harder. I think its a large part why "stable" software branching is unpopular. The difficulty of tracking fixes against their core features over time is extremely difficult without an additional "shim" on top. Even knowing what group of commits comprise related functionality becomes difficult without layering on a commit group id (as gerrit does for example) on top. (AKA i'm looking at $file which has a set of commits for feature $Y, what are the related commits in other parts of the system required to implement this feature). Or for that matter, the ability to group a fix with its original commit (without rewritting public history) is why projects like the linux kernel implement "fixes:" tags which are then scanned by scripts/etc to detect fixes for a given commit group for back-porting functionality. Except in that case its brittle as frequently everyone involved forgets the tag.
Bottom line, git is the VSC equivalent of C, it is quite powerful, but its got a lot of foot-gun moments and requires a lot of human rigor/experience to make it work well. Rigor that even the best users frequently mess up.
both fork and the intellij ide are great for that, handling the common cases solidly and building up so many convenience functions I can't live without them now, like whitespace aware conflict resolution or single line commits.