There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.
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.
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
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.
Then you wouldn't really need distributed source control, would you ;)
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.
It's not, but if you don't use it mostly every day, or if you decide to "Delete repository and clone again" every time there's a problem, you won't ever get to learn how to fix it.
The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it.
The term `checkout` is multiplexed to do more things than I would've guessed.
You don't need the staging area to select hunks into a commit. The selected hunks could go straight into a commit. Selecting hunks is a different thing than putting the selection into an extra intermediate area between working directory and commit.
You don't need an extra intermediate area to review a commit. Commits are flexible and modifiable, so you can review the draft commit, modify it as necessary, and then publish it.
But this sort of multi-step thing is often a pain to do from the command line, I find: unless you have some way of tracking the state between commands, it's no fun working through this list of items, building up a to do list that you then have to get done at the end with one uber command. And the staging area is this way of tracking the state when it comes to putting together your commit.
The gitless examples look to have many common possibilities licked, though, and perhaps that will suffice for most cases?
Staging area / Index is one of the best features of Git for me.
If I end up having a bunch of semi related changes in-progress; being able to easily group those into individual commits is great.
> The term `checkout` is multiplexed to do more things than I would've guessed.
Agree
I can't even imagine not having it, I extremely rarely commit all changes, to the point where I really might as well alias add=add -p, and now I've thought of it I probably will.
> The term `checkout` is multiplexed to do more things than I would've guessed.
My rule is that if I think that, I've probably got the 'wrong' mental model.
Checkout gets the state of the worktree from somewhere else.
In its simplest usage, from another ref and changes to it.
With -b, as above, but with a new branch name.
With -- files, filter for only the given files, leaving HEAD where it is because moving it would be the opposite operation - taking the inverse list of files from current location to the specified one.
Etc.
Honestly, I think that 'stash' is the more problematic concept for me. Not that it's particularly bad, just that it's extra. Make a new branch for your awful code, check out your old head and keep going. I learned hg and then git, and IIRC stash was more comfortable for my team's established workflow.
And maybe I have good reason to hate it. One of the only times I've ever broken a repo is by attempting to stash partway through a messy merge. Never did figure out if that was pebcak or a bug, or if I could gracefully recover, because I was in the middle of something. I shed a tear, nuked the repo and found a better direction to merge.
Ever since that happened I've gotten much more comfortable making and deleting branches. Among other things, they're easier to clean up and have proper histories.
Do you mean `pull`?
> The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it.
It's an interesting POV. Especially since you can easily amend and rebase -i before pushing without any consequence. Thanks for the idea. I implement a git-like for a special use case at the moment and will certainly consider this.
It makes the staging very convenient to use. But without this command, I agree that it is a pain to use.
And there are also those people who inflict themselves unnecessary strict rules for whatever reason. Like those who refuse to rebase and push -f on their own branches. Or those who refuse to use a GUI but keep messing up when diffing, resolving conflicts and staging specific files/lines.
Recently got turned onto `git push --force-with-lease` which is great.
I had a coworker explain that he did a merge and something unexpected happened to his branch. I had to explain to him that what happened was totally expected and that his understanding was what was wrong.
Quick quiz: What does 'git checkout a/b' do? I've seen users end up with 3 different meanings.
But I guess this is very subjective. After all, I've never been able to master gnupg despite how long I've been using it for.
On the contrary, I find the "graph of patchs/Merkel tree/whatever" model pretty easy to understand, and have difficulty in using the commands to make the tree look like how I want it to.