I kinda conceptually disagree with approaches like this, for the same reason I dislike the official Github client: it renames some basic git concepts. e.g. git sync. How is this helpful when the dev is put in front of a situation (not configured server, new colleague who is not aware of legit)? Essentially I admire the work put into this project, I just question the goal.
In the general case, I agree. But working with Git you will very probably have to learn what's going on beneath the abstraction sooner-or-later (ie. when I'm working on a team larger than 1 person and the repo becomes a mess). So writing abstraction layers just increases the number of things that need to be learned.
Spending time generating aliases for commonly used commands and scripting commands together to form new (possibly more comfortable) command-wording are both fine once you use the product enough to learn which aliases and scripts would be productive.
Providing a set of these alternatives as a wrapper is a dangerous alternative to newcomers, and has the potential to simply add confusion.
I think these efforts must come after foundational product knowledge is achieved, not before. This effort seems to target those who do not yet have said knowledge.
