Git is amazing and essential for my work. However, a vast majority of developers just use the clone-commit-push workflow and can get by. I've also taught CS to younger kids and seen students struggle to internalize the mental model of Git. The learning curve is steep for early devs. Is there merit in having a VCS that has a less steep learning curve or are the benefits of knowing a universal VCS too great (even if you end up using a small subset of the features)
In my experience doing mentorship, a lot of people are taught git in a super rushed way and tend to have the mindset of "here's this incredibly complicated program you will never understand, please learn these magic commands and hope you never get a merge conflict" which isn't particularly useful because they're now scared of their tools.<p>We need to teach tools like git (and some editors!) as their own thing, completely separate to programming languages. Not "now we've written some code, let's put it in git" but "here's a tool called git, let's show how it works with some text files"<p>Honestly - you spend 20 minutes with someone teaching them that git only stores diffs and how that actually works and they leave much more confident and willing to experiment on their own.<p>A plain text TODO list is absolutely perfect for this, because a merge conflict between two steps on a numbered list is completely intuitive and resolvable. "I've got two 4)s now!" "What's the fix?" "I guess one needs to become 5)?"<p>(The CLI and naming scheme is total garbage though - biggest hurdle for non-native English speakers IMO)
I do think git isn't user friendly. I came from perforce and also had a hard time building the mental model. Eventually I read the article about git's internals, and finally got the idea. What's most useful for me was the diagram of the three states (<a href="https://stackoverflow.com/questions/3689838/whats-the-difference-between-head-working-tree-and-index-in-git" rel="nofollow">https://stackoverflow.com/questions/3689838/whats-the-differ...</a>).<p>some of the git's naming was also not intuitive for me, For example, calling the scratch area "index". I didn't seem to have to learn perforce, cvs or svn's internals to use them fluently.<p>but I guess it's a bit difficult to change the current situation. git has become the most common choice. And once the mental model has built, it's not that difficult to use, admittedly I only use a few very common commands.<p>you know the challenge won't be building the version control. for mass adoption, you need a github-like platform.
People might be interested in gitless [0], which purports to be "a Git-compatible version control system, that is easy to learn and use". It appears to be built on top of git, using a simplified conceptual model.<p>I read about it in one of Adrian Colyer's "the morning paper" blog posts from 2016, "What’s wrong with Git? A conceptual design analysis" [1], which summarizes the paper that critiques git and describes gitless. (The link to the paper at the beginning of the post no longer works, but a commenter suggested this [2] instead.)<p>I should point out that I've never used gitless, and I don't know whether it's still maintained, but if nothing else the critique itself is interesting.<p>[0] <a href="https://gitless.com/" rel="nofollow">https://gitless.com/</a><p>[1] <a href="https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-conceptual-design-analysis/" rel="nofollow">https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-c...</a><p>[2] <a href="https://web.archive.org/web/20131230194321/http://people.csail.mit.edu/sperezde/onward13.pdf" rel="nofollow">https://web.archive.org/web/20131230194321/http://people.csa...</a>
Having used SVN for a decade before we all moved to git, I have to say I've never noticed any improvement in our productivity. I.e. the limiting factor wasn't how well you can do a merge.<p>In fact I've probably experienced more cock ups with git due to its increased complexity and insane naming scheme. I mean "checkout"... Completely inappropriate for what it does.<p>Obviously with git you can work offline then sync later on, but that's not something you have to deal with in most organisations.
The different flavors of processes using git are where I see significant differences in how hard it is to use. GitHub/GHE encourages pull requests and force-pushing a candidate branch. Gerrit encourages a staged-commit via "refs/for/$dest_branch". Projects like QEMU and the Linux kernel are much more decentralized and leverage requests to pull from dev repos and email patches ('git send-email'). All of these differences have some impact on how you use git locally and how easy or difficult it is to recover when you make a misstep.<p>Subjectively I think that - the staging area is unnecessarily confusing (mercurial did this better imo), and the overloading of 'checkout' causes confusion too.
My pain points with git are the detached head states (so puzzling) and basically everything that concern submodules (very brittle.)<p>Anything about undoing commits, going back to a specific version of the code is less painful but I almost always have to google for it because that are not daily operations and I can't reliably remember them. Maybe that would be easier if I used a GUI instead of the command line. Anyway, a simplified git with only basic functionality and dead simple error messages AND part of the standard git distribution would be very useful. After all git does a lot of things but I'm using only a core 1% of it. Even after 10+ years I reliably know only the basic clone, add, pull, push, checkout, branch, commit, merge, rebase, log, diff commands. I have to google everything else, even how to track a remote branch. It's checkout -b but Gould I also fetch and pull it before? You got the idea.<p>And it should be about files, directories and branches, the stuff developers reason about.
No. I had to use mercurial at my old job and everyone in the company saw mercurial as an easy and efficient alternative to git - something which I could not comprehend. And truthfully after using the "easier" solution, I'd rather take the code, print it out on punch cards and compare them in order to create the adequate changes by taping the holes accordingly and feed the punch cards back into the computer. Now that I'm saying it and having looked at how mercurial works underneath, it's not far off, with the exception that mercurial creates copies of all punch cards and keeps stacking them on top of each other. I've never hated any version control as much and I've had to use svn in the past. Git operates on a strict and crazy stupid model without adding unnecessary features and advertising them as "flexibility" or "ergonomics". I've worked with juniors who've never used git in the past and in all instances it took them a day at most to figure out how it works.
Git it fine, maybe the naming could be better, but it's just something that anyone can get used to. The real issue is crazy workflows people tend to invent instead of using something common like Gitflow.
But I have to admit that I prefer Mercurial, enforced immutable history makes everything easier. Also, I root for new alternatives like Pijul.
this always makes me laugh:
<a href="https://youtu.be/3mOVK0oSH2M" rel="nofollow">https://youtu.be/3mOVK0oSH2M</a><p>edit: start at 3:00 mins in
Respectfully, version control is not necessarily easy, and even with other versioning tools (they already exist, and some purport to be easier than git), you still have to think about what you're trying to do. I see this attitude a lot with new developers, and it's troubling. Of course git is hard; what part of computing _isn't_ hard? Git is a hell of a lot easier than, say, debugging a kernel panic, or solving a tricky race condition. If the vast majority of developers can't get by without learning anything beyond clone-commit-push, then I truly fear for our industry, because I am thoroughly average, and I have a pretty good idea of what git is up to when I run commands.<p>Git might not have the best interface, and you could argue for different models, but some of this stuff just takes time and effort to learn. This is an important lesson for new developers to learn: some of this stuff is not, in fact, easy, and I don't where this expectation that it is comes from. It reflects a disturbing trend of learned helplessness I've noticed from newer developers. Computers are hard, but if you want to be the expert, you're going to have to figure it out. I don't think we need easier version control, I think we need developers who are willing to learn hard things.
Personally, having used it for over a decade now, once you learn how it works, git is perfect. But it's not necessarily easy, sure. But then there are a lot of easy solutions out there that aren't very good. I'd say it's worth the investment to learn it, but I've seen so, so many developers refuse on the grounds that they simply don't want to. These are the folks who think it isn't good, the ones without experience.
The system has actual complexity. Actual complexity can't be abstracted away without reducing functionality. I think git has a poor/opaque command semantics outside the basic functions and the API could use some work. I think that a new review or "most used/useful commands" and an evaluation of whether the API to accomplish them can be simplified.
Gitless [1] has already been mentioned in another comment here. [2] That makes it easier to use git for those who are not as experienced or haven’t learned about the internals of git.<p>For a different model (and other types of workflows), consider Fossil SCM. [3] Here’s a comparison of fossil with git, and what these tools are a good fit for. [4] I found fossil easier to understand, relatively speaking, and it seems simpler for personal use and for small teams.<p>[1]: <a href="https://gitless.com/" rel="nofollow">https://gitless.com/</a><p>[2]: <a href="https://news.ycombinator.com/item?id=29757043" rel="nofollow">https://news.ycombinator.com/item?id=29757043</a><p>[3]: <a href="https://fossil-scm.org/" rel="nofollow">https://fossil-scm.org/</a><p>[4]: <a href="https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki" rel="nofollow">https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v...</a>
There are definitely warts and sharp corners. Inconsistent cli api. The story for binaries with Git-LFS is still a mess (try using git over SSH with LFS or explain to a newcomer why it doesn’t work). Conflict resolution is still half stupid with very few easy ways of adding better more specialized merge drivers and deploying it over a company. Improvements like ReReRe and similar aren’t well integrated and enabled by default. Instead they are obscure additions so that you <i>can</i> get a less infuriating behavior. But only if you press the right buttons first.<p>The worst aspect of it though is you can’t set it up to be properly centralized so that you truly bless a location which can keep things like branch name policies, distribute hooks to all employees etc. All that has to be built (poorly) on top, with ample opportunity to accidentally sidestep.
Overall IMO, Git is so good that if you have a problem with usability, it's better to work on a wrapper around Git than it is to change Git itself.<p>Maybe a plain English tool that just lets you click through menus to dictate what you want to do. No Git lingo whatsoever. Very rough examples below:<p>1) "I want to save my progress". (combination of git add and git commit)
2) "I want to go back before my previous save." (`git revert` on your last commit)
3) "I want to upload my latest work." (git push)
4) "I want to pull in any new updates." (git pull)<p>...Et cetera. Stuff that's basic enough to satisfy some basic use cases.<p>Then, for anything more complicated than this basic subset, users have to whip out the terminal. The balance between basic and complicated, and too little vs too much, might take time to figure out.
No, we need the power that git offers us for scaling workflows and contributions to large ecosystems. Software does not get less complex over time, but more complex - and we need a system to handle contributions to a complex system (read: large, distributed, multi-thousand developer/files codebase)!<p>git is as simple as possible while being as powerful as possible.<p>What we need is better education! Not only how git works, but also how clean and scaling development workflows work. I've seen too much "Lets just copy the code to the production environment"-workflows in my live already and I do not even have 3 full years of professional experience as a SW dev!
I don’t feel so. Beginners can learn a handful of commands to gets started. And once they started to contribute to a production project they anyway have to learn some additional advanced commands (mostly rebase on top of others changes and conflict resolution). Things beyond a rebase a rarely used by anyone, so most people can just avoid learning those or learn when necessary.
Working with git for 5 years and SVN for 15 before that on teams ranging from 2 to 30 people, I think the problem of collaborative programming just isn't solved yet.<p>It's not that git is special or especially hard. It's that distributed source control is a hard thing to understand, and no 20 minutes tutorial is going to solve that.
I’ve used Git Tower for years because I dislike commandline.<p>Git tower is a “simpler git” that makes many complex tasks safer and easier. But it’s on top of git so you have the full power of git if you do have to jump into the commandline.<p><a href="https://www.git-tower.com/mac" rel="nofollow">https://www.git-tower.com/mac</a>
Maybe just an optional second cli for git that improves usability? If it takes off, switch it to default. Are there any examples of a cli tool with multiple, user selectable cli interfaces?<p>Edit: to answer your question, there’s a lot of value to learning the standard industry scm tool.
There are tools out there that attempt to provide a simpler and/or more powerful CLI while letting you collaborate with others on existing Git repos. Gitless has already been mentioned here, but there's also my own tool (<a href="https://github.com/martinvonz/jj" rel="nofollow">https://github.com/martinvonz/jj</a>) and git-branchless (<a href="https://github.com/arxanas/git-branchless" rel="nofollow">https://github.com/arxanas/git-branchless</a>).
Much of the complex parts of git have to do with rebasing and merging.<p>But I remember that Pre-git this was hard too - the lack of features in VCS systems made it rather error prone. I recall manual 3-way merges and long conversations with colleagues about the right way to work through an SVN merge. Not to mention automated testing was less widespread, so it was harder to catch bugs.<p>Git offers more features here. But the truth is the problem is just hard. Combining changes from multiple authors requires knowing both your tooling and code well.
Yeah. Git is great software, but there's seriously no reason I should be typing multiple CLI commands over and over again as part of my workflow in the year 2022.
I work with hundreds of developers with git, and yes 80% of them only know the basic workflow. The other 20% know a good bit more and can resolve any problem that occasionally comes up. I don't think it has hindered our development at all. People understand how the tool works for what they need, at the level they need. I'm good with that.
Basic git flow operations are straightforward. I taught a few graduates who had no prior vcs experience and they had no problem with day to day stuff. Because git is truly a powerful tool its ux becomes complicated once you need to do something beyond the simple operations.
It might be useful to be able to write git commands in more descriptive way for beginners. “Git add all new files”, “Git commit all files with message ‘foo’”, “Git show history of file ‘readme.txt’”, “Git restore previous version of file ‘readme.txt’”, etc.
No.<p>It was initially hard.<p>But once I read through the excellent Git Book[1] things became very clear and intuitive.<p>[1] <a href="https://git-scm.com/book/en/v2" rel="nofollow">https://git-scm.com/book/en/v2</a>
I used the GIT GUI, and it seems easy enough for me, though I haven't pulled things out of repositories yet, just stage/commit | push to github<p>What's needed is better documentation, nothing more.
> Git is amazing<p>Let me take a wild guess here, bud, you are definitely an american, amiright?<p>Git is shit, it just happens to be better than the competition coupled with the fact of its huge market share.
Since you should not be working in ways that create merge conflicts if you can avoid it I would say a simple distributed disk backup would be enough for 99% of programmers.
Git is complex, which is fine.<p>People take that to mean they need to learn and teach git in intricate detail, and use it in ways that are needlessly complex, which is dumb.