Since I started joining AI hackathons, there's one thing I've been using a lot more often.
GitHub.
Actually, I'd known about GitHub for a long time.
About 11 years, I think.
Back then, I was studying web design. I learned HTML and CSS, and then started working with jQuery.
I remember downloading free code from GitHub and adding it to websites I was building.
I can't remember exactly whose code I downloaded or where I found it.
But I do remember seeing phrases like "Feel free to use!" quite often.
Wait, people are letting me use all this amazing stuff for free!?
How generous!
That's what I thought at the time.
Some developers even wrote things like "Buy me a beer."
Basically, "Go ahead and use it. But if you like it, feel free to buy me a beer!"
I loved that. Haha!
Downloading Code from GitHub Made My Websites Come Alive!
My favorite thing back then was image sliders.
Just having images slide or transition from one to another could completely change the look of a website.
It felt dynamic. The visual impact was huge.
I had so much fun with those.
I also used things where you could click to open a list of options, choose something, and move on to the next step.
And there's one other thing I still remember clearly.
It was something like a photo gallery, with different images scattered around and overlapping each other.
Normally, you'd arrange photos neatly in rows and let visitors select one.
But this design deliberately placed photos all over the page, almost randomly, and you could click on the ones you wanted.
I thought that was such an interesting idea that I downloaded it and used it on one of my own websites.
I loved combining these different pieces to create websites.
By the way, if someone asked me to do the same thing today, I wouldn't remember how. I couldn't do it! Haha!
Back then, GitHub was a place where I could use all sorts of useful and creative things other people had made.
Then many years passed.
Recently, I started using Claude Code.
With AI helping me, I began building apps and tools for my own work. I also created a GitHub account.
Then I looked at the requirements for my very first AI hackathon.
Having a GitHub account was one of the participation requirements.
Oh! Good thing I'd already made one!
But at that point, I still didn't really understand how GitHub was used for team development.
I was about to find out.
So this time, I want to explore the basics of GitHub through my own experiences as a non-engineer.
What Is GitHub, Anyway?
GitHub is a platform where you can store and manage code and related files, share them with other people, and work on projects together.
Imagine several people building one app.
If everyone worked on their own computer and emailed updated files back and forth, things could get complicated pretty quickly.
Which file is the latest version?
Who changed what?
What if you want to go back to an earlier version?
GitHub helps teams work together while keeping track of changes.
You can also explore code created by other people when their projects are public.
Or you can create a private project and collaborate only with people who have permission to access it.
That makes sense.
About 11 years ago, I was using code that other people had shared.
Now I'm managing my own code and getting involved in team development, too.
Are Git and GitHub the Same Thing?
This part can be a little confusing at first.
Git and GitHub are not the same thing.
Git is a system for tracking changes to files.
It records changes over time, so you can compare different versions and, when necessary, return to an earlier state.
This is called version control.
GitHub, on the other hand, is an online platform that lets people share projects managed with Git and collaborate on them.
Here's the simple version.
| Name | What it does |
|---|---|
| Git | Tracks and manages changes to files |
| GitHub | Provides a platform for hosting, sharing, and collaborating on projects managed with Git |
You can use Git without GitHub.
But when you're working with people in different locations, a platform like GitHub can make things much easier.
My First AI Hackathon: Working Together on GitHub
At my first AI hackathon, our team worked on a single project together.
One of my teammates set up a repository on GitHub.
A repository is a place where a project's files and their change history are managed.
We worked on the project using that repository.
My main contribution was helping to complete the README.
A README is a file that explains what a project is, how it works, and how to use or set it up.
On GitHub, you'll often see a file called README.md.
It's like an introduction or instruction manual for someone who is seeing the project for the first time.
That's the part I helped with.
And at that particular hackathon, the project submitted through GitHub was evaluated during the first screening round.
So the README was super important!
I wasn't writing the core program.
But this experience taught me something.
Oh, so GitHub is a place where everyone can work on the same project together!
That was a completely different way of using GitHub from downloading free code 11 years earlier.
My Fourth AI Hackathon: I Even Have My Own Branch!
Fast-forward to now.
I'm taking part in my fourth AI hackathon, Vietnam Japan AI Hackathon 2026.
This time, I'm on a two-person team with a Vietnamese AI engineer.
We're working on FrostLoop AI, an AI agent for Amazon sellers.
Recently, my teammate invited me to our GitHub repository.
And he even created a branch just for me!
What's a branch?
Put simply, a branch is a way to separate different lines of work within a project.
For example, imagine that a team uses a branch called main as the shared reference point for its code.
You can create your own working branch from there and make changes without immediately changing main.
Once your work is ready, the team can review it and decide whether to merge those changes back into main.
This makes it easier to collaborate without everyone editing the same shared branch directly.
Ah, so that's why he made a separate branch for me!
But actually, I haven't really started working on that branch yet.
I've looked through its contents, but most of my other work is still happening locally on my Mac.
The CSS changes related to colors and fonts seem to have been reflected in the team's project already.
So why am I being so cautious?
Because I don't want to accidentally break something my teammate has built!
He's put a lot of work into the project, and I'd hate to cause problems by making the wrong change.
So my plan is to get things into reasonable shape locally before moving further into the GitHub workflow.
My teammate also shared a Markdown file for our work.
I think checking and following team rules like these is an important part of collaborating on a project.
GitHub Terms I Keep Coming Across
Once you start using GitHub, you run into all sorts of unfamiliar words.
I'm still learning, too, but here are some of the main ones.
| Term | Beginner-friendly explanation |
|---|---|
| Repository | Where project files and their change history are managed |
| Branch | A way to separate different lines of development work |
| Commit | A recorded snapshot of changes |
| Push | Sending local commits to a remote repository, such as one hosted on GitHub |
| Pull | Bringing changes from a remote repository into your local copy |
| Pull Request | A proposal to merge changes from one branch into another |
| Merge | Combining changes from different lines of development |
| README | A file explaining the project's purpose, usage, or setup |
These terms can sound complicated when you first see them.
But they make more sense when you imagine a team actually working together.
For example, you work on your own branch and commit your changes.
Then you push those commits to GitHub.
Next, you open a Pull Request so your teammates can review what you've done.
If everything looks good, the changes can be merged into main or another target branch.
Of course, that's just one common workflow.
Different teams have different rules, and not every project follows exactly the same process.
What's the Difference Between Working Locally and Working on GitHub?
This is something I'm particularly interested in right now.
Local means the working environment on your own computer—in my case, my Mac.
For example, suppose I edit a project's CSS file on my Mac.
Normally, that change only affects the local file.
It doesn't automatically change the team's files on GitHub.
You'd need to do something else, such as commit your local changes and push those commits to GitHub.
However, AI coding tools can sometimes perform Git operations for you, so it's important to check exactly what they're doing.
And pushing to your own branch is not the same as merging those changes into main.
Using branches is one way to protect a team's shared work.
I'm still cautious because there are operations I don't fully understand yet.
But as I learn how everything works, maybe I'll be able to use GitHub without feeling quite so nervous about it.
Can Anyone Download and Use Code from GitHub?
This question brought me back to something I remembered from 11 years ago.
Back then, I downloaded all kinds of code from GitHub and used it on my own websites.
But now I'm storing my own projects on GitHub.
So does that mean someone else could download something I've made and use it?
I looked into it and learned that GitHub repositories can be Public or Private.
| Setting | Who can see it? |
|---|---|
| Public | Generally, anyone can view and download the code |
| Private | Only the owner and people with the appropriate access permissions can view it |
Interesting!
So I checked my own repositories.
I had 18 in total!
Three were Public, and 15 were Private.
When did I end up creating 18 repositories!? Haha!
But then I had another question.
If something is Public, does that mean anyone can use it however they like?
Apparently, not necessarily.
Being able to see or download code is different from having permission to reuse it freely.
And that's where something called a license comes in.
What Is a GitHub License?
A license sets out the conditions under which other people can use software or code.
Even if a project is publicly available, the creator may specify rules for how it can be used.
One common example is the MIT License.
It allows broad use, including commercial use, modifications, and redistribution, as long as conditions such as keeping the required copyright and license notices are followed.
On the other hand, if a Public repository doesn't have a license, that doesn't automatically mean you can modify its code or incorporate it into your own product however you like.
Just because you can see code on GitHub doesn't mean you're free to do anything with it.
Thinking about that makes those old "Feel free to use!" messages even more memorable.
Of course, when actually reusing code, it's important to check the license and any other applicable permissions rather than relying only on an informal message.
And then there's "Buy me a beer."
I remember being surprised that developers would share their work and give people a way to show their appreciation if they wanted to.
People who share code.
People who use it.
People who improve it.
And people who support the creators.
GitHub can be part of all those connections.
Could I Let Other People Use Something I've Made?
This was another interesting discovery for me.
These days, I use Claude Code and Codex to build all kinds of apps and tools for my own work.
Some of those projects are stored on GitHub.
Of course, some are just for my personal use, and others contain business-related code that I wouldn't want to make public.
But what if I made something and thought, "Hey, this could be useful to other people, too!"?
If I have the necessary rights to the code and it's safe to share, I could make it Public and add an appropriate license so other people can use it.
But there are things I'd need to check first.
Does it contain API keys, passwords, customer information, or confidential business data?
Does it include someone else's code or materials that I'm not allowed to publish?
Could sensitive information still be present in earlier Git commits?
Those are important things to review before making a repository public.
I'm not planning to publish anything new right away.
But someday, I might review my projects and see whether there's one or two that are safe to share and potentially useful to someone else.
Eleven years ago, I was downloading other people's code and thinking, "Wow, how generous!"
Maybe one day I'll be the person saying, "Feel free to use it!"
That's a fun thought.
Is GitHub Required for AI Hackathons?
At my first AI hackathon, having a GitHub account was a participation requirement.
And at my fourth hackathon, we're using GitHub to collaborate as a team.
So for me, GitHub and AI hackathons have become closely connected.
But not every AI hackathon requires GitHub.
Participation requirements and submission formats vary from event to event.
Some events ask participants to submit a GitHub repository URL.
Others may focus more on demo videos, presentation slides, or other deliverables.
That's why it's worth checking the event's official rules before joining.
Still, if you're planning to build apps with AI, learning the basics of GitHub seems pretty useful.
You can use it not only for team development, but also to keep track of changes to projects you're building on your own.
Where Should a Beginner Start?
If you're thinking about joining an AI hackathon, I think simply creating a GitHub account and exploring the interface is a reasonable place to start.
For example:
- Create an account on the official GitHub website.
- Open a public repository and look through its files and README.
- Create a practice repository of your own.
- Try editing a simple file, such as a README.
- Gradually learn what commits and branches do.
If you find interesting code in a public repository, take a look at its README and license, too.
GitHub also lets you download repository files as a ZIP archive, or use Git to copy a repository to your computer.
And if you're joining a team project, it's important to check the team's working rules first.
Which branch should you use?
How should you share changes?
Can you push directly to main, or do you need to open a Pull Request?
If you're not sure, ask a teammate.
I certainly don't understand everything about GitHub yet.
That's why I think practicing in a separate repository is a good idea before trying unfamiliar operations on an important team project.
Eleven Years After Discovering GitHub, I Feel Like I'm Finally Learning to Collaborate
Looking back, it's kind of funny.
About 11 years ago, I was studying web design and downloading free code from GitHub to use on my websites.
My favorites were moving image sliders and unusual photo galleries.
I loved putting those pieces together, and I was amazed that people were willing to share such useful code.
Then I barely touched GitHub for years.
But recently, I started using Claude Code, created a GitHub account, and began joining AI hackathons.
At my first hackathon, I helped complete the README in our team's repository.
At my fourth hackathon, my teammate even created a branch just for me.
It's still GitHub, but the way I'm using it has gradually changed.
And now I'm working with an international team.
There's still plenty I don't know, and I'm careful because I don't want to make a mistake that affects someone else's work.
But through these experiences, I'm starting to understand what GitHub is really for.
And looking into Public and Private repositories and software licenses has given me another perspective I didn't have before.
GitHub isn't just somewhere to store my code.
And it isn't just somewhere teams work together.
It's also a place where people around the world can publish and share code.
Knowing something exists and actually using it are two very different things.
That's another thing I'm glad I've experienced through AI hackathons.
Next, I'd like to become more confident working with my own branch!
And maybe someday, I can share something useful and tell someone else, "Feel free to use it!"
Just like those generous developers did for me 11 years ago.