Git Basics

Soon you will fork your portfolio starter. From that point on, each module project will follow the same workflow: fork a starter repo, create a branch, make your changes, and open a pull request. This lesson teaches that workflow step by step. You’ll learn the key terms you will see often and the core commands you will use on every project. Later, we will go deeper into how Git works; for now, the goal is to help you feel confident following project instructions like “fork the starter and work on a branch."

What a fork is

A fork is your own personal copy of someone else’s repository on GitHub.

This is the word that trips people up most, so it is worth being precise. When you fork a project, GitHub makes a complete copy of it under your own account. That copy is yours. You can change anything in it, and the original is never touched. The person who created the starter does not see your changes, and you cannot accidentally break their version.

This matters for every project you build here. You start from a starter that someone else set up, and forking is how you get your own copy to build on. You always work in your fork, never in the original.

Fork and clone a starter

A fork lives on GitHub, on the internet; to actually edit the files, you need them on your own computer, and cloning is how you bring them down. There are two ways to do the fork-and-clone, and they end in the same place — pick whichever fits you.

In the browser

Open the starter repository’s page on GitHub and select Fork in the top right. GitHub creates a copy under your account, at a URL like https://github.com/your-username/phase1-starter. That is now your repository.

Then clone it to your machine. Copy your fork’s URL from its GitHub page (the green Code button), and run, replacing your-username with your GitHub username:

git clone https://github.com/your-username/phase1-starter.git
cd phase1-starter

With the GitHub CLI

If you have the GitHub CLI installed, you can fork and clone in one command, without leaving the terminal. gh repo fork forks the repository to your account, and the --clone flag clones your new fork in the same step:

gh repo fork OWNER/phase1-starter --clone
cd phase1-starter

Replace OWNER with the account the starter lives under. This is the same fork-then-clone as the browser path, collapsed into one line.

Either way you end up in the same place: your own copy on GitHub, and a local clone you can open in your editor. The order is always the same — fork to get your own copy on GitHub, then clone to bring that copy to your computer.

Work on a branch

A branch is a separate line of work inside your repository. The main line is called main, and it holds the version of your project that works. When you build something new, you do it on a branch so that the half-finished work never touches main — if the new work breaks, main is still fine.

Every project in this path asks you to work on a branch named for the module. Create one and switch to it in a single command:

git checkout -b m1-package-setup

The -b creates the branch and moves you onto it. From here, every change you make and save belongs to m1-package-setup, not to main. You can build freely: main stays exactly as it was until you decide to bring your branch back into it.

Commit and push your work

As you edit files, you save your progress into the project’s history by making a commit. A commit is a labeled snapshot of your work at a moment in time. You choose what goes into it, then write a short message describing the change:

git add .
git commit -m "Add data loader and package skeleton"

git add . selects every change you have made; git commit records them as one snapshot with your message. So far this history lives only on your computer. To send it up to your fork on GitHub, you push it:

git push -u origin m1-package-setup

The first push of a new branch uses -u origin m1-package-setup to connect your local branch to your fork; after that, git push alone is enough. Commit often as you work — each commit is a point you can return to.

Open a pull request

A pull request is how you bring a finished branch back into main. It is a page on GitHub that shows everything your branch changed and lets you merge it once the work is ready.

After you push your branch, GitHub shows a Compare & pull request button on your fork’s page. Select it, confirm the request is merging your branch (m1-package-setup) into your main, add a short description, and create it. When the work meets the project’s rubric, select Merge pull request. Your branch’s work is now part of main, which once again holds a complete, working version of the project — now with the module’s work added.

For the next module, you branch off this updated main and repeat. Because you carry the same repository through every module project, main is your project growing one reviewed branch at a time.

The whole loop, once

Here is the entire workflow a project asks for, start to finish:

# 1. Fork the starter to your account (the Fork button on GitHub, or `gh repo fork`).

# 2. Clone your fork to your computer:
git clone https://github.com/your-username/phase1-starter.git
cd phase1-starter

# 3. Branch for the module:
git checkout -b m1-package-setup

# 4. Build, then save and share your work (repeat as you go):
git add .
git commit -m "Describe what you changed"
git push -u origin m1-package-setup

# 5. On GitHub: open a pull request, then merge it into main when it is ready.

Every module project is this same loop with a different branch name. Once it is familiar, it disappears into the background and you think about the project, not the git commands.

Where this goes next

This is everything you need to fork a starter, build on a branch, and submit a project. Next is Set Up Your Environment — optional, for anyone who wants to install the tools these commands run inside — and then Your Portfolio Site, the first repository you will fork and clone for real. Further on, the first module, Python for ML Engineers, has a full lesson on git that explains why this works — what a commit really is, how branches stay isolated, and the failure modes to avoid when work is shared. Treat this lesson as the moves and that one as the understanding behind them.

The best way to make branches and merges click is to play with them, and two free interactive sites are built for exactly that:

  • Learn Git Branching — type real git commands and watch the commit tree move; the clearest way to see what a branch, a merge, and a rebase actually do.
  • Oh My Git! — an open-source game that teaches git by playing it, good for building intuition before the commands feel routine.

If you would like to read more, two references are worth bookmarking: