How to give a crash course on Git?

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

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.

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'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.

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 ).

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.

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.

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