[jordigh]

The proliferation of articles like this is a very very good indication, that, yes, git is that hard, especially if you have to collaborate with other people.

Everyone has a different idea of what git does, what things are called, and different interpretations of the vast git vocabulary. What is a rebase? What is a branch? What is a reset? People have different mental models for all of these things.

Git would be easier if it weren't for all of the git users you have to work with. If you're a git solipsist, you develop your own mental model that works for you and you never have to care what anyone else does when they are using git.

[chucksmash]

I got a lot of mileage out of git with "do work on my own individual branch, never use `--force anything` even if a blog post on the internet says to, and don't rewrite history."

Reading just enough of the git-scm book to get a basic mental model of staging, branches, and pushing/pulling from a single remote (aka the things new people actually probably trying to do with git) can serve you well enough. I've since worked on teams that expected WIP commits to be squashed, used multiple remote repos, etc, but the above should be all the git most of the people complaining about git actually need.

    git remote add origin git@yabbadabbadoo:org/team
    git checkout -b feat/my-work-branch
    # do work
    git add -p .
    git reset HEAD accidental-file.txt
    git commit -m "Add sweet feature"
    git push -u origin feat/my-work-branch
    git pull origin feat/my-work-branch

I feel like there are two big reasons git gets the rap it does separate from any actual interface issues:

1. People tend to mess up with a tool more often when they are still getting acquainted with it. When things get hairy, people tend to just try random fixes so they can get back to work which makes the problem hairier still.

2. git might be one of the first tools someone uses that expects end users to map their mental model to it rather than trying to fit their pre-existing mental model.

[brobinson]

Specifying the remote and branch name again when doing a `git pull` is not necessary after you've set it as the upstream branch (which the `-u` option in `git push` did in your example).

[saghm]

To play devil's advocate, I purposely never use push/pull without specifying the remote and branch because doing otherwise would cause issues if I accidentally forget which branch I'm on (which isn't super uncommon for me, as I've unfortunately gotten so used to seeing the branch name as part of my shell prompt that I don't notice it unless I actively look at it). I believe there's even an option you can put in your .gitconfig to enforce this.

[narnianal]

Sorry, but it seems like you've worked in very low skilled teams. There are sometimes two different solutions to a problem, but they come with different pros and cons and you need to decide which to choose based on balancing reasons, not based on having different understandings of how git works.

For instance, when you have lots of parallel work, you have to decide whether to merge-commit each into the mainline or wether to rebase them. The first is an honest view of what happened, but might be harder to read. The other is easier to read, but might not represent well what actually happened. Git doesn't work one way or the other. Both is fine for git. And you should also be aware what it does under the hood for both options.

[saagarjha]

> Git would be easier if it weren't for all of the git users you have to work with.

Then you wouldn't really need distributed source control, would you ;)

[ozim]

There is loads of videos on yt on how to make pushups.