*GitHub has a reputation as a programmers' club. It is really a filing cabinet with a memory, and the day an AI writes your first script, you need one.*
Everyone in supply chain seems to agree on one thing about GitHub: it is for programmers.
That was true for a long time. Then the way code gets written changed. In 2026 a planner describes a weekly report to Claude or Copilot and a script appears. A buyer asks for a tool that reads supplier confirmations and gets one. The code works, and it lives in a folder called "new version final".
That folder is the problem GitHub solves, and it has nothing to do with being a programmer. GitHub keeps every version of a set of files, records who changed what and why, and lets two people work on the same files without emailing attachments. Developers needed that first. Anyone who builds with AI needs it now.
This post explains what GitHub is, how to set it up, what the daily routine looks like, and walks through one example: a shipment CO2 report at a fictional bicycle maker.
What GitHub is
Two things with similar names get mixed up, so let me separate them.
Git is a version control system: a free, open-source program on your computer that tracks changes to files. Linus Torvalds and the Linux community wrote it in 2005, after the tool they used for the Linux kernel stopped being free. It was built for speed, thousands of parallel branches and no central server, and it needs no internet connection.
GitHub is a website, launched in April 2008, that hosts Git repositories in the cloud and adds what Git lacks: a shared copy everyone can reach, a page for reviewing changes, issues for tracking work, and automation. Microsoft bought it in 2018 for $7.5 billion. By GitHub's own count, in its Octoverse report of October 2025, it has more than 180 million developers and 630 million repositories.
Five words cover most of what you will do:
- Repository (repo): one project's folder, with its complete history.
- Commit: a saved snapshot of the files, with a short message saying why.
- Branch: a parallel copy inside the repository, where you try a change without touching the original.
- Pull request: "I changed this, please look." A page that shows the exact lines that changed, with a merge button.
- Push and pull: send your commits up to GitHub, and fetch what others have sent.
Everything in this post works on the Free plan, which today lists unlimited public and private repositories and 2,000 minutes a month of automation. The Team plan is $4 per user per month for the first 12 months. Copilot, GitHub's AI assistant, is a separate add-on.
What it means for supply chain
You already do version control. You do it with file names.
| The spreadsheet habit | What Git calls it | What you gain |
|---|---|---|
| Save as forecast_v7_FINAL2.xlsx | A commit with a message | The reason for the change travels with the change |
| Email the file to a colleague | Push, and they pull | One copy, and no "which version do you have?" |
| "Who changed this cell?" | History | Every change, with who, when and why, for ever |
| Copy the file before you try something | A branch | The original is never at risk |
| "Can you check this before I use it?" | A pull request | The reviewer sees only the lines that changed |
| Dig out last month's version | Checkout | Any version, in seconds, with no digging |
Once that mapping clicks, the use cases are obvious.
The scripts an AI wrote for you. Claude Code, Codex and Copilot write files, and speak Git natively, so GitHub is where those files stop being disposable.
A number you can reproduce. The forecast you showed at S&OP came from one version of the script and one week's extract. Six months later you can rerun exactly that version.
Prompts and SQL, not just code. A prompt library or a set of queries is text, and Git tracks text well. Every change to the prompt that sorts your exception messages gets a date, an author and a reason.
Reports that run themselves. GitHub Actions runs a script on a timer, so nobody has to remember Monday morning.
A place to say no to an agent. When an AI agent changes your tool, the pull request is where you read what it did and accept or reject it.
The quickest way to see all this is to do it once. Setup first, then the routine, then the example.
Setting it up in twenty minutes
The account (five minutes). Go to github.com/signup and follow the prompts. Verify your email address, because without it you cannot create a repository, and switch on two-factor authentication while you are there.
Your tool (ten minutes). Three options, and the first needs nothing installed.
- The browser only. GitHub's Hello World tutorial needs no coding, no command line and no Git installation: you create a repository, edit files, branch, open a pull request and merge on the website.
- GitHub Desktop. A free, open-source app for macOS 12 or later and Windows 10 64-bit or later, from desktop.github.com. Sign in under Settings on a Mac or File, Options on Windows, then Accounts, "Sign Into GitHub.com". This is the one I would pick for working with files on your own machine.
- The command line. For people who already use a terminal, or whose AI coding tool does. Claude Code and Codex run the Git commands; you only need to read them.
The company check (five minutes). Ask IT whether your company has its own GitHub and what the rule is for company data on public services. Make repositories private by default. More on that in the traps.
Running it: the daily loop
Most days the routine is four moves.
- Pull before you start, so you have your colleagues' changes.
- Work. Edit the script, the prompt or the CSV, or let the AI do it.
- Commit with a message that says why: "Use the rail factor on the Lyon to Milan lane", not "update".
- Push.
When a change is bigger, or someone else should check it, wrap a loop around it: create a branch, commit on it, push the branch, open a pull request, get it reviewed, merge, delete the branch. In GitHub Desktop that is "New branch", commit, "Publish branch" and "Create pull request". In the browser it is the five steps of the Hello World tutorial.
The habit that matters more than any tool: small commits, often, with messages that read like a logbook.
Worked example: a shipment CO2 report at Upshift
Upshift is a fictional bicycle maker with two plants and five distribution hubs. The logistics lead at the Lyon hub asked an AI assistant for a Python script that reads a weekly CSV of shipments and writes a CO2 summary per lane. It works, it lives on her laptop, and the Antwerp hub has a slightly different copy.
Step 1: create the repository. On github.com, click "+", then "New repository". Name it shipment-co2, choose Private, tick "Add a README file" and click "Create repository". In GitHub Desktop the same thing is File, "New repository", then "Publish repository" with "Keep this code private" ticked.
Step 2: add the files and commit. Three files go in: the script, a small table of emission factors per transport mode, and twenty illustrative shipment rows for testing.
lane,mode,tonnes,km
Lyon-Milan,road,4.2,460
Lyon-Milan,rail,18.0,470
Antwerp-Lyon,road,6.5,780Commit them with the message "Add weekly CO2 report script with sample data" and push. GitHub now shows the files, the README and "1 commit". From a terminal the same step is six commands, in the order GitHub's own guide gives:
git init -b main
git add .
git commit -m "Add weekly CO2 report script with sample data"
git remote add origin https://github.com/YOUR-NAME/shipment-co2.git
git remote -v
git push -u origin mainStep 3: a colleague improves it. The Antwerp hub lead clones the repository, creates a branch called rail-factor-update, and makes two commits. The first changes one line in the factors table, from an illustrative 0.028 to 0.022 kg CO2e per tonne-kilometre for rail, with the source named in the commit message. The second adds a check to the script that rejects any shipment with zero kilometres. Then he opens a pull request: "Update rail factor and reject zero-km rows".
Step 4: review and merge. The pull request shows one changed line in the factors table and six in the script, old lines in red and new in green. The Lyon lead asks in the comments where the new factor comes from, gets a link, and clicks "Merge pull request", "Confirm merge" and "Delete branch". Her next pull brings the change to her laptop. Nobody emailed an attachment, and the discussion about the factor now sits on the change itself.
Step 5, optional: let GitHub run it. A short workflow file in a folder called .github/workflows tells GitHub to run the script every Monday at 05:30 UTC and keep the output.
name: Weekly CO2 report
on:
schedule:
- cron: "30 5 * * 1"
jobs:
report:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- run: python co2_report.py sample_shipments.csv > report.txt
- uses: actions/upload-artifact@v7
with:
name: co2-report
path: report.txtThe schedule uses the five-field cron format and runs on the default branch; the shortest interval GitHub allows is five minutes. A two-minute weekly run uses about nine of the 2,000 free minutes a month.
What to notice: after four commits and one pull request, the repository tells the whole story. Which rail factor was used, since when, on whose say-so, with which source. When the quarterly sustainability report quotes a CO2 figure, it can point at the exact version of the script and data that produced it. That is the difference between a number and a defensible number.
What it can't do, and the traps
- A pushed file is in the history for good. Deleting it in the next commit does not remove it from earlier ones. Never commit passwords, API keys or customer lists. Private repositories by default, and company data only where IT says so.
- Git cannot see inside Excel. It compares text, so a spreadsheet shows up as "changed", never as which cell. Keep the logic in scripts and the data in CSV, and treat Excel as output. Files over 50 MiB get a warning, over 100 MiB are blocked, and GitHub asks you to keep a repository under 1 GB.
- Two people, one line. When two commits change the same line, Git stops and asks you to choose. That is a merge conflict, and the moment beginners give up. Paste it into your AI assistant, which resolves these well, and pull often to avoid most of them.
- The vocabulary wall. Origin, HEAD, rebase, fork, stash. Ignore them for the first month. The five words above carry you a long way.
- Vendor and policy. GitHub belongs to Microsoft, and some companies use GitLab or Azure DevOps instead. The skills transfer, because Git is the same underneath, and every clone holds the full history, so a repository can move.
Put one script on GitHub this week
Take the last script or prompt an AI wrote for you. Make a private repository, add the file, and commit it with a message that says what it does and where its data comes from. Twenty minutes, and the thing you built has a home and a history.
Supply chain people have always been the ones who kept the records: the bin card, the goods-received book, the change log on the drawing. Git is the same instinct, applied to the tools we now build ourselves.
What is the oldest "final" file on your drive, and how many copies of it live in your team's inboxes?
Sources
- About GitHub and Git (GitHub Docs)
- A short history of Git (Pro Git book)
- About Git (git-scm.com)
- GitHub (Wikipedia): founding and the Microsoft acquisition
- Octoverse 2025: a new developer joins GitHub every second (GitHub Blog)
- GitHub pricing
- Creating an account on GitHub (GitHub Docs)
- Hello World (GitHub Docs)
- Getting started with GitHub Desktop (GitHub Docs)
- Installing GitHub Desktop (GitHub Docs)
- Adding locally hosted code to GitHub (GitHub Docs)
- Events that trigger workflows: schedule (GitHub Docs)
- About large files on GitHub (GitHub Docs)
- actions/checkout releases and actions/upload-artifact releases
