That's nice, but most of us here are version control consumers, not version control professionals. We need something that has very few knobs to turn because our job is focused around delivering value through other tasks.

Git is highly professionalized. It has layers of modal state. That is built into the operating model. It is made for Linus Torvalds, a professional merger of code. If you are using all of those commands "almost daily", you are a professional code-merger too.

This is such a strange attitude to source control as a developer. It's literally the most important tool a developer will use second only to an editor.

And again, maybe git is the wrong tool for you, that was kind of my point, use cvs or svn it's much closer to what you seem to want.

Some other things I rank above version control: Programming language compiler, runtime, etc. Email and similar communication tools, phone, chat, whatever. Web browser for documentation, Q&A, etc.

Some sort of basic version control is definitely important.

If it was so easy, the decision of what SCM platform to use isn't part of the developer teams, rather IT.

I was replying to this part of your comment:

> Usually my response is if you use something daily, and you know you lack the skills to use it effectively, why don't you improve your knowledge and seek out training or education?

Seeking out that training would be useless since I don't use git enough.

> Maybe git isn't the right tool for you?

Git is definitely the tool for me. It's better than any other available tool for my situation.

Why the hell would I branch more? Just to get better at git? Sorry, I'm sorry that I work on a small team! Maybe I should go back to CVS?

Stop gate keeping.

> Why the hell would I branch more? Just to get better at git? Sorry, I'm sorry that I work on a small team! Maybe I should go back to CVS?

I have multiple branches on the go in a one-person project. I find that very useful. But if you don't, maybe you should go back to SVN? Using git without merging between branches seems like you're making your life complicated for no gain - like using a distributed system framework to run a single-node system.

I have multiple branches, we use gitflow (well modified). This isn't about branching, it's about what happens in the edge cases and how difficult git is when things go wrong.

The comment I'm replying to said "branch more" as if that would solve some kind of problem with edge case complexity.

That comment likely assumed merging between branches was the "edge case" you were hitting; the general principle - do whatever it is more often, so that the edge case becomes routine - is sound. I found gitflow horrendously overcomplicated so I can imagine it might introduce some edge cases, but I'm honestly struggling to think what they might be - in my experience as long as you never rebase/cherry-pick/squash, frequently have parallel branches, never rebase/cherry-pick/squash, and frequently merge, there aren't actually any edge cases in git - as long as you remember to never rebase/cherry-pick/squash.

This is just retarded.

You don't want branching and you still think git is the tool for you? Compared to say svn?

Honestly, use svn, its the better tool for your use case.

You don't have to use git.

Don't gaslight me by saying you don't need gits main feature and then suggest I'm gstekeeping, I'm not, youre welcome to use git, just don't complain about your lack of ability to RTFM.

Nice ableist slur, on brand.

I use a modified gitflow. The article and this thread are about how when you get into trouble, git quickly becomes complicated. It’s not about branching being too hard or whatever you turned this conversation into in your head.