The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour)

Resisting GUI's is not a good idea. The trick to learning is to always have `gitk --all` or a similar viewer open in another window.

Also instead of `git add` / `git commmit`, use `git gui`, but for most other things stick to the CLI.

Having said that use a GUI, github desktop is terrible. It tries to make things easier and as a result takes you away from git's standard terminology, so it's impossible to understand what it does.

Something I found teaching other people is it helps a lot if you haven't learnt SVN before.

I've used git for ten years, at half a dozen organizations (I'm a consultant/contractor). I have accepted that it's what we use now, so I use it. But...

Git is the bad boyfriend of the developer community. If anything bad happens it was your fault. If you ask it to do something and it does something else, it was your fault, and also you are stupid. If you ever make a mistake, you will be punished for it with a long drawn out cycle of embarrassment. No matter what happens, it was not git's fault, it was your fault.

Good software is not like that. Good software is the opposite of all of that. Git is the industry standard, and I have just accepted that we aren't going to get anything better, but whereas it might make sense for the Linux kernel dev community, it is not good software, and I suspect that it's not just the UI that's the problem.

Lots of non-devs also have the problem of wanting to have multiple people edit the same document, track changes, and occasionally merge them. I would never recommend that they use git, and I see no evidence that it is ever spreading beyond the dev community in any significant way. There's a good reason for that.

> I’ve used it since GitHub was in beta

This is the root of the author's issue. As another commented, git is born in a world where computers are mostly offline, people are highly technical, and will spend a lot of time manually crafting the messages they will send to the numerous collaborators. It is an alone-first software. What the author wants (and exactly what I want as well: https://news.ycombinator.com/item?id=25002318) is the complete opposite: a system that knows it's connected to other people, where changes are instantly propagated and easily visible, where the differentiator between "branches" is not "what computer does it reside on" but "who did it". That's the model behind GitHub, after all.

git is complex because it's working with a very complicated model that is not in line with what most people expect today. As I said in my other comment it seems that fossil works with that flow, but I haven't tried it. However what is sure is that it doesn't make sense to ask git to become what it fundamentally is not.

EDIT: There might be a solution with wrappers. When you look at git-annex assistant (https://git-annex.branchable.com/assistant/) you can see that the right amount of abstraction can provide something closer to what we expect... but at this point it's not git anymore, so we might as well start from scratch.

“Git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.”

— Isaac Wolkerstorfer

http://twitter.com/agnoster/status/44636629423497217

I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward.

That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is.

Git is hard because it precisely models the complexities of concurrently modifying source code on multiple computers. It explicitly models all of the concepts and operations that are relevant in that domain - branching, merging, my local changes, the server that my local branch is kept in sync with, rewriting local history, rewriting public history. Can you shoot yourself in the foot? Absolutely, because this stuff really is non-trivial. Could it be made easier? Yes, by limiting what operations you're even allowed to make, and streamlining those (c.f. git flow).

Arguments against git being 'too hard' seem to fall into these categories:

* It's not actually hard.

    ** You don't understand it. Everyone else is fine with it. You just haven't spent the time to understand it like everyone else has.
    ** Ok maybe lots of people don't understand it. They just haven't spent the time to understand it like I and others have.

* It is actually hard.

    ** You're not intelligent enough to understand it, but everyone else is.
    ** Ok maybe lots of people aren't intelligent enough to understand it, but that doesn't matter because I am and so are others.

IMHO the more intelligent response is:

* If people think it's hard, that's a problem, and we can use our understanding / intelligence to help make a version control system (layered on git if that works) that doesn't require the depth of understanding or intelligence to work with - for everyone.

I've worked with thousands of developers and my experience is that even the brightest still make mistakes when given sharp tools, and when you're just trying to get your job done but you've tied yourself into a knot with distributed tools that try to help you deal with merges of turing-complete text, you can have a bad afternoon.

I'm hoping darcs / pijul / something else a bit more 'friendly' becomes popular and those who want to concentrate on their code and not their tools can get some time back.

Git's problem is 3 fold:

* It is too powerful

* It is not prescriptive

* It has horrifyingly bad UX/semantics

Git exposes all of its complexity at installation, which means that you are able to do any amount of damage from minute one. There are no cascading layers of abstraction that map onto the user's comfort level with git.

Git also doesn't prescribe workflows. Overtime, people have come up with standard workflows, but there are too many of them and they all have different mental models. The issue is that most of these workflows are only marginally better/worse than each other and don't necessarily provide additional functionality in any sense. It would be much better if there was only one way of doing things in git. It would make things marginally inconvenient for many, but the marginal loss of productivity would be more than made up by a consistent mental model and the increased reliability of the 'canon' workflow.

Last, and certainly my biggest complaint is the terrible UX and the semantics they convey. It is almost as though the creators went out of their way to have naming schemes at odds with natural language.

I hope someone builds a keras-like tool for git. Interoperable with the tensorflow (v1) that is the git underneath, but exposes a much easier and in most cases feature complete set of abstractions that work for 99% of its users.

I cannot live without git, but somehow I still "hate" it.

A very lovely thing is text editors without "save" button. You change the contents of your file, close the program and that's it. The boundary between "changes in memory but not yet saved" and "changes already saved to the hard disk" is an obsolescence and does not really make sense today.

Git adds not one, but three layers upon the idiotic save button. Now, after saving your changes, you still need to add them, commit them, and finally push them. What I want is less stuff, not more. All my keypresses and states of files at any moment should be automatically saved forever, without action by my part. Then, if I want, I can "tag" a state of the file tree to refer to it later. The perfect git interface should only have two commands: "git init" and "git tag". All the rest of saving and bookkeeping could take place automatically.

Git is one of those technologies where it's super important to get a good grasp of how to internals work. Once you got that, it get easier to answer git questions for others or yourself, and to read the documentation or man pages, as you know what is happening.

With how software devs use git, it's 100% worth it to read a good book on it.

The directed graph isn't the problem. I think people can deal with the idea that other people have a different version of the code from them. The parts that are hard are the horribly inconsistent commands and the complete mess that is how the staging area interacts with everything else.

With most software in general, we usually think the very definition of "easy to use" is "a high portion of users and potential users find it easy to use."

Somehow with git, lots and lots of developers (and non-developers too, but let's just consider developers) can show up and say "i've been writing code for years, i've been using git for years, I get by, but I find it pretty confusing and hard to use," and still have people saying "no, you're all wrong, it IS easy to use."

Like, how is that even logically possible? To insist that software really is easy to use even when a large number of people don't find it easy to use, is an interesting metaphysical stance.

The UX design of git is horrible, granted. To me this article read as "I want a GUI", while having some good points.

For example on knowing branches having local and remote versions, "because why would they"..they would because if they want to use the tool effectively then they need to know how it works. This is the same reason I learned how to use git prune. Would I ever use it on production code without a backup? No.

A GUI is not the solution, because a GUI can never equal the expressiveness and capability of skill combined with a parcity of input provided by the command line. If it did then the complexity of using the GUI would be just as hard, or harder, than the command line interface. However, there are many who do not need more than basic Git. Those can be served by a simple GUI, or by pre-provisioned Git aliases with documentation of what those aliases do.

I still dislike a GUI because I have had a number of people come to me to fix things on a team that used SourceTree and accidentally did something horrible, either because their finger slipped or because they didn't realize what they were doing and the GUI made it too easy to do it.

All powerful tools should have a simple version and a complex version. Git is extremely powerful, but has no simple version for everything.

What helped training new people was telling them to think of git like a complex copy operation across computer boundaries, and explaining the commands in terms of that. Once they've gotten comfortable with the basics then you can explain how it differs from copy (and it does, greatly).

Agree. The argument “well this is a hard domain so tools will be complicated” I don’t buy at all.

The complexity is mostly accidental and down to poor UX choices and legacy.

As an example: why is the centralized binary storage system (LFS) using http when git isn’t? The answer: because it’s not really part of git. Congratulations, you now have two sets of auth and network issues instead of one.

Git is design damage by Unix philosophy. It does one thing and lets programs interact via command line. The problem with that for a tool that humans use is people want consistent simple UX, not unchanging UX. Scripts want unchanging UX, don’t care about consistency or simplicity.

Git is simply too low level for most users. As an example, it doesn’t even know which repo is the central one! It’s so low level that repos are repos. Yet few of us would consider our local repo to be equivalent to the blessed central repository and it would certainly help with many operations.

No it's not.

If you're a dev/SWE you should be able to grok a semi-complex CLI API to control software... but the further the world gets into "everything as UIX" and "everything has to be 'easy'" the more we stray from incredibly powerful, immediately available CLI tooling.

I know of too many highly-paid people who literally refuse to learn the CLI `git` or `docker` and limit themselves/skillsets by doing everything through the comfort of a UI. To me, it's a mark of laziness.

Git isn't "too hard"... it solves an incredibly complex problem. It has a lot of capability and complexity under the hood to deal with all of the craziness of distributed development paradigm.

I fully agree.

I particularly think about this because I had some conversations with people from the open science community. It's really often where I'd like to tell them: "This problem, you really want to use something like git. Although... it's kinda hard to learn."

There's a lot of workflows outside of software development or from people who develop software, but for whom software development is not their primary thing, where a version control system would be really useful. But our current state-of-the-art version control system isn't very well suited for that, particularly not for people who have a limited capacity to learn things or might only use it every now and then.

As usual, in the discussion there are a lot of folks who's advice/opinion boils down to "rtfm" and "it's not the tool, it's you!"

I found working with SourceTree to be a good fit most of the time, after learning via command line for a bit. It keeps me from having to look stuff up, and is much nicer navigable than command line imho.

My problem with such answers is not that I don't want to have to memorize git commands (with all the flag and sub command variations, git config entries etc.).

My problem is that the guys from the discussions about.. ... blender, vector graphics programs, Xcode, rider, gcc, apple notarization command line tools, brew, pip install, the python3 standard library, emacs, vim, the terminal and ssh, my Synology's time machine configuration, my book keeping and tax program, Django library, the c# standard library, my insurance policies, my smartphone, smart home and my Samsung smart tv, ... ... all said that it's not so hard to memorise these few simple steps or commands, and that I should rtfm.

Not sure how useful of a retort that is to the criticism "X is too hard to use".

What I often experience (see also a lot of comments here):

Some people, however smart, try to force git to do something in particular, without asking first "How can I do x with git" (I don't think I ever had a use case where stackoverflow didn't have a solution for).

Then they end up with a borked repo, everything is confusing (because it should have almost never been in this state), angry at the tool they abused so badly.

Git is solving complex problems, and it obviously has certain idiosyncrasies. But just because you think the developers chose poorly, doesn't necessarily mean git is terrible in the first place (might also be true though, but please prove it by showing a better alternative). I heard mercurial has a lot of fans, but I had a terrible time cleaning up behind colleagues though - everything was easy for them, but they did not know what they were doing and why it was bad. The git branching-workflow helped a lot there.

Often the obvious solution of an outsider is not really a solution.

Could git have named some commands better? Yes, of course. If you don't know what git is doing internally on a checkout, it makes little sense. But this is being worked on.

I would argue that if someone comes up with his very own perfect distributed versioning system intended to be super intuitive and simple, he will in the end also build in complex constructions that make no sense to outsiders that didn't participate in thinking about the complex problem these concepts are trying to solve.

There is an answer to the perceived bad UX of Git: Gitless.

https://gitless.com/

Is has already been mentioned a couple of time in this thread, but it deserves a more prominent mention, because IMHO it's a really interesting project.

The author(s) analysed git UX shortcomings and tried to learn from them. For example, Gitless aims to align well its concepts with user's intentions. There have been written research papers (and a talk is available online) about their methodology and Gitless design:

https://spderosso.github.io/oopsla16.pdf

https://www.youtube.com/watch?v=31XZYMjg93o

I've trained multiple teams to use Git (which means I've been their on-call tech support) and I agree the learning curve is tough. However I argue that the value added is so high that the initial curve is worthwhile. I usually start by explaining that Git was made by kernel coders who like low level access, so git hides nothing from you and provides a very generic solution that works for almost everyones use case. GUI tools will cover you in simplest of scenarios, but it's a matter of time until you need to do something marginally complex and are left hanging out to dry. I advise not using them at all because the details they hide are the only thing that will help you understand the advanced features.

Once you're over the hump the system is very intuitive. I liken it to awk or sed which beginners often find incomprehensible, until they understand what the tools do at which point they become simple. There's a lot of good resources out there and StackOverflow has almost every question imaginable already asked and answered.

As with many things, the solution is complex because the problem is complex. Managing code history in a distributed manner, handling conflicts and allowing cooperative coding is not an easy problem to fix.

Having said this, Git doesn't make it easy by the terminology and concepts that are used. And also the inconcise UI (you use git reset for a lot of very different actions, some harmless, some very destructive) doesn't make it easy for a newcomer. Who will often resort to just remember oneliners or look them up from a manual without knowing what they actually do.

What really helped me in understanding Git was to understand the mechanics of the database on an abstract level. Commits and how branches/tags relate to them. If you understand that commits (not branches) are the tree and the branches just post-it's you put on the commits and can rearrange as you please everything becomes much more malleable. Once you discover commits are hardly ever deleted/lost, but just the post-it's are moved (which makes the commits invisible), things become easily recoverable and fixable. Also not using code, but cats[1] also seems to greatly reduced the complexity of learning Git for me. Visual tools like Ungit[2], Tig[3], or plain Git log[4] help to see the commit tree and attached branches and gives an idea of how the data is manipulated.

There is also the Gitless[0] project which tries to redefine the UI of Git, without changing the data format itself. It offers a different look at the same repository and more clear and dedicated commands/concept to perform certain tasks. And since it just uses Git itself underneath you can seamlessly switch between it and Git without issues.

[0] https://gitless.com/

[1] https://girliemac.com/blog/2017/12/26/git-purr/

[2] https://github.com/FredrikNoren/ungit

[3] https://github.com/jonas/tig

[4] git log --oneline --decorate -50 --all --graph --remotes

Git's plumbing is simple and intuitive.

Git's UI has grown organically and is still not great for common tasks like undo, however they are working on it and it is slowly improving. For example, they've just added a restore command which should make it simpler to undo changes (git restore filename):

https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things

Things I'd also like to see improved:

Undoing things locally should be very simple and intuitive - perhaps restore will help.

Conflict resolution when changes happen on the same line, so that there are fewer clashes on rebase/merge.

Git log should be compact and pretty by default

Git push should push tags as well by default

Deleting tags etc on a remote has a really weird syntax - git push origin :tagname git push --delete origin tagname just feels really odd instead of using the tag command.

There should be a simple way to add all changes and commit - e.g. git add --all && git commit -m "Message" if that could be git commit "Message" that'd be great (probably not possible but at least a flag on commit would be nice). I have an alias set up for this. I like being able to add files separately to a list then commit too, but that is far rarer, most of the time I want to commit all changes.

A blessed workflow - perhaps this isn't possible but having one workflow would make it simpler to move between repos and simpler. Many projects seem to have settled on main=production with short-lived feature branches rebased off main and edit as necessary locally before sharing on main. This works well for us at my workplace.

git start - a guided tour command which steps a user through a typical workflow and shows them the commands they need (probably about 5 commands initially), and tells them the difference between local and shared commits (fine to change vs never try to change).

These are pretty minor gripes though most of which can just be fixed with some aliases for commands - I'm pretty happy with it and much prefer it to what came before.

I loved using Mercurial. It provides such a nice UX and it is very intuitive to use.

It's a shame that github was created and not MercurialHub and now we are stuck with Git.

Now even Atlassian abandoned Mercurial.

I'd say rather 'Version Control is hard'. It should not be that technical.

The very notion of versioning terrified quite a few non-technical but otherwise very proficient office users in my experience trying to sell them the benefits of VCS. Even GitHub or Jira would be considered "for programmers".

On so many occasions I would fail to convince such users to embrace version control in their workflow, even with some Tortoise-like GUIs.

Immediacy of copying their work folder or document and appending a date or "-final" tag to the name is all their busy minds are ready to adopt. And it does make sense, no blame.

This just tells that current concept of Version Control is indeed serving the very specific needs of maintainers, not much the mundane needs of normal users. Thus the complexity of the CLI in the name of flexibility.

My expectation is that Version Control should be mostly transparent to user. It's just some internal housekeeping. On a basic level it's just a Save/Save As operation with very much versatile project-level Undo and Open. MS Office's Track Changes is a familiar workflow for many users, perhaps a similar approach could be adopted for Change Management in broader and less proprietary context.

In Git's parlance, Mr. Version Control is still a plumber that offers users some porcelane sinks, yet user's projects need to live in a whole house with already functioning works and appliances.

I want to believe that Version Control will one day become a basic amenity, not an "exotic" feature that needs constant attention.

The git CLI is too hard. I'm the "git guy" at work and can always fix people's problems and never have to resort to delete and reclone. But I don't use the CLI. I use magit. Using git is just doing operations on the DAG. Git's DAG is the most elegant implementation of a version control system that I've used. But the CLI is awful. It makes no sense. Other Git GUIs make this even worse by adding yet another layer on top of the already bad CLI. What you need is a new porcelain, like magit.

Since my experience with Git is much less (too much solo work, so you don't get exposed to the same scenarios as team developers do), I'm now having to handle new situations in my Git use.

The biggest problem I face is the conflicting information of how to do a certain thing. The other biggest problem is that my need at one moment may be similar by slightly different to a situation/question posed on StackOverflow, and so I'm left to guess if I can take the answers and work from those... or if I will end up in a worse or weird situation by following them.

It's very difficult to even discuss situations in Git, because the smallest details can be a deciding factor in choosing what next step to take. It reminds me of analog and digital electronics... sometimes you must be very precise and know exactly what you're doing, and sometimes you can just approximate. Knowing when to do one or the other takes lots of experience.

To be fair I have seen a company who had a dedicated git guy who was committing, merging, pushing whatever on behalf of the developer after nth time some of them screwed the repo completely. When I started learning how to use I had people telling me it is difficult, but were not able to explain why they think it is difficult and I started learning having this in mind and that made it unnecessarily complicated. I think once you know all the terminology and a few workflow scenarios, then it is very easy.

Not Git is which is hard. Distributed systems are hard! So there is a really hard problem to begin with. One specific example from the post to delete a branch. There is no way to simplify that if you want to make a truly distributed system.

> I feel that nobody should need to have spent so much time in a terminal to be able to understand those things.

True! Too bad the author doesn't use a GUI just because they are "a Linux nerd". Magit contributed a lot to my Git understanding. And for those who don't use Emacs, I believe there are some other good GUIs out there (e.g. gitk). They allow to have a visual representation of what's going on, they show available commands, etc.

Here is another approach:

Back in the bad old days before git I was in a 20-30 person company that used Microsoft's SourceSafe. For anyone unfamiliar it had a basic library type structure where only one person could get out (lock) a file at a time.

Now the obvious downside is that when someone goes on holiday or simply forgets those locked files can become blockers. The solution to that is to have an admin unlock the files, which was pretty easy, then a merge, which is basically what happens by default with git.

The upsides of the library approach were a) that I could scan the top directory, and quickly drill down to see who was working on what. b) I feel that walking over to someone's desk and asking if they were still working on a file produced some great back and forth, that was where the magic of collaboration actually happened.

I think the "just Google the answer" mentality to overcoming Git's obvious shortcomings is really problematic. For example, we once had a junior developer run into a problem with Git and before asking anyone else they went off and found an answer on Stack Overflow that solved a similar but slightly different problem. They naively ran the suggested solution without reading the documentation and wound up deleting our entire remote repo. Fortunately we were able to recover everything...

For context, we used SVN successfully for years before that without ever running into a similar situation.

Git is like piano. You can play chopsticks or Berliotz. Are piano's too hard? Unlike other tools out there, git is utterly transparent on the mechanics above and under the hood. This coming from someone who has gone trough the gauntlet, MS Visual Source Safe, ClearCase, CVS, Subversion, Razor and (gasp) Perforce.

Git is indeed hard, but it’s also far too easy to screw something up, sometimes irreversibly. Before I became much more competent with Git, I used to spend far too much time trying to figure out how to undo or fix things. My strategy eventually became “just be extremely careful with everything”. That said, I have learned to judiciously use GUI tools such as those built into IDEs, but I have had to make conscious efforts to understand the commands they’re using underneath.

Let’s also not forget that version control — and any kind of synchronization — in general is hard.

Git should have been a library to create multiple compatible CLI/GUI implementations. The Git CLI has become too bloated to use. It will take a month to read through the manual and learn all available commands. A well-designed VSC should not take that long to learn.

Git is a beautiful system with an ugly UI. Semi-random English words used that seem to explain a different action than they really do, especially mixed with --arguments that sometimes make a command do something entirely different.

It also lands squarely in the middle of making user-friendly analogies and allowing you to go "directly to the metal". The commands are a super leaky abstraction and often you need to simply memorize what they really do, no real deduction possible.

Git is different from TFS/SVN. I wonder if Bitkeeper and other DCVS solved the user friendliness part. Not every programmer nowadays is a greybeard, nor do they need to be. If Git can be made easier to use without displeasing greybeards, it should (or: please don't make it into a useless toy).

That being said, I think Git's command-line is becoming simpler -- I don't use GUIs since SourceTree failed to make me notice I was in the middle of a merge.

Is it git that's too hard, or is it that version control is too hard? I suspect that it's the latter.

That is, version control is difficult and git is a powerful tool that exposes that difficulty and the many (complex) ways to approach version control.

Darcs has a great UX. Please to use and still powerful. It inspired some small parts of the Git UX like the `--patch` mode for `git commit`.

The author of Darcs, David Roundy realized that Git was going to dominate so started a "best of both worlds" project that used the storage format of Git but the UX of darcs. That was called `iolaus` and never really launched as a usable project before was abandoned:

https://github.com/droundy/iolaus

That's still my preference for what a rethink of the Git UX should be.

By this point I've learned many of the pain points of Git. By having experienced Darcs, it's frustrating to teach Git to newcomers knowing the experience and ease of use could be so much better.

More context:

   * https://mark.stosberg.com/blog/2008/11/darcs_vs_git_annoyances_push_-dry-run.html
   * https://mark.stosberg.com/blog/2008/11/darcs_vs_git_annoyances_pushing_specific_patches.html

I was doing a proof of concept work on transferring a mercurial repo to git, following the official documentation. I then used push --all to copy all the changes to the shiny new bitbucket server (corporate decision, we didn't had the choice...) then wonder why all the tags were missing. Apparently, by default push --all doesn't push the tags...

There is GIT (the system itself) and there is the CLI. While GIT itself is very elegant and clean, the CLI is the exact opposite. In my experience people who struggle with GIT mostly struggle with its CLI and do a lot better with a graphical interface, given they understand the concept of distributed VCS.

The article is about GitHub writing a new porcelain in Go that matches GitHub's semantics better. And I think that's the key point: the main git porcelain was hacked together by the Linux kernel team to match their workflow.

Now, I have strong disagreements with GitHub's semantics. I want code reviews to be per commit, not per branch, and I want an easy way to stack up a bunch of commits, make changes each of them as I get review feedback, and then merge a whole range at the bottom of the stack as I they are accepted.

Right now I do this by living in git rebase -i, putting a little tag in each commit message to name what remote branch it should be pushed to, adding an exec command in my rebase -i that extracts that branch and does the push, and then working with wiring together all these remote PRs on all these remote branches.

Git is a well designed, well thought out sophisticated tool.

Please read through the first few chapters of the official git tutorial[1]. Once you get the mental model right, git is immensely simple to use.

I highly recommend sticking with the command line.

Github on the other hand, was designed to solve a whole different problem.

FWIW if you're on Linux (unsure about Windows and Mac), I happen to have zsh and oh-my-zsh[2] installed. They add a ton of incredibly useful git aliases. So for example, seeing a tree view of your project is a simple `gloga` command. Helps by not having to remember the equivalent full command that gives you the same result.

[1] https://git-scm.com/book/en/v2

[2] https://ohmyz.sh/

Git is hard if you allow it to grow into a monster via neglect. Having a clear, consistent process for branching, reviewing and merging code is virtually 100% of the battle with any vcs.

We use a very basic GitHub PR squash+merge process. One other person must review all code and it must pass checkbuild. Simple enough. To avoid horrible conflicts we have daily standups where we make our work areas known so these concerns, dependencies and blockers can be handled asap.

For us, a PR/branch that lives longer than 48 hours is rare, so things don't have a whole lot of time to get fucked up. If we know we are going to be working on something longer term, rebasing after every merge to master is strongly encouraged.

I just use gitkraken and have never thought about git again. I often have to help out cli-power users that have hopelessly destroyed their branch and do the equivalent of 12 operations with a few clicks and drag and drops. My job isn't to play with / debug git issues, it's to deliver customer value.

I use cli for pretty much everything else. I don't get the fetishization of the cli, it's just another interface. For source control operations are much easier to grok as visual operations and I advise all new developers to start with a client like gitkraken and delve into the cli if they really need it (in most cases they don't).

I don't think git is hard at all, it's lightweight and elegant, and quite frankly, extremely logical to understand.. Sure, the syntax can be hard to grasp at first, but that's a reasonable price to pay for brevity tbh.

If you think commandline git is complicated, try to make a symbolic link or an rsync backup from the commandline.

Commandline is not easy, it is powerful: that's why we use it, that's why we love it.

We don't have to know exactly all the command parameters except one or two: if need more, make a script/an alias or use --help or man; there are many ways.

As long as we keep it powerful and can script it, it is good for me. Actually, most of the time I use a GUI for git, because that's what the tool allows and as a human I feel it more practical. But sometimes I go beyond the GUI and use some very specific commande to get back the raw power of it.

I'm still using Mercurial, and I don't regret that decision. I only regret that everyone else appears to have STOPPED using it, so that I am isolated in my own little world away from community like Github.

> (And it does not have to be something separate than Git. It should maybe be just a really powerful abstraction built on top of Git.)

GitHub drooling now that their extinguish end-game will actively be welcomed by the community.

I've never understood why so many pro developers around me speak so highly of git. I get that its powerful but why does it seem so convoluted?

I'm not a git expert. Just a developer who likes to get things done with the least amount of effort. I use a combination of git cli, vscode git extension and SourceTree to do everything I need to do. I hate that I have to use SourceTree given its many flaws. Yet, the way that it lets me visualize branches-merges history and do interactive rebase is just unmatchable.

Also, never understood why Github Desktop exists or what people use it for.

Whenever posts like this come up, the amount of controversy they always generate I take as proof of git's difficulty. If git were easy, it wouldn't need to be constantly defended by supporters.

Git is a tool that asks the user to engage from the perspective of the internals of the tool. In order to understand what is happening in git, you need to understand how changes move through the system.

There's a good reason for this! Git is really worried about automatically doing something you don't want and losing data or mangling code. One way to deal with that is to teach users how many decisions git is making, and then if there's any doubt git will refuse to make a choice and tell the user to sort it out.

The approach is both sensible and demands a great deal from individual users. Especially users who are newer to the system and, in their inexperience, more likely to get into bad states and be uncertain about how to get out. I suspect that, on a practical level, more changes are lost by users needing to reset --hard because they don't know what else to do than git would use by making a few more choices. But there is value in the idea that when that data is lost its the user who chooses to lose it! I don't want to lose that.

I think there's a huge hunger for a more automatic DVCS, one that offers fewer options and makes more choices for you. There are obviously a lot of other options out there at various stages of development and I have no idea what they are like because, like many experienced programmers, I'm quite comfortable with git!

I briefly looked at Plastic SCM and really liked it (https://www.plasticscm.com/). It's design is much more sensible from the get go, and it has a great UX + UI. If things being Open Source is so important, then I dream about a world where gitlab acquired Plastic SCM and makes it open source!

I hate git with a passion and am very happy with svn. Even my business users can learn and use TortoiseSVN in one session.

This feels similar to the no/low code idea. Saying you want to make it more human and doing so without losing some of the power and crispness of it seems hard if not impossible

From the perspective of a tyro, I find it very difficult to catch on the terminology that git uses. There are simply too many concepts to understand and remember. For example, why is rebase so much more complicated while merging two branches seems fairly straightforward. Even after using it for quite some time, I almost always mess it up. In my opinion, git should abstract a lot of details from a regular user to make it more friendly and easier to learn.

If you cannot explain it, you don't really understand it.

First of all, I'm sure the author knows more about git than I do, so I don't wanna come across as trying to lecture an expert. But I do feel that his main point misses the mark. It seems to be centered around the idea that a lot of reasonable people are surprised by things git won't let them do (or, more accurately, strongly advices against doing). The problem is that most of these things are only "reasonable" from the point of view of someone who hasn't thoroughly thought through what a DVCS has to do. A lot of the "reasonable" questions are raised from the point of view of "this is a tool for sharing changes to code". But that is just a nice side-effect of what a DVCS aims to do – it is not the goal.

I too have had to clean up git mistakes of collaborators for years, almost all of them rooted in a misunderstanding of what git does, or carelessness (amplified by git's arguably less-than-stellar naming conventions). But is there really any chance that any DVCS will be "easy" (or "not too hard") for someone who hasn't thought about and internalized what the goal of a DVCS is? It seems a bit like a person who only ever spreads butter complaining that knives are needlessly sharp.

PS: My greatest success rate at converting people from "just hammer git commands until my code is on GitHub" to actually understanding what problem git tries to solve, and how to interact with it, has been from Mary Cook's wonderful Git from the inside out (https://codewords.recurse.com/issues/two/git-from-the-inside...)

The author says that the problem is:

> I have some changes. I wanna share it with Jon and Johnny so they can tell me what they think. And then maybe they can add their ideas. And then we can have a merging of our ideas, and eventually test out if it works, and have it out there and ship it.

Fundamentally this is the problem. If this is your use case, then git is not for you. But this is not really a use case because people have not thought through the complexity of what a "merging of ideas" means.

If you want the simplest version of this, just use a google doc -- you get history, collaboration, all of that. It's a fine tool for what it does. You don't have to worry about backing up checkpoints or anything, or sending around multiple drafts for revision and comment -- all of that is directly included.

For people who need to manage versions, in order to use git you have to acknowledge that you can no longer treat your version control as an annoying little checkpointing thing that magically shares stuff, because that model ALWAYS breaks in reality; anyone who has used CVS knows this. Anyone who has had to do branching in Perforce or SVN knows this. You have to understand how it is implemented under the covers.

Fortunately, git is really really simple under the covers -- there's no deltas or change records, just an efficiently stored snapshot of the entire tree, and when you commit a change, it stores an efficient snapshot of the entire tree. The previous snapshot is still there, as are all previous snapshots.

Then it's just a matter of learning how each of git's commands map to changes to the underlying data model.

Only one link https://git-man-page-generator.lokaltog.net/

The git plumbing is awesome and robust. The git porcelain (aka the cli UI) is optimized for people that are deeply comfortable with command line tools and setting up aliases for things they do a lot and/or scripting things together. I'm OK with it and I memorized most of the commands and flags I need regularly.

Most experienced developers are used to this. Most other version control systems have similar issues. I started using Git 15 years ago by means of running it against subversion via the git subversion plugin. That forced me to learn a few things in a hurry and made me realize just how limited subversion is. I got into that another five years earlier by migrating a code-base from cvs to subversion. 20 years ago, using cvs was considered acceptable as a version control system. Neither of those were particularly user friendly but they were a lot simpler to use because there was only so much you could do and even less that worked well enough that you should do it (like branching and merging).

Git UIs as attempts to make git user friendly seem to be mostly not very successful. I always struggle how to do even basic things with git in IDEs like Intellij or VS Code because they seem to insist on coming up with their own terminology. I mostly ignore that stuff and do it on the command line. I use a simple mac tool called gitx as a ui for viewing diffs and writing commits. But I push, rebase, merge, etc. from the command line.

Github is the exception. It's awesome as a web based UI. And it's the reason that git became the dominant remaining version control system against a long tail of things like darcs, mercurial, and other decentralized version control systems and an even longer one of legacy/obsolete ones like subversion, cvs, etc.

None of those are any better in terms of UI and at this point basically all of them are magnitudes worse when it comes to being properly integrated into other tools. So, that kind of is why Git 'won' and why the barrier to entry for new tools is very high.

But git could definitely do with a rethink of the porcelain at some point. I think the issue is most of the interesting problems are on the plumbing side and hence most people get stuck in protracted wanking around diffing algorithms rather than actually fixing the UX issues. Techies are just not good at UX. By the time you 'get it' well enough to fix it, it's no longer a problem for you.

I've never shied away from embracing complexity in trade of more power and/or flexibility wherever it brings me value.

I run UNIXen as my desktops (Linux, Solaris, BSDs) even if it takes more understanding and tinkering than OS X, because in the end it's more powerful. I run my own email infrastructure instead of giving it up to gmail, because it's more flexible and powerful and I'm in control. And so on.

But git? What a curse it is. I identify with the comments that liken it to hazing. A lot of pain to be inducted into the club, just for the sake of pain. No gain.

I've been using source control systems for many decades and all of them have been tools that provide their value without being intrusive. Never have I had to fight a source control tool or take backups before every operation like with git.

So that explains the hate, from my perspective. git came along and polluted a perfectly good tool space with something extremely user-hostile and didn't add any extra value (no, git did not invent distributed source control so that's not the explanation; I've been using distributed source control since the mid 90s and today I use mercurial wherever I get a choice).

A theme that comes out again and again in the comments here is that in a technical community, complaining that a tool could be better is a reliable signal of a dumb/lazy worker.

At the same time, many tools could actually be a lot better and if we all magically traveled 50 years into the future we would find all these better tools and see that it wasn't only the dumb/lazy people who used them - it would be everyone. For example, how many people write applications in low-level languages like assembler today? Not many - but at one point that was the only option and anyone who complained about it would be labelled as a lazy worker.

The signalling aspect of this certainly distorts the discussion, but bear this in mind:

It is simultaneously true that git is a tool with a poor interface and a bunch of warts AND every aspiring developer should do the work and learn it in detail so they can use that knowledge to signal to people that they're not lazy and/or dumb (and the lazy/dumb people - even knowing this - will not do it, so the signal works).

You know what's really interesting? I think this is a left/right brain dichotomy here. I learned git on my first software dev job and learned it _deeply_ by executing on the command line. This infused a deep, practical understanding of how the distributed system worked.

Also—I'm a language guy. Picking up languages, reading in other languages, just "clicks" for me. But math? Pffft. Forget it. I barely scraped myself out of college with my CS degree intact.

I learned Russian and Spanish just for fun!

My theory is that git is learned like a language and retained like a language. Tools like "GitKraken" are just "Duolingo" for your brain. They don't replace immersion learning when the stakes are high. (Not claiming this is the "best" way to learn, but boy is it effective)

Anyway.. I've never really struggled with git, nor with it's advanced notations. But algorithms? Hard, math-related thinking? That's an every day struggle. Perhaps the author's opinion is geared from the perspective of more functionally-paradigmed thinking?

Git is as hard as you make it.

It's a bit like raising kids. You don't bash them with the intricate model of the world that you have developed at an age when they are not ready for it. The police are the good guys, the criminals are the bad guys. Sure, there are places where it's the other way around, but you don't really go about telling them about corrupt police departments or authoritarian governments when they are three years old. The goal is to build a mental model that is a good and usable first approximation of the world that they live in. There will be plenty of time to get into the details and edge cases later on.

Similarly with git, you can very much give someone a good and usable first approximation that lets them be productive with it quickly, and then go deeper as needed.

If, however, your normal git workflow involves using a lot of git features that were originally implemented to solve certain edge case situations, then this is not really git being complicated. It's people making it complicated for various good and not so good reasons.

I've used and introduced as CTO hg in the past because I think it's easier to understand. less confusing and there are extensions for many (special) use cases. Every org dropped it and I've dropped it more than five years ago because every example on the internet uses git, no one wanted to learn hg and that friction was higher than the benefit of hg to me and orgs.

Git is simply one of the tools you must learn to master as a modern software developer. If you'd say "but source control is simply too hard!" you would probably be asked to leave the building on the first opportunity, and I'd say rightly so. A craftsman that doesn't master his tools is a shoddy worker. I don't see how that is different for software engineers.

Also, modeling your tools around "how people think" is the wrong approach. Tools should be modeled around the process flow, and people should be taught to think in terms of that same process. "How people think" should not be leading, the process requirements should be leading.

> I have some changes. I wanna share it with Jon and Johnny so they can tell me what they think. And then maybe they can add their ideas. And then we can have a merging of our ideas, and eventually test out if it works, and have it out there and ship it.

So, no. You don't "have some changes". You have a piece of software source code. That source code is worthless without running it (or shipping it). And once you start running it, people (including yourself) will start to rely on how it works right now. If you change how it works, you need to

a) be able to explain what changed from one version to the next

b) be able to revert to the previous version if the new one is problematic

The first rule of source control is that it's not about sharing: it's about auditing your changes. From there you can start to work out the details, about sharing the source code with others, about developing multiple features in parallel, about maintaining multiple versions off the same codebase, etc.

But in the basis, git (or any vcs) is not a sharing tool, it's an auditing tool. Sharing is secondary.

> >How do I delete a branch?

> and then I have to ask them:

> > Well, what do you want to do? Do you wanna delete a local branch, and then just get it recreated when you pull again from the same remote? Or delete the remote tracking branch? Or delete the remote branch?

I struggle to think of a reason why you would want to delete a remote tracking branch only. Maybe as part of a bulk cleanup if your tab complete list gets too cluttered and you want to remove ones that don't exist on the server, but that's an advanced topic.

So for most users, it's "Do you want to delete your copy or the server's copy"? This is just the kind of user focused language that the author highlights as simple and complains git makes it hard to think about.

The git UI sucks. I'd rather we were in a world where mercurial won for that reason alone. But it didn't, and I gave up that argument years ago. But the example given feels more about DVCS in general, which removing the distributed part feels like throwing out the baby with the bathwater.

While I generally disagree with what he's saying, I do think that most of his points are understandable, even if not persuasive to me.

Except this one:

>> I will get you to think about a directed graph or as operations on a directed graph

> No human thinks about that!

Well, that's not wrong, people don't usually think like that, but people also don't usually think about possible specimens living in some forest during a hike, or the odds and the reasons why a given storm could become a hurricane when they read about it in the news, or all the most likely reasons why a given body part might be hurting. No, those are thought by zoologists, meteorologists and physicians, respectively.

With that in mind, I see thinking about graphs and other areas more complex of version control as being, similarly, part of the job and the cognitive load of software engineers.

In short: People don't usually think like that, but, in my opinion, thinking like that is part of a software engineer's job, so I don't see an inherent problem with that.

But what's the alternative? I dislike Git for its complexity, guns helpfully cocked and pointing at your feet, obscure commands etc. but still feel it's the best of the available tools.

I really wanted to like Mercurial. UI seems much nicer. But there's no support from major tools. Cmdline tools are slow on startup - not Mercurial's fault as such, but affects me as the user - in particular waiting for the cmdline prompt showing Mercurial branch etc. Learning materials are a bit confused - so many different types of branches, a lot of popular materials seem out-dated, etc. Everyone in the whole world knows survival Git, very few know anything else.

Long story short, if I were setting up a collaborative software project (be it commercial or FOSS), I would reluctantly but unwaveringly choose Git. Truth is, 95% of the time it doesn't get in the way of getting work done, and the remaining 5% is not worth going against the grain on all the above points.

I didn't see a mention of Sublime Merge, by the authors of Sublime Text. It's thoroughly good and free-as-in-nagware to try.

Git is still too hard to pretty much every non-developer workflow, and wouldn't omnipresent versioning (but not at the full filesystem level; with branches and explicit merges) change the world for the better.

I have often thought about what a truly intuitive, simple, easy, user-friendly VCS would look like. Git is fine for programmers, but what about non-programmers, or student-programmers? Would it be possible to make a VCS that my mother could use without sacrificing too much power?

One thing I would give up easily is decentralisation - a centralised model is more straightforward, and, for better or for worse, most people use Git in a centralised fashion.

Conflict resolution is one of the hardest version control tasks for beginners. Maybe it could be made easier by making the VCS AST-aware for more legible diffs, or by automating conflict resolution altogether with CRDTs or OT.

There were some interesting, very different takes on version control envisioned for darklang:

https://blog.darklang.com/how-dark-deploys-code-in-50ms/

I can say git is dragging our feet all along. I don't remember subversion being acting this unintuitively.

I always hear problems that someone couldn't clone a repo as the repo got big and it's only 2GB in size and random blogs tell you to run git config command to fix which isn't even available on Windows if the user is only using a GUI tool and the other solution is to edit a .gitconfig file which Windows have problem handing files with dot at the beginning, commits creates a conflicting branch because I pushed before I pulled files I didn't even touch, and push randomly fails on people but it works on a retry etc etc.

People just figured Linus' work is a magic bullet to everyone's problem but I guess people jumped on it with no evaluation and we're all bleeding from this.

We need a better tool than git.

I miss tools like bazaar when they mention their goal was being user friendly which is important.

OK, we got a powerful and flexible version control system which some people find difficult to use. The solution is to build alternative wrappers/frontends (command-line or GUI) on top of it, which present different takes on the best user interface. The author finds local/remote branching confusing? One could build a small `git` command wrapper that will hide it and have more straightforward branching commands. You can think of current git as an assembly language of version control and develop wrappers/compilers for high-level VC languages of various flavors.

Starting from scratch and building a dumbed-down version control system for simple users vs. kernel developers is not the right approach, IMHO. As they say: "build a system any idiot can use, and only idiots will use it." Or you will end up incrementally adding more and more advanced features to it.

Torvalds understands something extremely important about software, and that makes him uniquely suited to make deep, foundational, bedrock software projects.

The machine world is the machine world, and the human world is the human world. Git was built to match the problem space and not human intuition. This is why we still use it while no one who doesn’t have to uses cvs or svn anymore.

Of course it’s not easy for the beginning to intermediate coder to understand. It wasn’t written to solve that problem, it was written to support Linux kernel development.

What’s nice about git is that the interface stabilized years ago. It’s not going anywhere. Alternative git interfaces are everywhere, but only one is really any good, Emacs’s magit. There’s nothing stopping you from writing another one.

Or just do what the rest of us do when we encounter historically-entrenched ugliness. Learn its eccentricities and move on.

That's a lot of points for an article that didn't say much. also, I question the author's experience of 10 years if he considered those hard questions to answer.

But point well taken, we want an easier and more usable tool. I definitely think the learning curve for beginners needs to be shaved off somehow.

I think the best thing you can do for yourself as a git user is to learn what things are easily to reverse, what things are hard to reverse and what things are irreversible.

In general as long as you have a clean remote you can fuck around without worry because you can just throw everything away and start over.

IMHO, No it's not. This isn't Dropbox or FTP. Conceptually, some of thing things Git does is are not easy concepts to distill into a couple commands to achieve what Git sets out to do. Sure, you can use it in a basic way, but that's not the point, Git is incredibly powerful tool.

In fact, on my teams, I make sure people use the CLI and not use a frontend wrapper so they grab the concepts before they go "willy nilly" into the comfort of GitLens or another UI that masks their understanding of what they are actually doing.

You should always understand the underlying commands you're executing. Rebase, merge, branch, etc. aren't easy concepts to understand and they aren't easily conveyed for beginners in a graphical tool.

Exactly! It is too hard for me. I'm webdeveloper mainly full stack since 2009. Since the begining I used SVN but after few years transited to Git. I never had any training where I could put my hands on many use cases and situations of git. I did some tutorials and watched some youtube videos, also checked on f. manual. I can do pulls and fetches, I don't recognize strict difference (I try this or that). I am able to work smoothly inside my feature branch and can do pull requests to any other branch. I can resolve conflicts. But other stuff is out of my reach - and I now why. Because it almost never happens in day to day job. And if it does not happen I don't remember the procedures to perform.

I have a real question (not trying to start a flame war). Truthfully, why do people think git is hard? Seriously, as programmers we do many, many things that are really hard. Things like thinking about abstract data structures, understanding concurrent processing, etc. I can understand not knowing it and how that frustrates people, but I genuinely don't understand why people are afraid to just dig in and learn git. Some of the commands I admit are confusing at times, and I have to look commands up, but I don't think I've ever looked at git and said, this too difficult for me to understand.

Honestly, I would really love to know, because I have to teach git fundamentals in a couple of months at work.

Meta comment: this thread has over 600 comments after 10 hours (one comment per minute) - most of which are of the form "I use it this way", or "here's a better way to do that" - thus proving the point of the article.

It's not hard nor easy. Git takes time to learn and understand properly, like a lot of things in technology. Sure, it's internally very complicated, but it does a great job at providing a sane interface to use it. I think the problem is really in the approach that a lot of git users think of git in the first place. It's seen as a requirement rather than an aid and solution to a set of very tricky problems. The actual point of VCS in general can't be summed in a sentence. I think the appropriate approach here is to recognize that it will take time to see the value of and learn how/why git does things the way it does.

I don't agree that git is 'too' hard, but I do think the author made a great point how a lot of complexities with git stem from its distributed nature which arose from its origins in the Kernel development community. Most people who use git simply don't work on anything even remotely close to that scale, and will basically only ever be working from a 'source of truth' master/main branch.

Understanding the origins of git and how it compares to the modern Github-is-git workflow really propelled my understanding of the tool and why some of the things that seemed weird to me actually make a lot of sense with that context.

Part of the problem with git is that too much of the metadata around a repository (config, heads, remotes, branches, tracking etc) is stored in separate little files somewhere in '.git' This critical state of the repository should itself be version controlled so changes can be examined and rolled back in a clean consistent manor. Git has a reflog so experts can go dig around for the stuff you lost. Imagine if git were more like 'nix'. (that last statement might not help my argument for some of you ;-)

Read the various stores of git blunders in this thread with the idea in our head about how it would be different with this change.

There's some core concepts that need to be grokked to not feel stupid, like commit, rebase, pull, fetch, merge, revert, and more important, when you use them and when you don't.

There's a learning curve in understanding version control, not just git. The git manual/handbook covers all of this, including reasoning, but the way that the industry carries on is as if git is a side dish that accompanies the main meal. Git is not like that, it's been here 15 years and deserves investment like a programming language, or a text editor (see Vim/Emacs).

I disagree that you need to understand the internals, but it can prove useful.

I think it boils down to Git solving a complex problem in a very elegant way. Other version control systems try to simplify the problem, but the result tend to make some part of a dev team more unhappy than git does

I get frequent questions from other developers (not all junior) on how to fix weird messes in git they've made which is fine if you're just learning but at some point it's like seeing a developer who can't type properly, just kinda why subject yourself to so much extra work to avoid learning to use something. Yeah it's kinda hard and not very exciting but it's powerful, a part of pretty much every software related dicipline and we don't have an easier modern alternative right now. I don't get the stubborness around it.

I find it a little confusing, especially when trying to do something a little unusual.

For example, I had a git repo on a web host and wanted it moved to another host (they cloned it easily enough), but then I wanted to make the cloned repository "authoritative", but I after several hours of looking for an answer I finally gave up. I was able to clone the new repo to my local machine, but I couldn't push changes to the new repo, and had to log into the new host using the console and commit changes there, which was still looking at the original repository.

Can't remember the times I've had to google "Pop commit and move to another branch", for when I accidentally commit to `master` when I meant to commit it to `feature-branch`...

I agree that Git is hard, but with the right explanation and a good graphical GUI like SourceTree, I've gotten non-technical team members up to speed on it!

I think the hard part is explaining the distributed nature of the tool, where your branches are completely separate from the branches on the server. When I'm explaining it, I usually talk about branches as work streams, and merging branches means merging work together.

What kind of things tend to trip people up when explaining Git? Maybe I should write a blog post or something...

I still mourn the loss of Bazaar, Canonical's early distributed VCS.

It was much simpler to use than git, but still gave you the important functionality. It had a clean Python implementation. (Actually it was the first open-source project I contributed a patch to.)

Alas, like many Canonical products, it was a good idea that failed to take hold. While git is technologically superior (more features, better performance), I like to think there should have been space in the world for a more user-friendly VCS to co-exist.

Earlier this year, I wrote a blog titled 'A simple Git workflow' https://www.iwriteiam.nl/D2009.html#30 and now that I am rereading it, it does not feel simple at all for a first time user. And note, this simple workflow does not even use branches. It was only recently that I found the two global settings that makes lives for first time users so much easier. Why not make them default?

I disagree.

Your workflow should be pretty simple.

Go to a feature branch, make changes, add/commit changes, push up the branch, ask for a review, merge the request. This workflow is independent of the technology and can be implemented by git or anything else. There's a handful of commands involved.

When you're newer and make more mistakes, or if have more advanced needs, you can use other commands like rebase, reset, cherry-pick, bisect, etc.

Git is far simpler than the algorithmic crap we get whiteboarded on, or maintaining a complex web app.

Yes I agree there are issues with git, and this may be a great solution!

But the github cli tool being pushed on github as the defacto user interface feels like internet explorer all over again.

And this media flurry at the same time as the switch on github away from ssl links is disheartening, frightening, and just another example of Microsoft's fingerprints on this product and our ecosystem.

Combined with the recent DMCA takedown fiasco... I cannot wait until if or when web 3.0 decentralization makes these problems non issues.

I've read this as a rant about why we should want a fancier SVN. Unsurprising coming from someone working at Github, but hardly representative of what git was made for and can actually do.

Centralisation is easier, but generally the wrong solution. Git is distributed by design, and most of the difficulties come from that. Github makes git easier by making it centralised, and that makes it easier to use, but actually make it bad in some other ways : the the recent youtube-dl debacle.

I completely agree that git is hard to learn. I had used both cvs and svn before moving to git, and it took me a looong time to really get git. And it wasn't a case of command line vs GUI - I prefer the command line.

I wrote about some of the things that had to click for me here: https://henrikwarne.com/2018/06/25/6-git-aha-moments/

The main problem I run into with git is communicating with my teams about editing history and how they shouldn't.

Particularly on teams that like to keep main clean and avoid reverts and merge commits in favor of rebasing. Thankfully my current team likes to keep their PRs clean and main is whatever works.

That and merge conflicts, especially on a stale branch. I use cli for most things and Intellij's merge tool for merge conflicts because I can get a clear view of what's what.

I LOVE how the article used highlights.

And it seems that all the posts on the changelog.com platform use highlights. I wish more people and articles did this. I actually built Kontxt (https://kontxt.io) so everyone can add highlights to websites they visit or own, but it has more interactivity with inline comments, polls, mentions, tags, and smart navigation.

Please everyone, highlight everything! It's so useful!

Git is the single-most reliable tool that makes the most sense to me and gets out of my way 100% of the time. Knowing how it works is imperative to using it effectively - you wouldn't drive a car if you didn't know how to use the steering wheel or pedals, would you?

What a ludicrous article. We're dumbing ourselves down to pander to the most common denominator.

Keep in mind, the author of this article is affiliated with Github. This doesn't bode well for Github at all.

> "I will get you to think about a directed graph or as operations on a directed graph". No human thinks about that!

Maybe they should try? Just because I can describe with words what I want to accomplish doesn't mean the implementation will be simple. I'm all for making abstractions over git but the underlying model is extremely robust.

I think the UI layout could use some adjustment though to be fair. Reset is one of the worst offenders in my opinion.

Git the ideology is great. Git the tool and UI are good for power users, but are abysmal for beginners and non-technical folk.

Github has done a lot to make it better, but even github is confusing for non-technical people.

We need some merger of tools like github with everyday applications. In the same way OS's provide a file picker, github should make a "branch/file picker and committer" so that regular people can contribute to things stored in git.

I've been programming since long before GUIs existed, and Git baffles me. We use Subversion, it's a lot simpler and does the trick.

Subversion integrates beautifully with third-party apps: Windows File Explorer (Tortoise), Qt Creator, Visual Studio, macOS (Cornerstone), Help & Manual, etc.

A GUI interface makes one more productive. I can right-click on a file or directory in Windows, and display all the change history at a glance.

Git also sucks when someone in your team drags their feet and doesn't use it properly. And when your team is mostly made of non pure comp. science background who have learnt SQL on the job, trying to get them to stick to git is really difficult. There almost needs to be something in between that satisfies this kind of intermediate technical ability and interest.

I think Atlassian could come up with something suitable.

Well if you want to know how to unpush, here's how. You can also use this to just uncommit locally if you made a mistake, too.

>git reset --soft HEAD^

That preserves your work, but it uncommits it. You can now make changes, re-add files, and recommit. If you want to destroy the last commit instead, replace --soft with --hard.

>git push origin +mybranch

The plus sign forces an overwrite of the remote branch.

I've used this technique countless times, for years. It works fine.

I use vscode with Git Graph. It gives me a clear understanding of everything, allows me to manage branches easily, gives me access to every command I need, and even allows a great diff view between any commits.

Merge conflicts are easy to solve now and I never get lost in the complexity.

I use cli tools for almost everything, but Git Graph and vscode solves git for me. The only command I run in git cli is git clone or git unit.

It's about time we should get off of git to something new by creating a bridge like "git svn" for easier migration that's targeted at more general audiences than hackers of the hackers only.

There's no way kernel devs would want to change the course of git to target different audiences. It was meant to be as their tool which is a niche and we should've known better.

People often blame git for being hard, but did they actually learn git at some point, or do they just monkey-type commands hoping for it to make sense?

Since I read the git book, I never once had to rm -rf + git clone, and I've never been stuck in any situation.

It's the same thing as people blaming regexes or CSS for being hard without reading full courses.

Last weekly I had consolidated all my notes on git and made a series on git in my site https://bobbydreamer.com/44-git-theory-1

Initially I had thought one page would be enough. But as I started, it went on and on. Still there is much more. At a point I had to stop.

> Resisting GUI's is not a good idea.

Git supports many different development workflows and it isn't reasonable to optimize a GUI for all of them. As a result, GUIs for git always feel cluttered and overwhelming or under-featured to me. I'd much rather them focus on making the CLI more intuitive than spend time on yet another git GUI.

I would say that people only need to initially learn: checkout, add, commit, push and pull. Those operations cover most of a devs daily workflow (for most companies I've worked at at least). Anything else can be figured out/taught as needed, it's much easier to learn a new concept when you have a use case specific to you.

I see many comments saying that Git is still the best SCM system, which I agree with. Git can simultaneously be bad, and better than any other option available. To me Git has always seemed a little bit awkward. It works well when it works well. I think it it solving a hard problem. I don't think Git is the final solution though.

As someone who has lost data due to a bug in Git [1], I don't like how it works.

[1]: https://www.reddit.com/r/git/comments/9b80ks/how_to_restore_...

I disagree. Git definitely has a learning curve just like all tools do. But as an engineer, you should learn it accordingly.

And honestly, once you understand the concepts of git, you don't need to remember the commands, you need to search for it. Just like you search for all sorts of problems in whatever language you're writing in.

I use a straightforward workflow, protecting master with PR, with some alias to create a new branch, pull and push, pick, and log.

I never used the GUI. It seems really complex for what we decided to be our workflow. Git is a complex software that can solve complex contexts, but you can limit your daily workflow to a few commands.

The article ought to be titled: 'Distributed VCS is a lot more complicated than centralised VCS'.

And I'd agree.

You can learn SVN in five minutes. Git...you're looking at the docs still, after using it for 2 years.

I agree that git is awful for beginners and casual users but the warts become insignificant after you get accustomed to git. I honestly prefer an industry wide solution where everyone is aware of the warts than having 100 different solutions where each tool has different warts.

Mercurial was a pleasure to use, but the "whatever Linus does is great" crowd had to kill it.

The analogy with (La)TeX is strong. That's also very powerful, written by a luminary at the bottom level (Knuth as opposed to Torvalds), and with a command line user experience loathed by most. GitHub etc. are supposed to be like Overleaf. Why aren't they?

I'm an academic. I use git for some projects. I would love something between git and Dropbox: Dropbox's ease of use and automation, but git's ability to add branches. I've struggled to persuade co-authors to use git. There is too much to learn.

I completely disagree. There is the very serious danger of replacing an elastic, very simple to learn system which is battle tested in real battles (like kernel development) with a fancy GUI or CLI that can only deal with 10% of the problems I can solve with Git.

I agree with this statement; I am, however, not a Git pro. I have mostly used SVN and am very comfortable with it. Whenever I jump on a project that uses Git, I have to ask a million questions about how to do things. I am just having trouble groking Git.

How to use git is difficult to teach to people who are not familiar with version control. I think sometimes this community forgets that version control is not common knowledge outside of the tech sphere.

A graphical client like Sublime Merge makes it easier, but not easy.

Why refs are not versioned themselves? Sometimes I miss an option to "checkout" state local git env of my somebody else I am trying to help with git.

This would also keep history of branch changes on the server side, making force pushes trivially revertable.

I've found that when I've seen people struggle with git they're doing something really weird that they shouldn't have been doing in the first place.

Learn the core commands, keep yourself disciplined, stick to a workflow, and git is fine.

I don't mind hard, if it can justify itself. But after having struggled with git for years now, I still can't find a single thing that it does better than Subversion did, only with a lot more seemingly superfluous steps to do it.

I went from typing everything out to using aliases via Oh My Zsh.

https://github.com/ohmyzsh/ohmyzsh/wiki/Cheatsheet

I have to disagree. Got is as hard and complicated as you want it to be. For the most common usage (commit, push, pull, checkout) it's very, very simple and easy to grasp. This is like saying "computers are too hard".

An example issue: the interactive `--patch` mode, by far the most powerful paradigm for interacting with diffs, is available for `git stash [push]` but not for `git stash pop`. The CLI is full of inconsistencies of this kind.

Just learn it. Its model and (once you know) the commands is actually very elegant.

Git is a distributed version control system and does not add complexity beyond what is required for the task at hand.

This is a highly technical tool not for the average person, but it is neither designed for nor used by the average person.

> "Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it?" - adding a revert commit, rebasing and squashing it together with the original is the standard way. I know, it may be painful, but back in the time when I used SVN that was only possible by asking the local sysadmin to run a bunch of hacks on the server.

Also, people must cope with the fact that "undoing" something that has already been pushed isn't just like typing Ctrl-Z in a text editor. If you're the only developer of the repo then no problem - rebase like there's no tomorrow and nobody will complain. If you work on the same project with other people, then you must take into account that someone may have already pulled your commit and added something on top of it, and you can't simply "undo it" without breaking his/her git tree unless you rebase. It's not a limitation of the tool, it's a common solution to a common problem in versioning systems.

And the confusion about local and remote branch just vanishes once one figures out that there's a local copy and a remote copy of the repo, and those may not necessarily be in sync - of course, it adds a layer of complexity, but it solves a lot of other problems when collaborating with multiple people on the same code base.

I believe that git is really the best version in system around. The way it works may have a bit of a steep learning curve, but once you master it you realize that its entities and functions (commits, branches, tags, reverts, rebases, submodules etc.) are really the best way to solve the problem of distributed software development without adding any more complexity.

The only argument one could make against git is that its cli is sometimes confusing and inconsistent - checkout can do tons of things, from resetting a file to the original version to create a new branch; some branch actions can be done through git branch, some through git checkout, some through both; you can pull --rebase, or you can run either pull or rebase alone as commands, but one pulls things from the server, the other is used to manipulate commits on the local copy - unless you want to change the commit message, and in that case you use git commit --amend.

I agree that the cli nomenclature is sometimes very puzzling. But let's really try and separate the discussion around the technology and its implementation (which is, IMHO, absolutely brilliant) from that around the user interface (which is sometimes inconsistent, but it's also the result of adding more and more functionalities on top of relatively few existing commands).

Before git won there were some competitors with better command-line, like: http://wiki.bazaar.canonical.com/BzrVsGit

The author hasn't used the likes of cvs or the commercial systems much, I think? :)

I mean, git is hard, but it's a big improvement over what we had before. And so will whatever replaces git be, whenever it shows up.

All of those questions in this blog post comes from people who don’t even look into documentation or try to find answers (e.g. learning), and someone is even hiring them.

It’s a sad state of a world we live in. :)

Been working on solving some of these problems with – https://github.com/chriswalz/bit

As a user who knows absolutely zero Git, I often fumble around for a good 20 minutes at times trying to figure out how to just install someone's project for consumer use.

Git is hard if you don't take the time to learn/teach it.

As a checkmark on a resume, knowing git doesn't mean much. Most developers know how to branch, commit, push and pull. Maybe they know a little bit of reset to get themselves out of bad situations.

We had one highly-skilled developer with a background in contributing to very unrelated FOSS join a frontend team once, adding a rule about avoiding merge commits in PRs. Within a month or so they all learned how to rebase and cherry-pick.

Git as a skill needs to be taken more seriously, not something you learn on the way to doing actual work.

You don't have to understand the finer details of Git to use it. I know that HEAD is a pointer, branches, how to submit my own modifications.

Somebody should make a GUI application that the ONLY thing it does is undoing a push to a repo, or several pushes. That's a common scenario.

Does something like Gitless (https://gitless.com/) help?

> and there’s really good man page documentation now

Well, my pet peeve has always been git-tag. When I discuss about technical documentation, I actually use man git-tag as a reference of what NOT to do.

The summary (called NAME in manpages):

       git-tag - Create, list, delete or verify a tag object signed with GPG

... which might make sense but is already confusing to a beginner because of its reference to GPG (are all tags signed with GPG?).

But DESCRIPTION is actually the best:

       Add a tag reference in refs/tags/, unless -d/-l/-v is given to delete, list or verify tags.

       Unless -f is given, the named tag must not yet exist.

       If one of -a, -s, or -u <keyid> is passed, the command creates a tag object, and requires a tag message.
       Unless -m <msg> or -F <file> is given, an editor is started for the user to type in the tag message.

       If -m <msg> or -F <file> is given and -a, -s, and -u <keyid> are absent, -a is implied.

       Otherwise, a tag reference that points directly at the given object (i.e., a lightweight tag) is created.

       A GnuPG signed tag object will be created when -s or -u <keyid> is used. When -u <keyid> is not used, the
       committer identity for the current user is used to find the GnuPG key for signing. The configuration
       variable gpg.program is used to specify custom GnuPG binary.

       [... spoiler: it doesn't get any better]

So this should be a description that makes beginners understand git-tag.

Instead, it is a sequence of unrelated sentences that merely describes functionalities in response to command line arguments, in a very convoluted way (I think "If -m <msg> or -F <file> is given and -a, -s, and -u <keyid> are absent, -a is implied" is a little gem).

This is how I would write it:

       Create, view, and delete tags.

       By default, it creates a new “lightweight” tag, which is simple a reference to the current commit (eg: “git tag v1.2”). If you specify “-a”, a “annotated” tag is created instead; an annotated tag is still a reference to the current commit, but also remembers the date in which it was created, who created it, and optionally saves a message associated to the tag (like a “commit” message for the tag).

       Annotated tags can also be cryptographically signed with GnuPG, using “-s” instead of “-a”.

       You can also tag a commit which is not the current head by simply specifying it on the command line (eg: “git tag v1.2 abcde1234”).

       Use “git tag -l” to view the list of all tags.

       Use “git tag -d” to delete a tag.

So I think git still has a long way to go with documentation.

I'm a "senior" dev and here's my git skillset:

  git clone [repo] (download existing project)

  git init (start a new project)

  git checkout -b [branchname] (create a new branch)

  git checkout [branchname] (jump between branches)

  git checkout -- [filename] (reset changes in given file)

  git reset --hard (reset evertyhing)

  git clean -f -d (remove leftovers after reset --hard)

  git status (see changed files)

  git diff (see changed lines)

  git add ./[filename] (prepare file(s) for saving)

  git commit -m [commitname] (save changes)

  git push origin [branchname] (push changes to remote server)

  git merge [branch] (merge two branches)

I've been using these commands exclusively for the last 12 years or so. These are the ones I know by heart. If I was able to get by only using these than it's likely you could also survive knowing nothing more.

Rebase is still confusing at times. I did cherrypicking multiple times, but usually Google that just to be sure.

Squashed a few times, but this I also Google.

Reverted a commit a few times too, Googled.

Changing commit message and unstaging is more common, but still do it so rarely I have to Google it as there's no point in memorising (one day might finally remember them, right now I know it's reset soft and amend, not sure about syntax).

I do not use git pop and git stash because microcommiting is better and less confusing and leaves no trash behind (just my opinion, might be wrong).

Maybe I've missed something but if you're taking it slow and do not make any serious fuckups with git it's all about add/commit/push, 99% of the time. I know I might seem lame to most of you as there are more git ninjas on HN than anywhere else, but I honestly just did not need any other commands and I've been working for companies as big as 500 devs.

It's a whole different story once you do something wrong, my strategy is to think 10x about everything I type after 'git' and never had any issues, but when they happen - I just Google again. Worked every time, so far. I feel although I know shit about git I'm pretty confident using it, I've seen many mid devs who still have trouble with mental models of merging stuff, people merging "dev" branch to feature branches etc. is something that happens to other folks quite often.

To sum things up - I think git is extremely hard if you want to use it from top of your head to fix complicated and not that common issues. If you just want to use it, survive and not necessarily understand all the mechanics behind it - it's as easy as HTML.

I sympathise with the article, though I'm not sure git is to blame here - if you have to revert a branch from remote once in 2 years there's no way you're going to remember how to do that. Without UI you will need to search for the solution every time, and it does not matter what command line tool or version-control system you use.

SVN: "Not enough options!" Git: "Way more options!" You: "Too many options! I want more options!"

People overthink it. Git has ten million ways of doing anything - pick a subset that works, and stay within it.

Isn't it true that Google doesn't use git? Wonder what they know that we don't.

`git log --name-only --oneline`

Why is "name only" split but "oneline" is not?

Honestly, I like PTC Integrity over git. Sure the UX sucks but it makes sense.

Boy, if you can't handle got, I've got some bad news for you...

If you think Git is hard then you shouldn't be writing software.

To answer your question about deleting a remote branch: branches are usually features, e.g. fixes, new features, etc. Once I've pushed to the remote and merged, the branch is no longer necessary. This is why someone would delete a remote branch.

The misconception of a singular branch is the fault of git forges.

Sounds like we need a new, higher-level interface on top of git.

Git is indeed hard and it would help to have some metaphors for it. One I ofter use (I work in biology) is that it is like a lab journal. A lab journal also needs to be in a specific format, dated, indexed, checked every now and then (by someone else), changes have to be dated and signed.. And it's also hard :)

What make it less hard is something like vscode, just click the file you want to register the change that you made for, make a nice description, sign and date (commit).

I also went through the xkcd 1597 phase, we all do, but over time you start to appreciate the beauty. Like all hard things, take it easy and allow yourself to learn.

Maybe something easier will come along in the future, but also making it better will probably very difficult. It is more likely that more convenient layers are build on top of Git, imho.

I work with people who continue to struggle with it, and occasionally make a mess that I have to clean up. They've watched the tinker toy video, and others.

git is not simple but it's not hard, the model is quite sound right ?

The phrase that I hear often when complaining about git: "Git good".

> Click here to listen along while you read. It's better!

No. It really isn't.

mercury was better but . . . really?

No it’s not

RTFM.

What?

git is hard? what are you talking about mate? >proceeds to use github desktop

Okay finally RTFA and I have this to say:

> Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it?

It's always possible to reset the head back one. You "really shouldn't" because this will cause issues for anyone else downstream if they had already pulled, but this is an issue common to CVS, SVN and probably most other VCS. Arguably the Git approach is best because it actually provides a structured way to do it, and offers your downstreamers an escape hatch should they decide they don't like what you've done. As somebody else pointed out, it's like trying to unsend an email. I think you've more wiggle-room than with email though since there is a possibility to correct the record, somehow.

I'm not sure how you would do this better, a system of notifications perhaps but arguably this is something for the tools sitting atop git, and is actually "made possible" by git vs other VCS.

> How do I delete a branch? / Do you wanna delete a local branch / delete the remote tracking branch / Or delete the remote branch?

If they're coming to you it's almost certainly the remote branch, although the alternatives are so trivial they're barely worth mentioning. Most people will approach learning something new in terms of what they already know, and if they've ever used version control software before they're almost certainly thinking in terms of the old, centralised model.

> A branch is just a single concept in our head that is made complicated

I would say it is "clarified" - just like we never needed to worry about quantum effects and the classical model of physics was fine, it does one no harm to update your mental model to accomodate these things when they come to light. In a distributed setting it absolutely makes sense to be more cognisant of the split realities of two nodes in a distributed system. [0]

[0] https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

> I have some changes. I wanna share it with Jon and Johnny so they can tell me what they think. And then maybe they can add their ideas. And then we can have a merging of our ideas, and eventually test out if it works, and have it out there and ship it.

There's a couple of things wrong with this, but the most glaring is that there are many many ways to do this first of all, but secondly it's not what git is for. It's for version control. To the extent that it supports collaboration it's still a version control tool. You can absolutely email your diffs, or put your code on a share, or do demos or exchange design documents but to me at least Git is an improvement on all of these.

> But then when we come to physically typing out all those commands… suddenly we need months or sometimes even years of learning this set of tools to become proficient enough with them.

Nobody complains about the C compiler command line? You figure out what you want, and you embed it in a Makefile or something, or you learn the commands that you need to know to do 90% of your stuff.

> I have really initially resisted the idea of graphical tools for Git, because I was this heavy terminal nerd; I was very much in my terminal bubble of being really proficient with a lot of these things,

Ah, here. Let's be clear, while I think it's important to maintain contact with the command line in these matters, you really, really need to have some good tools or you really are going to be in pain. C compiler analogy again: I can use an IDE to shield myself from these issues. The beauty of Git is it's got such widespread support there's so many great tools, and I honestly think you would be "mad" to pass them up.

> I especially see it when somebody not from my background is approaching this.

Like who? Git is a tool for managing code. I think he might be driving at non-programmers who contribute to a project like graphic designers or people providing copy. Fair enough, but that's an extension of the brief for software VCS which is primarily designed with managing and versioning text-based software ... it's not, historically what they are for. Surely there is software for managing these kinds of assets?

> I will get you to think about a directed graph or as > No human thinks about that

I'd say a large amount of people on here think like that. All are human. But facile analysis aside, most people that use git don't talk like that or describe what they're doing like that. The "chain of commits" is a very useful mental model however.

> I’m gonna save my work and I’m gonna share it with other people. Then I’m gonna step off this computer and just leave for the day.

Yes, you can zip it up and email as an attachment, or export it on Dropbox. But when you need to store your changes "on the record" it will need to go into a version control system at some point.

> I feel that version control systems (the next version of them) should not be something that was specifically made for the Linux Kernel community

Literally any other existing version control software. Check out mercurial for something that approaches parity with git's features [1], it was an early frontrunner but Git ran away with it globally. Nobody was forced to use it, it was just the better tool.

[1] https://www.joelonsoftware.com/2010/03/17/distributed-versio...

The actions for the commands ‘commit’ and ‘push’ were always confusing to me.

‘commit’ will take a snapshot to your local branch. But then, you have to “push” it to the remote branch.

I understand what it’s doing, but the choice of words seem wrong. It sounds like “push” has a lower importance than “commit”. But because “push” will sync your local changes with the master remote system, then this obviously has more importance.

Instead, I think they (Linus) should have used something like “snap” for snapshot, to take a snapshot of your local changes. Then “commit” would be used to push your local changes out to the remote server or repository.

magit

/thread

I've never understood people who complain that git is too hard. What's so hard about it?

Complaining is not the best strategy for marketing anything. If one cannot use it, why bothering onesepf with more complex problems comes up in software engineering?

A free market theory says anyone can prosper if one does what can do great. Do something else. Learn git. Or drive trucks. Do not complain.

Git is not hard - the “questions” in the article are incomplete or not properly framed, that’s why they don’t have a straightforward answer. If you can’t be bothered to understand a crucial tool you use everyday I don’t know how you expect to be a professional developer. Hell even hobbyists have mastered git and are not running around complaining.

“Started using git when GitHub was in beta” what a newbie haha.

Saying that git’s distributed nature makes things harder - well it’s the entire nature and point of git to be distributed :)

People don’t want simpler, friendlier source control, this is why bzr failed and was abandoned.