Git saves your history locally. On your machine. Invisible to everyone else.

GitHub puts that history on the internet.

Now your code is backed up off-site. Now collaborators can contribute. Now recruiters can see your work. Now you can open your project from any computer in the world with one command.

GitHub is not just Git storage. It is your professional portfolio. Every project you build in this series belongs there. By the time you finish Phase 11, your GitHub profile will be a living resume that shows exactly what you can do.

This post sets that up properly.

Create Your GitHub Account

Go to github.com. Create an account. Choose your username carefully. This appears on every repository URL and in every contribution. Use your real name or a professional handle you are comfortable putting on a resume.

After creating the account, set up SSH authentication. This lets you push and pull without entering your password every time.

Generate an SSH key:

ssh-keygen -t ed25519 -C "your@email.com"

Press enter through all prompts to accept defaults. This creates two files:

~/.ssh/id_ed25519      # private key, never share this
~/.ssh/id_ed25519.pub  # public key, this goes to GitHub

Copy the public key:

# Mac/Linux
cat ~/.ssh/id_ed25519.pub

# Windows
type C:\Users\YourName\.ssh\id_ed25519.pub

Go to GitHub → Settings → SSH and GPG keys → New SSH key. Paste the public key. Save.

Test the connection:

ssh -T git@github.com

Output:

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

You are connected.

Creating Your First Repository

On GitHub, click the + icon in the top right → New repository.

Fill in:

• Repository name: ml-practice (use hyphens, not spaces)
• Description: "Machine learning practice projects following the How Machines Learn series"
• Visibility: Public (employers need to see it)
• Do NOT initialize with README if you have a local project already

Click Create repository.

GitHub gives you the commands to connect your existing local project.

Connecting Local to Remote

In your local project folder:

git remote add origin git@github.com:yourusername/ml-practice.git
git branch -M main
git push -u origin main

git remote add origin tells your local Git where the remote repository lives. origin is the conventional name for the primary remote.

git push -u origin main pushes your local main branch to GitHub. The -u flag sets upstream tracking, meaning future git push commands know where to go without specifying again.

Output:

Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Writing objects: 100% (6/6), 542 bytes | 542.00 KiB/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To github.com:yourusername/ml-practice.git
 * [new branch]      main -> main

Refresh your GitHub page. Your code is there.

From now on, after every commit:

git push

That is the entire workflow. Commit locally, push to GitHub.

Writing a README That Actually Helps

Every repository needs a README.md. It is the first thing anyone sees. A bad README makes good code look amateur. A good README makes average code look professional.

# Customer Churn Prediction

A machine learning project that predicts whether a telecom customer will churn based on their usage patterns and demographics.

## Problem

Customer churn costs telecom companies billions annually. This project builds a binary classifier to identify at-risk customers before they leave, enabling targeted retention campaigns.

## Approach

- Exploratory data analysis on 7,000 customer records
- Feature engineering: usage ratios, tenure groups, service combinations
- Models compared: Logistic Regression, Random Forest, XGBoost
- Best model: XGBoost with 89.3% accuracy and 0.91 AUC

## Results

| Model              | Accuracy | AUC  | F1    |
|-------------------|----------|------|-------|
| Logistic Regression | 82.1%  | 0.85 | 0.79  |
| Random Forest       | 87.4%  | 0.89 | 0.86  |
| XGBoost             | 89.3%  | 0.91 | 0.88  |

## Setup

bash
git clone git@github.com:yourusername/churn-prediction.git
cd churn-prediction
pip install -r requirements.txt
jupyter notebook notebooks/analysis.ipynb

## Project Structure

plaintext
churn-prediction/
├── data/ # Raw and processed data (gitignored)
├── notebooks/ # Jupyter notebooks for EDA and modeling
├── src/ # Python modules for data processing and modeling
├── models/ # Saved model files (gitignored)
├── requirements.txt
└── README.md

## Dataset

Telco Customer Churn dataset from Kaggle. 7,043 rows, 21 features.

shell

A README with problem statement, approach, results table, setup instructions, and project structure tells the whole story without opening a single notebook.

The Daily GitHub Workflow

# start of day: get latest changes if collaborating
git pull

# work on your code
# ...

# see what changed
git status
git diff

# stage and commit
git add .
git commit -m "Add feature engineering: tenure buckets and service flags"

# push to GitHub
git push

Every single day. Stage, commit, push. This habit built over months creates the green contribution graph on your profile that shows consistent work. Recruiters look at that graph.

Cloning: Getting Any Repository

Download any GitHub repository to your machine:

git clone git@github.com:username/repository-name.git

Or with HTTPS (no SSH key needed):

git clone https://github.com/username/repository-name.git

This creates a folder with the project inside, with full Git history included. You can clone your own projects to a new machine, clone collaborator projects, or clone any public open-source project to study the code.

Forking: Your Own Copy of Someone Else's Project

A fork is a personal copy of someone else's repository on your GitHub account. You can change it freely without affecting the original.

On GitHub, go to any public repository and click the Fork button. Now you have your own copy. Clone your fork, make changes, commit, push to your fork.

If your changes would benefit the original project, you can open a Pull Request, proposing to merge your changes back. This is how open-source contributions work.

Pull Requests: Proposing Changes

On your own projects with multiple collaborators, or when contributing to open source, pull requests are how changes get reviewed before merging.

Workflow:

git checkout -b add-cross-validation
# make changes
git add .
git commit -m "Add 5-fold cross validation to model evaluation"
git push origin add-cross-validation

On GitHub, a banner appears suggesting you open a pull request. Click it. Write a description explaining what changed and why. Submit.

The repository owner or your team reviews the code. They can comment, request changes, or approve. When approved, the branch merges into main.

Even on solo projects, using pull requests for significant features is good practice. It forces you to write clear descriptions of what you did and why. Your future self reading the git log will thank you.

GitHub Actions: Automate Things When You Push

GitHub Actions runs code automatically when you push. Tests, linting, deployment. A simple example that runs your Python tests on every push:

# .github/workflows/test.yml
name: Run Tests

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'
      - name: Install dependencies
        run: pip install -r requirements.txt
      - name: Run tests
        run: python -m pytest tests/

Every time you push, GitHub spins up a fresh machine, installs your dependencies, and runs your tests. If something breaks, you know immediately before it affects anyone else. This is continuous integration and it is standard practice at every serious company.

Building Your Portfolio: What to Put There

Every project from this series belongs on GitHub with a proper README. By the end of the series you will have:

Phase 1 project: data processor
Phase 3 project: Netflix EDA
Phase 6 project: end-to-end ML pipeline
Phase 7 project: image classifier
Phase 8 project: RAG system
Phase 9 project: deployed AI application
Phase 10 project: AI agent
Phase 11 project: production ML system

That is eight projects covering the full stack from data cleaning to production deployment. Each with code, README, and visible commit history.

That portfolio, built publicly over time, is worth more than any certification.

Profile README: Your GitHub Homepage

Create a repository with the same name as your GitHub username. The README.md inside it appears on your GitHub profile page.

# Hi, I'm Alex

Building AI systems from data to production.

**Currently working on:** RAG systems and AI agents

**Tech stack:** Python | PyTorch | LangChain | FastAPI | PostgreSQL

**Projects:**
- [Churn Prediction](link) — XGBoost model, 89% accuracy
- [Netflix EDA](link) — Exploratory analysis of 8000+ titles
- [Customer Data Processor](link) — End-to-end data pipeline

**Writing:** howmachineslearn.com

📫 alex@email.com | [LinkedIn](link)

Add your actual projects as you build them. A profile README with real project links is one of the first things a hiring manager looks at.

A Resource Worth Reading

GitHub itself publishes GitHub Skills at skills.github.com, a series of interactive courses where you complete real tasks in actual repositories. The "Introduction to GitHub" and "Communicate Using Markdown" courses are free, take under an hour each, and give you hands-on experience with the pull request workflow. Worth doing immediately after this post.

Tom Preston-Werner, GitHub's co-founder, wrote a piece called "Readme Driven Development" arguing that writing a README before writing any code forces you to think clearly about what you are building. It influenced how the entire open source community thinks about project documentation. Search "Tom Preston-Werner Readme Driven Development."

Try This

If you have not already, create your GitHub account and set up SSH keys following the steps in this post.

Create three repositories. One for each of the first three phases of this series. For each:

Initialize a local project folder with git init. Add the code you have written so far for that phase. Write a proper README.md with what the project does, what you learned, and how to run it. Add a .gitignore. Make at least three commits with clear messages. Push to GitHub.

Then create a profile README repository. Write a short bio, list your three projects with links, and describe what you are currently learning. Make it something you would not be embarrassed to show a potential employer.

Bookmark your GitHub profile URL. You will be updating it for the next several months.

What's Next

Your code is online. Two more tools in Phase 5. Jupyter notebooks for interactive development, then Google Colab for free GPU access. Both are how you will run the machine learning and deep learning code in the second half of this series.