Live data from Hacker News

Ask HN: What made you finally grok Git?

news.ycombinator.com

21–30 of 94 posts

Re: Ask HN: What made you finally grok Git?

#21

I have not grokked git — it hasn't been necessary to. Understanding some of the basics, knowing enough of the commands to run, and figuring out which StackOverflow answer applies to my current situation is good enough. If I have to spend too much time knowing its internals and delving into its philosophies, then it is not a useful tool that lets me get on with my tasks.

Kinda.

I wouldn't be able to tell you too much about the internals of VSCode.

The 'trouble' with git is, though, that what happens when you run the wrong command can vary from "easy to fix" all the way to "you just lost your work, you shouldn't have run that command".

Which means you need to either be very careful anytime you run git, or you need to learn more about git to avoid the footgun aspects of it.

Re: Ask HN: What made you finally grok Git?

#22
0. mental model: staging, local, remote. c'est tout

1. `git status` + gitk before and after git commands

2. guess upfront what the result of git commands will be (in terms of gitk / git status)

3. be fluent with commit, push, pull, checkout, reset, merge, and possibly rebase (I call it required but it's opinionated) - you can safely ignore the other git api in 96% of workflow

Re: Ask HN: What made you finally grok Git?

#23

get in the habit of commiting every few lines you write, and before creating a pull-request(tm) use 'git rebase -i' and cleaning up into meaningfull bit sized history. move related changes togheter, remove (squash) things that didn't make it to the end, etc. oh and never join any project that uses github and force squash-commits-on-pullrequest-merge. that is a sign that nobody there knows git or they don't care about…

> oh and never join any project that uses github and force squash-commits-on-pullrequest-merge. that is a sign that nobody there knows git or they don't care about code history.

First, color me offended! Second... you're not completely wrong. My git-fu is not that strong. Would you help me improve it by explaining why squashing via the GitHub UI is so bad? To me it feels like an easy way to condense 1 PR into 1 commit. For some workflows, that makes much more sense than trying to get everyone to play by the same commit semantics. But I can see how it's not as "pure" in capturing the meaning behind your commits. Maybe it would be helpful to provide an example of a situation where squashing with the GitHub UI could cause problems?

Re: Ask HN: What made you finally grok Git?

#25
post #5

When I realized it's just a DAG and you're just manipulating a graph and pointers. Then it just became a matter of mapping git CLI commands to how they manipulate the graph.

I still don't fully understand what the nodes and edges in this graph "is" though. It's not patches. And I can't believe it is "all of the code" in each commit because that sounds very expensive.

Re: Ask HN: What made you finally grok Git?

#26

Reading this[1] and getting the data structures/mental model correctly internalised in my head. Although I do use git from the cli (or magit) primarily, this knowledge has helped me pick-up front end tools intuitively and have helped others when I've never used their preferred tool. All of this doesn't seem possible unless you've put in the effort learning what's going on behind the scenes. That is to say, git itself…

This is my answer too. The main git book is very well written. I stopped reading just before it got into rebasing and had to pick that up from the internet due to work requirements, but the book was so solid in explaining the basics that I understood outside stuff almost immediately.

I think one thing that’ll help OP, is to learn everything on the command line. The fine grain control is worth the extra effort. I’ve hated almost all git GUIs in most IDEs because they won’t let me do weird things like grafting branches which is a very advanced concept for them but once you understand git, it is a very simple operation.

Re: Ask HN: What made you finally grok Git?

#29
The trick(s) to git is not using `git add -A`, and being diligent (as in checking before you commit) about the changes that you are committing. Only add and commit what is relevant to the task that you are working on. But it's even simpler than that. Before you commit anything, check what you are about to commit. Is it what you expected? Is it relevant? Does it work? Has it been tested? Is it likely to pass a code review?

Re: Ask HN: What made you finally grok Git?

#30
Sit down with a coffee, read the book https://git-scm.com/book/en/v2 and just spend the time learning how to use it. You'll save yourself a bunch of time and headache and won't need to be nuking repos or branches any more. There's a lot it can do, so a big part is finding out what fits into you and your team's workflow.
Post reply on HN