Comment by ryanbrunner

I'm not necessarily the biggest git fan in the world, but here's some refutations to some of these concerns:

> 1. a branch that stays open for many months, perhaps even a year (for instance, at Maternity Neighborhood)

This is more of a workflow question than a VCS question, and would be true of any VCS that allows branching (i.e. anything remotely close to a modern VCS)

> 2. data is erased for good because someone makes a mistake while using rebase

Data isn't permanently removed from rebasing, you can still get at it with the reflog. If you discovered the problem months later, I suppose that could happen. checkout and reset --hard can irrecobably destroy uncomitted data (as can clean, but that's more obvious and has appropriate guardrails)

> 4. widespread but fine-grained cherry picking leaves the team unclear about what’s been merged and what has not been merged

Overuse of cherry-picking feels like a workflow smell to me, but even still, you shouldn't need to care. Merging the entire branch will work fine if some of the contents have been cherry-picked previously.

> 5. a developer makes a change in the wrong branch because they forgot what branch they were in

True of any VCS with branching.

> 6. a developer is unable to recover a stash because they forgot where they were when they created the stash, or they simply forget that they have work in a stash

I'll agree with you here, I think stash is a bit of a footgun and almost never makes sense to use if the stashed contents are going to live for longer than a minute or two. But this is easily addressable with workflow, don't use stash for anything other than an extremely temporary holding place.

> 7. developers confused by working in an unattached commit, after a botched attempt to revert

Git is generally not great about warning you about dangerous operations or things you shouldn't be doing. Running against a detached HEAD is not one of those things, you'd have to be willfully ignoring what it's telling you to not realize that this isn't a safe thing to do.

> 8. a developer feels the need to delete the repo from their harddrive and clone it again, because the whole repo got into a state that they seemed unable to resolve

I will agree that git could make it easier to say "just get me back to origin, i give up"

> 9. the “blame” command is nearly useless — maybe its because we never know in which branch a given change was made, finding who made a mistake is very difficult

Blame isn't great, but it sucks in precisely the same way it sucks in any VCS. Just seeing who last committed a line often isn't enough information. It would be cool to see an alternative here, but I don't see many better alternatives around.

It sounds like in general, this is more a concern with dealing with branches and branching, which is totally fair. If simple trunk-based development works for you, branches are an unnecessary addition. But there's no reason you have to use all these git features. You can happily have everyone just work against master and never need to think about branches (in that mode the various Git GUIs will probably be more than adequate as well).

I do agree that git tutorials tend to focus on a more advanced branching / rebase focused workflow, and that simpler resources for less technically minded folks would be handy.