Git and GitHub for AI projects
Git is a version control system that tracks every change to your code, and GitHub is the platform where you store those repositories, work with other people and show your work. For AI projects, the extra rules are about what never goes into Git: API keys and .env files, virtual environments, large datasets and model weights. Commit small changes with clear messages, work on branches, open pull requests, and write a README that lets a stranger run your project, because your GitHub profile is often the first thing a recruiter or client sees.
What version control solves
Think of a team building one product. One person works on the landing page, another on the backend, someone else on a set of APIs, and another developer on different APIs in the same backend. Everyone writes code at the same time, and the team needs to know who changed what, when and why, and needs to put all those changes together without losing anyone's work.
That is what version control does. You already know versions from software you use: Windows XP, then 7, then 10 and 11, or Python 2.7, then Python 3, then 3.10 and 3.10.12. Each version is the state of the code at one point in time, and Git records those states for your project, at a much finer level, every time you save a meaningful change.
Every company that builds software expects you to know Git. It is not an extra skill on a resume anymore, it is assumed.
Git and GitHub are different things
Git is the tool. It runs on your machine, tracks the changes in a folder and keeps the full history of the project.
GitHub is a platform built around Git. It hosts your repositories online so your team can work on the same code, adds issues, pull requests, code review and automation, and gives you a public profile where you can share your work with the world. GitLab and Bitbucket are alternatives, and Hugging Face plays a similar role for models and datasets.
You can use Git through a graphical interface, but most developers use the command line, because it is faster and works the same way everywhere, including on servers where there is no interface at all. On Windows, Git Bash gives you that command line.
Three places your changes live
To understand Git, you need to know the three places a change goes through.
- Working directory: the files as they are on your disk right now, including changes you haven't saved in Git yet.
- Staging area: the changes you have selected for your next commit, using
git add. - Repository: the history of commits, saved with
git commit.
Think of commits as checkpoints in a game. If something goes wrong later, you can go back to the last checkpoint instead of starting over. The staging area is how you choose what goes into a checkpoint, so you can save the header of a web page as one commit and the footer as another, even if you changed both.
Your first repository
git init
git status
git add README.md app/
git commit -m "Add FastAPI app with health endpoint"
git branch -M main
git remote add origin https://github.com/your-username/your-repo.git
git push -u origin main
git status is the command you will run most.
It tells you which branch you are on, which files changed, which are staged and whether you are ahead of or behind the remote repository.
To get an existing project onto your machine, clone it:
git clone https://github.com/your-username/your-repo.git
To undo things:
git restore file.pythrows away uncommitted changes to a file.git restore --staged file.py(orgit reset file.py) moves a file out of the staging area without losing your changes.git revert <commit>creates a new commit that undoes an old one, which is the safe way to undo something already pushed.
Commit messages
Always write a message that says what changed and, when it isn't obvious, why. Your future self, your team and the person reviewing your portfolio will read these.
"update" and "fix" tell nobody anything. "Add retry with backoff to LLM client" or "Fix chunker dropping the last paragraph" tells the whole story.
Commit small, related changes together. If one commit adds a feature, fixes an unrelated bug and reformats three files, it is very hard to review and impossible to undo partly.
Branches
The main branch is the version of the project that works, the one that is deployed or shared with the world. You don't experiment on it.
Think of the project as a tree. The main branch is the trunk, and every new feature, fix or experiment grows on its own branch. When the work on a branch is ready and reviewed, it is merged back into main. In a team, the project lead or a senior engineer decides what gets merged, so main never breaks.
git switch -c add-reranking
git add .
git commit -m "Add cross-encoder reranking after retrieval"
git push -u origin add-reranking
For AI projects, branches are especially useful for experiments, like trying a new chunking strategy or a different prompt, because you can compare the results and simply delete the branch if the experiment didn't help.
Pull requests and code review
A pull request (PR) is a request to merge a branch into main. On GitHub, it shows every change, lets others comment on specific lines, runs automated checks, and records the discussion.
For AI changes, a good pull request also says how you checked the change: which test cases or eval set you ran, and what changed in the results. "Changed the system prompt" is not enough. "Changed the system prompt, ran the 40 question eval set, accuracy went from 31 to 35 correct, two answers got worse, details below" is a pull request someone can review.
Contributing to open source
The same flow is how you contribute to someone else's project:
- Fork the repository, which copies it to your own GitHub account.
- Clone your fork to your machine.
- Create a branch for your change.
- Make the change, commit it and push it to your fork.
- Open a pull request to the original repository.
- The maintainer reviews it, asks for changes or merges it, and you appear as a contributor.
Most projects have a CONTRIBUTING.md file that explains their rules, and issues labelled "good first issue" are made for new contributors. Contributing, even a documentation fix or a test, teaches you how real projects are organised, and it is visible work on your profile.
What never goes into Git in AI projects
This is where AI projects differ most from ordinary ones.
- API keys and
.envfiles. Once a key is pushed to a public repository, assume it is compromised, even if you delete it a minute later, because automated scanners read public commits within minutes and the key stays in the Git history. - Virtual environments. Commit
requirements.txt, not thevenvfolder. - Large datasets. Git is built for text files, and big binary files make every clone slow.
- Model weights and checkpoints. Store them on Hugging Face, in cloud storage or with Git LFS.
- Generated files:
__pycache__, logs, vector indexes, notebook checkpoints.
A .gitignore file in the root of your repository tells Git to never track these.
.env
venv/
.venv/
__pycache__/
*.pyc
.ipynb_checkpoints/
data/
models/
*.safetensors
*.bin
*.ckpt
logs/
*.jsonl
chroma/
.DS_Store
Adjust it for your project, for example by keeping a small sample dataset or an eval set that you do want in the repository.
GitHub now blocks pushes that contain known types of secrets by default for public repositories, through a feature called push protection. It is a useful safety net, but it doesn't recognise every kind of key, so don't depend on it.
If you do push a key, rotate it first, meaning revoke it in the provider's dashboard and create a new one, and only then clean the history. Deleting the file doesn't help, because the old commit still contains the key.
A README that people read
The README is the front page of your project. For an AI project, it should answer, in this order:
- What problem does this solve, and for whom?
- A demo: a link, a GIF or a screenshot of it working.
- How it works: a simple architecture diagram and the main components.
- How to run it: the exact commands, the environment variables needed (with a
.env.examplefile), and the Python version. - How you checked it works: your tests or eval results.
- What broke while building it and how you fixed it.
- Limitations and what you would do next.
Sections 5 to 7 are what most READMEs skip, and they are what makes a hiring manager or a client believe you understand what you built.
Issues and project management
GitHub issues are not only for bugs. You can use them to plan the work on a project: create an issue for each task, assign it to a person, label it, and link the pull request that solves it. In our cohorts, we create issues for parts of a project and assign them to different builders, so everyone contributes to one codebase the way a real team does.
Your GitHub profile
Your GitHub profile is your portfolio, and for many roles it matters more than your resume, because it shows your actual work.
A few things make a big difference:
- A real, professional profile picture, so the profile looks like a person and not a spam account.
- A profile README: create a repository with exactly the same name as your username, and its README appears at the top of your profile. Use it to say what you build, your main skills and how to contact you.
- A clear headline and bio with the role you are targeting and your top skills, because people find profiles through search.
- A description on every repository you pin, so a recruiter understands each project in one line.
- Pinned repositories with your best 4 to 6 projects, each with a strong README.
- Regular commits, because consistent activity over months tells its own story.
You don't need perfect projects to start. Show your work at whatever level you are, grow a little every day, and keep showing it, because very few people do this consistently, and nobody else has your story.
From the floor
In the 75 day challenge, Git and GitHub were on day 3, after Python and the terminal. I told everyone that every day's work would go into a repository from that day on, because the last part of the challenge was marketing your work, and you can't market work nobody can see.
I have received job offers through my GitHub profile, and I made a video about building that profile, because I spent many hours figuring out which tools and steps made a difference and didn't want others to repeat that.
When we build projects in our cohorts, the repository has a CONTRIBUTING.md with the exact flow: fork, clone, create a branch, commit, push and open a pull request, and I review it, give feedback and merge it, so every builder ends up listed as a contributor on a real project.