It is fine if the words below mean nothing to you yet — the course teaches all of them. For now just remember two things: student data does not go online, and passwords do not go into a project.
First, student personal data and unpublished data never go into a public repo — .gitignore is not a security tool. Second, not even a private repo holds account names and passwords — once something has been committed it is in the history, and deleting the file afterwards does not help.
The full explanation of both lines, the three rules of supervision, and the first-aid kit for "I saved the wrong thing" are in Part V of the material.
IWho this is for
For university teachers and graduate students who have a research project in hand. The test is simple: if a file called thesis_v3_final_really_final.docx has ever appeared in your folder, or if you and a co-author have mailed drafts back and forth until nobody is sure which one is newest, this course was made for you.
You do not need to know any Git command, any terminal, or any programming language. You do need a computer with an internet connection, a GitHub account, and an AI assistant you are used to — and it is fine if you do not have the last two yet; the setup pack walks you through getting them.
This course does not teach you to memorize commands, and it does not explain how Git works inside; several advanced features (stash, rebase, fork workflows, GitHub Actions) are skipped on purpose. What you practice is something else: being the supervisor of your agent (the AI assistant that does the work for you), not its rubber stamp. The full "why" is in Part I of the material.
IITwo routes: which one are you?
Same 15 steps, but a classroom session and solo self-study walk them differently. The difference is only in Stage 2.
You walk all 15 steps. In Stage 1 everyone works on their own research project. In Stage 2 you pair up: one of you plays the graduate student, the other the advisor, taking turns to propose changes and to review them, and at the end you swap roles and run one short round again.
For now, walk Stage 1 only, P1–P9. That stage is about your own research project anyway, and finishing it already solves the more painful half: you can get an earlier version back, your work is backed up on GitHub, and you can see what changed.
What C1–C6 practice is exactly how two people work on the same draft without stepping on each other — propose, send back, revise, approve, merge. One person cannot create that situation, so wait until you have a co-author, a student you supervise, or a place in a scheduled session.
Please do not register a second GitHub account just to fake a partner and play both roles yourself. The GitHub Terms of Service state that one person may keep only one free account, and practice is not worth crossing that line for.
IIIWhat to prepare before you start
You have to work through all ten items in Part II of the material, "The setup pack" (two-factor authentication, installing Git itself, installing PowerShell 7, the permission settings for your AI assistant, signing in to GitHub, and so on). The three lines below are only the lowest bar, the one that lets you judge right now whether you are heading in the right direction — they are not the full list.
The three minimum checks: ① your AI assistant is installed and signed in (it opens, the login works, you can find the input box); ② you can sign in to your GitHub account; ③ do one warm-up run — ask the AI to create a small file, and to report the Git version and the GitHub account it is signed in as, then open the file yourself and look at it.
Item ③ tests the whole installation chain in one sentence — the AI reports the Git version and the GitHub account it is signed in as (the tool is called gh), so this one step shows you whether Git is installed and whether GitHub is signed in. And the step is itself the first lesson of this course: the AI saying it is done does not mean it is done. ⚠️ But it cannot check two-factor authentication (2FA) or the permission settings of your AI assistant; for those two, follow the material. The material has an interactive ten-item checklist you can tick off, a screenshot for every step, and a sentence to say when you are stuck, so none of that is repeated here. Give yourself two evenings and do not leave this to the day before — several items need downloading and installing, which can take more than an hour depending on your connection.
IVThe 15-step map: what each step does, and where you must look yourself
This table is the map of the whole course. The right-hand column matters most — that is what you have to check yourself after the AI is done. The value of this course is not in the commands; it is in that column.
| Step | Minutes | What you do in this step | What you must check yourself |
|---|
The clock-based class schedule (what happens when, and what the instructor watches for while walking the room) is in Part VIII of the material. The times listed here are estimates for one person working through a step smoothly.
VDid I actually learn it?
After Stage 1, ask yourself these questions. Being able to answer them is what counts as having walked the path; the progress bar on the quest page is only a helper.
- I know that Git looks after one folder, and I can say which folder I am in right now.
- I can have the AI save a change as one version, and I read which lines it changed before saving.
- I can push the project to GitHub and see it on the website.
- I can read the history and compare two versions to see how they differ.
- I know that "just looking", "restore" and "revert" are three different ways of going back, and I know which one is safe once something has already been pushed.
- I know which files should stay out of the repo, and that
.gitignoreis not a security tool. - I know that an agent saying "done" does not mean done, and I open the file myself to check.
- I know I can call a stop at any moment, and I remember how the rescue sentence goes.
VIAfter the course: what to do next
- Move a real research project in. First decide whether the data can be public; if you are not sure, open a private repo — but a private repo still holds no account names or passwords, and sensitive research data still has to be judged against your institution's and your project's rules. Also keep the split you learned in class: large data files (.dta and .csv files easily run to hundreds of MB) stay on cloud storage and out of the repo — GitHub has a hard 100 MB limit per file, and pushing one in gets the whole push rejected.
- Move the files you edit often to plain text. Notes as
.md, papers as.tex; that is what makes line-by-line differences visible. - Find a co-author or a student you supervise, and go back for Stage 2. Once the two of you have done one PR together, real collaboration later will not get stuck.
- If your journal asks you to submit data and code, this workflow is the layer underneath: a complete history of changes, a clean list of files, and a clear account of how each version differs.
Before you start, it is worth reading Part X of the material, "Three honest limitations (we are not hiding them)" once: Word and Excel do not show line-by-line differences, GitHub plans and features change, and agents make mistakes. Knowing what a tool cannot do is how you find out what you actually have.