Hacker News Reader

Comment by iheartpotatoes | Hacker News Reader

This is nice, but I'd like a 201-level handholding on git. I've been using it for 5 years and I'm still just a clone/commit/merge/(bang head)/push user yet I know there is tons more it can do that would probably make me more effective. (I'd also like to switch my team of SVN. Someday....)

View on HN

My recommendations:

* Git From the Bottom Up: https://jwiegley.github.io/git-from-the-bottom-up/ (PDF: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf) (See also: "Linus Torvalds' greatest invention": http://perl.plover.com/yak/git/) Once your mental model matches the program, you'll be able to understand everything, hack your own solutions if necessary, etc.

* Learn Git Branching: https://learngitbranching.js.org -- in fact I think this should be the UI for Git; wish someone would make that happen (i.e., so that you can point it to any Git repo and get that sort of visualization for it).

Thanks! Awesome resources! I'll add it to my post as soon as I finish reading all the answers. I'm learning a lot from you!

I'd also recommend http://matthew-brett.github.io/pydagogue/rebase_without_tear...

I think once you understand the graph, then looking at what the graph looks like and what you want it to look like usually leads you to being able to figure out what operation you want.

And then git fetch/push/pull are mostly about copying parts of that graph from one place to another.

After that, it's mostly a question of what workflow you want and that becomes much more than a git question because git works for a variety of workflows, and many of the features of git are really only relevant for certain flows.

100% agree. Once you know what you want the tree to look like it's usually just a matter of making a branch/tag (in case you mess up, and need to start over) and not being afraid of reset, even with the --hard flag.

SublimeMerge is also a wonderful tool. Been using that since it came out and has helped tremendously with difficult merges. It's lightning quick as well.

Similar to magit - Sublime Text also has SublimeGit, not as fast as SublimeMerge.

Visual Studio Code built in git functionality is also nice.

A mention for Tower. I only do the basics but it totally took away my Git fear.

https://www.git-tower.com/mac

gitKraken is nice too

https://www.gitkraken.com/

Use a GUI. Git repos are graphs and trying to understand a graph from the command line is like trying to paint over the phone.

I recommend GitX (FOSS, Mac only, a little buggy but has the most logical UI and let's you easily amend commits), SourceTree (free, quite slow, Windows/Mac), Tower (paid, cross platform) or SublimeMerge (paid, easily the fastest, cross platform).

If you're an emacs user (and maybe even if you're not), try the magit package.

That taught me in a few weeks of usage more git 102 and 201 type functionality than a year of using only the basics did.

As a new emacs / spacemacs user, I bounced off magit hard. Too many weird things going on, hard to tell what I can do.

A couple months later, and a bit more experience with how emacs structures things, and I've returned to Magit and _love_ it. It just feels natural to hop around in for standard tasks. Certainly a good replacement for other porcelain UIs I'd normally use.

I use Spacemacs ONLY to have access to Magit. And I've successfully converted many non-emacs non-vim folks to use it, all of them love it.

This is so so fitting, and describe me to a "T" as well.

I'd add oh-crap-I-screwed-up-so-let's-clone-the-repo-and-start-over to the list.

Alternative to nuking from orbit is taking a look at "Flight rules for git": https://github.com/k88hudson/git-flight-rules

Awesome! I'll add it to my post! Thanks!

What can you screw up that requires re-cloning the repo rather than just a reset --hard?

Not knowing about the "reset --hard" feature? :)

For one, accidentally deleting the .git directory.

Honestly, you just need to try some things. Your reflog is your friend. You'll get the hang of reset/rebase/ect with a little experience. I also think it's worth it to learn a bit more about diff and log.

I have no idea why anyone would want to go back to SVN. If you don't want to use all the features, I understand; by all means, continue to only ever branch -> commit -> push -> create pull request. There's no need to subject the whole team to version control that doesn't work. That's what sold me on git; it's the only version control system that never failed at it's job of letting me track my changes. It doesn't break it's promise to always be there for me.

SVN, centralized systems, and even mercurial to some extent, prevent users from tracking their changes. This leads to questionable workflows (lots of copying directories to "save things"), or even worse, developers just don't track their changes at times. It sounds weird that I have to say this, but I feel that version control systems should be available to track changes 100% of the time. It seems like many of the people who dislike git, don't see the value in this, which I find absolutely baffling. Git means never being scared to create a commit.

"and even mercurial to some extent, prevent users from tracking their changes"

False. Stop spreading misinformation about Mercurial.

"Git means never being scared to create a commit."

This is indeed one of the biggest benefits of DVCS tools, including git and mercurial.

Thanks for the feedback. Quite frankly, I never found a comparable workflow in Mercurial (but that doesn't mean one doesn't exist). Commits still felt like a permanent thing that made me pause and think about whether something was "worthy" of a commit, thus I was unable to track my changes. This problem just doesn't exist in Git, though some care is needed when publishing (as w/any system).

I'm unaware of anything within base Mercurial that lets me do what I can do with git. Maybe the answer is to use the extensions, however that's a bit unsettling when some of them are being depreciated (eg. hg queues). Often times I found myself cloning and maintaining multiple directories for something that was better off as one thing. This led to reluctance to track changes, which is clearly evil. I guess I must have been doing something wrong, but I've heard similar feedback from others regarding Mercurial. I loved using hg and would have no problem using it (it was my first); I just prefer git now.

I agree with sjburt when he says "I think once you understand the graph, then looking at what the graph looks like and what you want it to look like usually leads you to being able to figure out what operation you want." When I was first getting in to Git ~10 years ago, I remember that I found the PeepCode "Git Internals" book[1] very helpful for getting that understanding of the graph.

Once you have the better understanding of the graph, it's hard to find resources on how to improve from there; most resources focus on beginner stuff, or function more as a technical reference without really talking about use-cases. I've found following Mark Dominus' blog[2] for his posts about Git to be the single best thing to "level up" my Git usage once already being at a high-level.

[1]: At the time, I had to pay money for the eBook, now they have the whole thing on GitHub: https://github.com/pluralsight/git-internals-pdf

[2]: https://blog.plover.com/

I took it upon myself to introduce Git to my colleagues: statisticians who've never used version control. I tried to preempt hard questions by going into a repo, wrecking it like a mad bull, and trying to undo the damage with Git. Turns out, it was a great way to learn for myself.

Exercises:

- Commit a "secret" and involve it in other branches, commits, merges, etc. Then remove the secret so that nobody can ever learn it from the repo.

- Clone a repo from another local repo and then rewrite history with rebase and revert. Then commit different work in each repo. What's the least painful way to get them "compatible" without losing any work?

Reply on news.ycombinator.com