GitHub: Put Your Work Where Anyone Can See It

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.

Read full story →