Don't want to sound old school, but git works perfectly fine. The learning curve might be a bit difficult, but afterwards everything makes sense. And let's be honest, you just need a few actions (pull, add, reset, branch, commit) to use it in 95% of the cases.
If you work in a team you need to understand rebasing and squashing, unless you can convince team to never use these features. A lot of people are religious about rebasing, "clean" commit history. But it's pretty much incompatible with several devs working on a single branch. I.e. when you work on something complex, perhaps under time pressure, git habits bite you in the ass. It's not fine.
Years and years ago I worked on a team where linear commit history was required so every time a merge happened you had to manually rebase and push to Bitbucket. I put a PR in halfway through the sprint, rebased it a dozen times as everybody else's work got merged, and had nothing to show during review because nobody bothered to check mine and the only coworker I had in the same physical office was out on vacation.
When I interview for new roles I always make a habit of asking how work gets done to avoid shops that engage in these types of shenanigans.