Ask HN: Recommendations on how to become a Git expert? | Hacker News Reader

Ask HN: Recommendations on how to become a Git expert?

19 pointstelman1716 comments

I use Git daily and often but rarely beyond pull, add, commit, and push. Feature branches are squashed when I merge into our main/master branch. Meanwhile, whenever I get on zoom calls with colleagues I can't help but feel like they run circles around me in the command line with git and I look like an idiot.

Don't ask me to cherry pick, rebase, or bisect. Merge conflicts I handle in VSCode and oftentimes I'll use GitLense or even GitHub Desktop as a last resort. I feel like these tools "work" but that I'm missing some aspect of being a software engineer by not being a command line git wizard or truly understanding what's going on when I do a rebase for example.

Are there any books/courses/videos/etc you recommend to level up in Git?

View on HN

I’m not a git expert, but little visualizers like these helped me get comfortable (coding work on and off for 10 years) with git bash:

https://learngitbranching.js.org/ https://ohmygit.org/

Merge conflicts are usually pretty tedious but not something I fear. I’d have to Google to know what precisely rebase or bisect are useful for.

My coworkers have used gui tools to deal with git and I can’t understand how those work/translate to the commands. Git commit, add, push, status, and diff have gotten me pretty far!

Hopefully that helps!

Most of the books I've seen were disappointing. The command line looks hackerish but I haven't seen any advantage over using tools like Fork.

I think most of the advanced tricks I've seen are:

1. Signing commits with gpg.

2. Git flow, i.e. branching off a feature or task then merging it back with a pull request. This is like passing a ball or making roux, more practice than theory, and a little fine skill will help a lot in making the code more readable and less buggy.

3. Cherry picking - usually done on a new branch and then merged in. This requires that commits are not too big but also big enough that you don't need lots of tiny picks for a whole.

4. Writing code in a way that you don't get difficult merge conflicts, though this is more of a question of architecture.

5. Git blame. Find out who wrote a line of code and what they were thinking. This is more useful on IDE or say, Github, than on command line.

6. Undoing a wrong commit/push.

7. Running automated tests, catching bugs before they're merged in.

The git docs are only as useful as you knowing what you're trying to do. e.g. rebase seems weird if it doesn't fit into one of the above.

What I'd like to see is more books on how to do advanced GitHub stuff and workflow. Or maybe there's some other tricks I missed out on.

Just to clarify point 2 about Git Flow (or Gitflow as is also spelled). It is just one of many workflows that include creating a feature branch off of main and merging it back in, but not the only one. Personally I always found it too complex, even for the intended use case of (enterprise) software with regular release cycles.

I would recommend the courses from Paolo Perrotta on Pluralsight - I've learned a ton:

https://app.pluralsight.com/library/courses/git-big-picture/...

https://app.pluralsight.com/library/courses/how-git-works/ta...

https://app.pluralsight.com/library/courses/master-git/table...

git didn't really click for me until I learned about patch[0] and had to use it some. I'm not sure if this is entirely correct, but I started thinking of a git repository as a DAG[1] of commits, where each commit is a patch (the changed lines of code) along with some metadata like a message, date, etc. Branches fall out of this as they're just names for specific nodes in the DAG, and thing like rebasing is taking a set of nodes (e.g. commits/patches) and replaying them on top of some other base. This has at least helped me get a grasp on how to get out of various situations.

That all said the best way to learn is to do! Maybe see if there is some bug that came up recently but was working in the past, where 'git bisect' would be a good tool to help you debug. And if the GUI tools work for you on a day-to-day basis, there's nothing wrong sticking with them over the command line. To me developer tools are a second-order thing, you should only use them as much as necessary to help you do your actual work.

[0] https://man7.org/linux/man-pages/man1/patch.1.html [1] https://en.wikipedia.org/wiki/Directed_acyclic_graph

I actually recommend against excessively complex git tricks. It's an extremely useful tool but, at times, can lead to bikeshedding.

It is definitely worth learning git skills in response to specific tasks you wish to complete though.

Regarding your situation, command line git has its uses. A big benefit can be when you're working on a mouseless environment, or want to set up personal scripts. In those cases, you should learn the command line git as needed.

Next time you want to merge think "should I rebase" and then do it if appropriate :)

Some reading: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

I wrote a post on useful Git techniques and practices that may be helpful:

https://blog.isquaredsoftware.com/2021/01/coding-career-git-...

Here is a free talk on Git Fundamentals my company organized a while back:

https://www.youtube.com/watch?v=j6Se3jH60dA

It's foundational knowledge, I quite recommend it.

This really helped me:

https://maryrosecook.com/blog/post/git-from-the-inside-out

If you're right about your colleagues (and that's a big if, because you might not be) ask them for help. Having access to people who can mentor you to improve is by far the best way to learn for most people.

Next time you have an issue, don't just try to solve it with your familiar tools, but reach out to them and say what the issue is, that you want to learn, and ask if they can help. If they're good devs they'll be more than willing.

All that aside though, the new three way merge editor in VSCode is amazing. Why wouldn't you use that to resolve conflicts?

I picked up this book, but haven't started it yet:

"Building Git is a deep dive into the internals of the Git version control system. By rebuilding it in a high-level programming language, we explore the computer science behind this widely used tool. In the process, we gain a deeper understanding of Git itself as well as covering a wide array of broadly applicable programming topics"

https://shop.jcoglan.com/building-git/

Try rebasing and don’t be afraid to make mistakes. I found that once I learned rebasing, everything else fell into place like cherry-picking. You only need a handful of commands memorized. For the other scenarios, a quick Google is fine, like when you accidentally commit to the wrong branch. End of the day, git is just a tool, you don’t need to memorize every nook and cranny.

The git docs are the most complete pieces of information. if you read and understood them, you understand git.

Just read the Git Book¹ end-to-end.

And refrain from using GUI tools for git; stick with the command line.

¹https://git-scm.com/book/en/v2

The Pro Git book is a free resource.

https://git-scm.com/book/en/v2

Reply on news.ycombinator.com