Ask HN: How to give a crash course on Git? | Hacker News Reader

Ask HN: How to give a crash course on Git?

31 pointsscandingo31 comments

I'm trying to build an application with a novice programmer. I need to teach him the fundamentals of working with Git and I'm hoping to find an approach that he won't find overwhelming. I'm a Linux/CLI guy. He is a Windows/VS Code guy. He has almost no familiarity with Git. I know he will be much more comfortable using GUI tools. The problem is that using Git through a GUI is very counter-intuitive for me. Do I need to just bite the bullet and spend a few days trying to familiarize myself with the tools he will be using or can I separate the technology from the tools when trying to teach him? More broadly, how do you approach teaching someone something differently than you would do it yourself?

View on HN

Give him some prescriptive formulas. He can look up the magic incantation for each task he needs to do.

Deeper understanding of git can happen gradually. For now he just needs to be able to do a basic workflow.

    ################################
    # download a new project to local disk
    cd ~/projects
    git clone someUrl

    ################################
    # get latest code
    git pull

    ################################
    # observe the general state of things.
    # Run status liberally, before/after any git operation.
    git status

    ################################
    # commit changes and push them up the the server.
    # This is the bread an butter of your git usage.
    git add .
    git commit
    # good idea to pull in the latest changes before you push up.
    git pull
    git push

    ################################
    # resolve merge conflicts after a pull
    git pull
    # alert merge conflicts! git status will tell you which files conflict.
    git status
    # edit each file with conflicts. Conflicts are flagged in file with ">>>>"
    # replace the ">>>>" sections with the final resolved code.
    # now check them in and push up the the server.
    git add .
    git commit
    git push

    ################################
    # develop in a feature branch
    git checkout -b featureX
    # make changes like nomral. add, commit your changes.
    # if this is a private branch on your local box only, you do not push.
    git add .
    git commit
    # periodically pull in the code from the parent branch so you don't drift apart
    git fetch origin
    git rebase origin/master
    # feature complete. Merge feature back to master.
    git checkout master
    git pull            # get latest master code
    git merge featureX
    git push

+1 Prescriptive workflow approach is the best. I am not competent with git, and this is the approach I have taken. I keep note of frequently used commands and solution to frequently encountered problems. I have gone through multiple tutorials from AWS CodeCommit, GitHub, etc but the most helpful has been describing the problem to someone more knowledgeable and have them guide me. Someday git will make sense to me but it is not going to be today or anytime soon.

Telling someone to take a course or go through a tutorial or read a book doesn't help that much, actually it is more discouraging and give impressions of an unhelpful colleague, as a new guy. Depending on GUI or Built-in IDE git features are not the solution, getting to know simple raw native git commands for tasks at hand or problem being faced is the best approach, imo.

On the contrary, I'd start without any remote.

Git through CLI for a new programmer is way more harder than an expert like you getting a feel for GUI. Ultimately the expert needs to learn new ways and tools before expecting novice to learn one. Git is just a tool and not the endgoal itself. VSCode has an excellent extension called Gitlens that provides UI for most basic git operations like branching, checkout remote branches, commit history, revert, stashing. It will take you an hour or so to familiarize with it. Teaching that extension should be sufficient for a new programmer

Goddamn do all the people who comment here work on linux and only through the command line, and have never used a git GUI before? There's barely any proper advice from a windows-gitgui user here.

On windows start with TortoiseGit, if he used TortoiseSVN before he'll get it. Right-clicking on a file/folder will bring up a context menu that windows users will be very familiar with, plus it has labels that even a command line git user would be familiar with. Then teach him commits, pushes and branches (git's underlying mechanics) from there on.

Sublime Merge is my preferred Git GUI. https://www.sublimemerge.com

I love this program. It is a crying shame there's no free/open source program which cloned its UI.

There’s also GitLens if they’re already using VSCode.

If it were me, I would suggest gitimmersion to my team mate.

https://git-immersion.github.io/gitimmersion/

If they were my report, I would allocate about twenty paid hours for the training. A contiguous block or fragments of time depending on the way the report trained best…some people want to plow through, others have limits of a few hours at a time.

Not saying gitimmersion is the best tutorial. Only that it is good enough for normal cases

However I am saying that without having been trained as a trainer, outsourcing training is going to be a better use of your time and theirs.

Good luck.

I like what this presents: "Learn by doing" thanks for posting it.

Plan to run through it myself this weekend. I used to use GIT back about 15 years ago, but have found my ability to remember it is limited.

Glad it might be useful.

Oh, please let me know if it is broken. It's been a few years since I used it.

I've done this to my fellow university students a few times.

What I've found is when teaching topics like this, is to start with "why git" instead of "how to git". Giving people a baseboard for them to rest their newfound knowledge helps a lot later on.

Git GUIs are a crutch, perhaps that's what your pupil needs right now, but not forever.

Windows novices may not realise that git can be a local program contained in a folder, so making a repo to test how a verb works costs you nothing.

Perhaps it bears pointing out that some people legitimately need crutches. Why shouldn’t they use a GUI to ease their access to a crucial tool?

Just teach him to use the CLI commands. If he is uncomfortable with that he will get over it and thank you later.

I think you're really underestimating their capacity to learn new things. Just teach them git through the CLI and they'll thank you for showing them a new way to do things.

In this situation, I prefer to just present the facts/choice to the other person, much as you have above, and let them decide for themselves:

So, I know you are new to git, and I am happy to help you! Just so you know, I am a bit of a command line kind of guy (because <reasons - it can be scripted, it works out of the box on all of my machines, whatever>).

If you'd like to be able to copy exactly what I do and have me help you with any problem that you encounter, you may find it easiest to use exactly the tool/version/environment that I use. However, if you're comfortable doing a bit of research and troubleshooting yourself, feel free to use a different tool that works better for you, and I'll still do my best to help you, but it's possible you'll run into tool-specific issues that I have never encountered and won't be the best person to help with. You could even try both at once, or try one approach and change your mind later on, we'll work it out as we go!

I agree with the others saying to just go ahead with teaching him the CLI, however I also think you are overestimating the amount of work required for scoping out a GUI client. Pretty much all of the mainstream clients you could get dropped into and if you understand git, could understand the GUI within about 20 min of poking around.

I actually switched from CLI to a GUI a couple of years ago because I found one that was a pure UI over git (not trying to abstract it) and that had a lot of useful features that were difficult to do from the CLI. If looking for a GUI to check out, I’d really recommend sublime merge, created by the same people as sublime text. You can also see exactly which commands it’s running which makes for an easy transition imo.

With that said, I switched to Sublime Merge purely because of advanced features that were difficult in the CLI. For just learning git, the CLI should be totally fine.

Have him go through this tutorial at the start of every week until it's second nature: https://learngitbranching.js.org/?locale=en_US

Having some visual intuition of what the commands correspond to really helps.

Set up a Virtual Box + CLI.

if you are designing a quick teaching tool or a training session, make warning messages that are informative, motivational, and kinda scary depending on the result (e.g., git commit with message is good, here's a sparkly high five; merge to main w/o code review is scary; squash commits is scary; committing credentials and pushing to prod is scary). Consider designing the lesson around lawful/true/chaotic evil/neutral/good. And then when not great things happen, have them try to fix the issue (rebase, reset commits hard/soft, rollback merge to main, ask for help when you don't know, inform someone else that you've made an error). This way they know informing others that something not great has happened and asking for help are good. Design the lesson such that best practice is standard practice.

This sounds like a fun project. Unfortunately, I don't have the bandwidth to tackle something like this right now. Perhaps if I every get sucked back into a tech lead role. It does make me think to look if there are any existing Git learning games.

I sympathize with wanting to find something that works for his perspective, but I'd recommend just showing him how you work with git, and tell him to explore other tools if he finds the CLI cumbersome.

So in short, I don't teach people to do something differently, I just teach them. I try to be clear that as long as we all are ending up with the same end result, they should feel free to find other ways that work better for them.

If he's truly a novice, then he's not an anything-guy yet (hopefully). Just teach him what you know and let him to discover GUI tools by himself if he's so inclined.

He knows enough Python to build small tools that solve people's problems, but he's never really built a full application. This is very pragmatic advice, thank you.

Explain that GIT takes snapshots, kind of like pkZip does, and it FAKES storing deltas.

Also explain that GIT stores files by the MD5 hash of their contents, show him the hidden .git folder, explain its structure, and the object folder, with all the subfolders and files

Everything else is pointers, and chains of pointers, to those snapshot files, with some labels.

---

It took me way too long to grok GIT because I was under the mistake impression that it stored deltas, and that made it much, much harder to understand

---

In Windows, "git gui" is a pretty darned usable GUI

Just point him to the source code to fully grasp the implementation details.

The better your model of how it works, the easier it is to fix things when they fail, no matter the cause.

Knowing that GIT doesn't store deltas explains some of the things that made absolutely no sense before that point.

You don't want to just tell a programmer... oh... here are some magic spells, don't worry about how they work, or how to fix it if you make a mistake.

Tell them you don't expect them to remember all the details. It should only take 10-20 minutes to get them up to speed.

If a repo has been repacked, that turns it into actual deltas. ctrl-f "git" on this page: https://en.m.wikipedia.org/wiki/Delta_encoding

I value good mental models. What behavior did the difference between fake and real deltas explain?

>What behavior did the difference between fake and real deltas explain?

Merges... fscking merges. Merge conflicts are completely unnecessary. Who cares about the delta from the last snapshot?, just store the new snapshot!

I've wasted so much time on "merge conflicts" even when I'm the only person, and I've got multiple computers involved. I've completely deleted git repos and rebuilt them to get around the insanity of merges gone bad. (Now I know it's different when you've got multiple programmers, etc... but in the base case, the wrong mental model deranges thinking)

The days of pkZIP files of source code on floppy disks NEVER included merge conflicts. GIT is an otherwise amazing upgrade from those days.

Sometimes the IDE or other tools mung a file that you don't edit by hand, but need in the archive, and you CAN'T merge it.

Gotcha. Sounds like a painful lesson. Thank you.

Reply on news.ycombinator.com