GitHub is an engineer thing, right? Not so much anymore.
Now that generative AI writes code and builds whole sites, GitHub is turning into something more than "a specialist tool for engineers." Hub-chan, the Academy's dev-support officer, takes you from the absolute basics all the way to real-world use.
The quick manga version
"Hub-chan, what's the point of you, exactly?" Not a fan of long reads? Start with the manga for the gist.
So what actually is GitHub?
In one line: it's a shared place to keep files that records every single change you make. Think Google Drive โ just quite a bit smarter.
๐ Everything scattered everywhere
- "final," "final2," "REALLY_final" โ version control by filename
- No way to trace who changed what, where, or when
- Want to roll back to an older version? Too bad, it got overwritten
- Someone else turns out to have been editing a different copy the whole time
๐ Every change is kept
- "When, by whom, and what changed" is recorded automatically
- Don't like it? Roll back to an earlier state any time
- Several people can work at once and merge their changes safely
- Not just code โ task management (Issues) lives in the same place
"Git" vs. "GitHub" โ and what's a "repository"?
Git โฆ the underlying system that records change history. It works entirely on your own computer if you want it to. GitHub โฆ the service that puts Git on the internet. It's the place where everyone can look at the same project and share it. And one whole project โ the entire folder โ is called a repository (repo for short). When someone says "take a look at this repo," they basically mean "take a look at this project folder."
Why non-engineers should use it too
"I don't write code, so this isn't for me" โ those are exactly the people who stand to gain the most.
Hub-chan
Now that so much gets built by asking a generative AI to make a site or an app, GitHub has become the default home for whatever comes out the other end. Hub-chan, our dev-support officer, explains why.
Sites and apps built with ChatGPT, Claude or Cursor overwhelmingly end up on GitHub. In fact, Hana AI Academy itself runs on exactly that setup: the code lives on GitHub and gets published automatically.
Once your files are on GitHub, you can reach the latest version from any computer. No USB sticks, no emailing files to yourself, and no more "wait, which copy is the current one?"
People assume GitHub means "a place to put code," but you can actually store any kind of file. Word and Excel documents get the same change history, so it's far tidier than letting a folder on your PC descend into filename chaos.
Keep the reports and checklists you produce every month or every year in a single repository, and "where did last year's version go?" stops happening. Every past version stays in the history, so looking back is easy.
Because the full change history is kept, "actually, the earlier one was better" is a one-step fix. That's the big difference from Word or Excel, where every save quietly erases the past.
A feature called Issues lets you log and track bug reports and feature requests one by one. Far less broken telephone between engineers and everyone else.
With GitHub Pages you can publish the files you've uploaded as a website, as-is. Even if you're firmly a no-code person, it's worth knowing about.
โ ๏ธ One caveat: very large files, like video or piles of images, are a different story. GitHub isn't great with big binary files, and the free tier caps file sizes. For heavy assets, it's better to use other storage alongside GitHub.
Public vs. private: don't skip this bit
We've talked a lot about how convenient it is โ but this is the one point you really must get right.
If you don't want it seen, make it Private by default.
Every GitHub repository is either Public or Private. Set it to public, and anyone in the world can read those files.
Documents containing personal data, confidential company material, passwords, API keys โ if you'd rather other people didn't see it, when in doubt, keep it private.
You choose the visibility when you create a repository, so make checking it a habit from the very start. You can switch between public and private later, but remember: once something has been public, someone may already have saved or copied it.
Commit vs. push: what's the difference?
This is where beginners trip up more than anywhere else. Let's take it slowly.
Do the work (local)
Writing and editing files on your own computer. At this stage, it's still only on your machine.
Commit (mark a checkpoint)
"Record everything up to here as one checkpoint." Think of it as saving a draft in your own notebook.
Push (send it to GitHub)
Uploading those records to the place everyone can see (GitHub). Think of it as handing the notebook in to your teacher and classmates.
Committing feels exactly like saving in a video game โ do it as often as you like, at every natural break. At this point it's still only recorded on your own computer.
Only once you push does it become visible to everyone else. A whole day of commits lands on GitHub with its history intact.
Committing alone means nobody can see it yet.
"I committed, so I sent it!" โ and then it turns out the push never happened. That's a classic slip, and not just for beginners: people using AI tools do it too. Only after you push does the change become visible to everyone on GitHub.
Mixing up commit and push
- Thinking commit = send, and forgetting to push
- Or the opposite: pushing after every tiny tweak
- Cramming a whole day's work into a single commit
Commit often, push at the checkpoints
- Commit at every natural break in the work (save-game style)
- Push once at the end of the day, all together
- Think of it as "here's how far I got today" = one push
In the generative-AI era, Hub-chan is buried under more pushes than ever
As the dev-support officer looking after the Academy's repositories, Hub-chan is busier right now than she has ever been.
Dozens of pushes a day โ that's Hub-chan's daily life now
Tools like Cursor, GitHub Copilot and Claude Code don't just write code any more โ they handle the commits and pushes themselves, and development speed has climbed to a level the human-only era simply can't be compared to.
Managing repositories, reviewing pull requests, running CI/CD (the machinery that automatically checks and publishes changes) โ Hub-chan barely gets a breather. To be clear, though, she isn't the one writing the code: that's the developers using AI tools. Hub-chan's job is to catch everything they push and keep it organized.
And here's the important part. Precisely because AI can write so fast, the step of "a human actually checking whether the AI's code is right" has become more valuable, not less. The mechanism that handles it is the pull request โ up next.
Putting it to work (beginner to intermediate)
From here on, we go through the words that come up constantly when you actually build things as a team โ with diagrams, one at a time.
Branch
BeginnerInstead of rewriting the main line (main) directly, you create a side track for experiments and work there. If it goes well, you merge it back into main; if it doesn't, you just throw it away.
Pull requests (PRs) and reviews
BeginnerA pull request proposes the work you did on a branch: "can this go into main?" Checking what's inside and leaving comments is the review. The more of the code an AI wrote, the more this checking step matters.
Work on a branch
Build one bundle of changes without touching main.
Open a pull request
Ask for a review: "okay to bring these changes into main?"
Review approved โ merge
Once someone has checked it over, it joins main and you're done.
Issues
Beginner"I want this bug fixed," "I'd like this feature" โ a task tracker that records them one at a time. It lives in the same place as the code discussion, so there's a lot less broken telephone.
Conflicts
IntermediateWhen several people (AIs included) change the same spot at the same time, you get the "so which one do we keep?" situation. It looks alarming, but once you understand the mechanism there's nothing to fear.
GitHub is becoming everybody's tool.
Get the commit-versus-push distinction and the idea behind branches and pull requests, and non-engineers can follow the conversation just fine. In an age where we make things side by side with generative AI, why not borrow Hub-chan's safety net โ "if it breaks, you can always go back" โ for your own work?