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

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.

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.

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

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

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.

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.

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.

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!

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

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.

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.