Git Commands

This page covers the Git commands you’ll use almost every day, and what each one actually means in plain English. If you haven’t installed Git yet, start with the Git setup guide.

The Big Picture

Before diving into commands, it helps to picture where your work lives. Think of it like working on a group project at an office:

• Your local workspace is your own desk. It’s the copy of the project on your computer. Nobody else can see what’s on your desk.
• The remote workspace is the shared filing cabinet everyone on the team uses. For us, that’s the repository on Codeberg. When we say origin, we mean this filing cabinet.
• Branches are separate folders for separate drafts. The main branch is the official, finished copy. When you work on something new, you make your own folder so you don’t scribble on the official copy while you’re still figuring things out.
• Commits are save points. Every time you commit, you put a labeled snapshot of your work in the folder, so you can always look back at (or go back to) exactly what it looked like at that moment.

Almost every Git command is just moving work between your desk, the filing cabinet, and different folders.

Cheat Sheet

Command	In plain English
git clone <url>	“I’m making my own copy of the project to work on.”
Forking (on Codeberg)	“I’m making my own copy of the whole filing cabinet.”
git pull	“I’m updating my local workspace with everyone else’s latest work.”
git branch	“Which folders exist, and which one am I working in?”
git checkout <branch>	“I’m switching to a different folder.”
git checkout -b <branch>	“I’m starting a new folder for a new piece of work.”
git commit -am "<message>"	“I’m checking in my work.”
git push --set-upstream origin <branch>	“I’m putting my new folder in the shared filing cabinet for the first time.”
git push	“I’m putting my work into my remote workspace.”
git merge <branch>	“I’m combining another folder’s work into the one I’m in.”

Getting the Project

git clone: “I’m making my own copy of the project to work on.”

Cloning is like going to the shared filing cabinet and photocopying the entire project, including its full history, onto your desk. You only do this once per project. After that, you use git pull to stay up to date.

To get the address, open the repository on Codeberg, click the SSH option next to the clone button, and copy the link.

Clone a repository

git clone <REPOSITORY_URL>

Example:

Clone a repository example

git clone git@codeberg.org:Example-Org/example-project.git

This creates a new folder with the project’s name in whatever folder your command line is currently in.

Forking: “I’m making my own copy of the whole filing cabinet.”

git fork is not actually a Git command. Forking is something you do on the website (Codeberg, GitHub, etc.), not on the command line.

If cloning is photocopying the project onto your desk, forking is getting your own filing cabinet with a copy of the project inside it. It lives on Codeberg under your account, and you can push whatever you want to it without needing permission from the original project.

You fork when you want to contribute to a project you don’t have permission to push to directly. To fork:

1. Open the repository on Codeberg.
2. Click the Fork button in the top right.
3. Once your fork is created, clone your fork (not the original) to get it onto your computer.

git pull: “I’m updating my local workspace with everyone else’s latest work.”

While you were away, your teammates have probably been putting new work in the filing cabinet. Pulling grabs everything new from the remote workspace for the folder you’re in and adds it to the copy on your desk.

Pull the latest changes

git pull

Get in the habit of pulling before you start working. The longer you work on an old copy, the more likely your work and someone else’s will clash later.

Working With Branches

git branch: “Which folders exist, and which one am I working in?”

Running git branch on its own lists all the branches on your desk. The one with a * next to it is the one you’re currently in.

List branches

git branch

Example output:

  add-login-page
* main
  fix-typo

Here, you’re currently working in main.

git checkout <branch>: “I’m switching to a different folder.”

Checking out a branch is like putting away the folder you’re working in and opening up a different one. The files on your computer change to match whatever is in that folder.

Switch to a branch

git checkout <BRANCH_NAME>

Example:

Switch to a branch example

git checkout main

Commit your work before switching. If you have unsaved changes that would clash with the other branch, Git will refuse to switch and tell you so. That’s Git protecting your work, not an error you broke something with.

git checkout -b <branch>: “I’m starting a new folder for a new piece of work.”

The -b means “make a new branch, then switch to it.” It’s like grabbing a fresh folder, putting a copy of your current draft inside, labeling it, and opening it, all in one step.

The new branch starts as a copy of whatever branch you’re currently in, so you’ll usually want to be on an up-to-date main first.

Create and switch to a new branch

git checkout -b <NEW_BRANCH_NAME>

Example:

Create a new branch example

git checkout -b add-login-page

Name your branch after what you’re working on. Use dashes instead of spaces, since branch names can’t have spaces in them.

Saving and Sharing Your Work

git commit -am "<message>": “I’m checking in my work.”

Committing is creating a save point. It’s like taking a snapshot of your folder and writing a sticky note on it describing what you changed. The snapshot only lives on your desk until you push it.

Commit your changes

git commit -am "<WHAT_YOU_CHANGED>"

Example:

Commit your changes example

git commit -am "Add a login button to the home page"

The two letters in -am each do something:

• -a means “include all the files I’ve changed.”
• -m means “here’s my message,” followed by the message in quotes.

Brand new files are not included by -a. It only picks up files Git already knows about. If you created a new file, tell Git about it first with git add, then commit:

Commit including new files

git add .
git commit -am "Add the login page"

The . in git add . means “everything in this folder.”

Write messages that describe what you changed, so anyone flipping through the snapshots later knows what each one is. “Fix typo on home page” is helpful. “stuff” is not.

git push --set-upstream origin <branch>: “I’m putting my new folder in the shared filing cabinet for the first time.”

When you make a new branch with git checkout -b, it only exists on your desk. The filing cabinet doesn’t know about it yet. The first time you push a new branch, you have to tell Git where it should go:

• origin is the shared filing cabinet (your remote on Codeberg).
• <branch> is the name of the folder you’re putting in it.
• --set-upstream tells Git to remember this, so next time you can just type git push.

Push a new branch for the first time

git push --set-upstream origin <BRANCH_NAME>

Example:

Push a new branch example

git push --set-upstream origin add-login-page

You only need to do this once per branch. If you forget and just run git push on a new branch, Git will print an error that includes this exact command for you to copy.

git push: “I’m putting my work into my remote workspace.”

Pushing takes all the commits (save points) you’ve made on your desk and puts them in the shared filing cabinet, so your teammates can see them. If you haven’t pushed, nobody else can see your work, no matter how many times you’ve committed.

Push your commits

git push

If Git refuses to push and says something about the remote containing work you don’t have, it means someone else pushed to the same branch since you last pulled. Run git pull first, then push again.

git merge <branch>: “I’m combining another folder’s work into the one I’m in.”

Merging takes the work from another branch and combines it into the branch you’re currently in. It’s like taking the pages from someone else’s folder and adding them into yours.

The direction matters: git merge <branch> pulls the named branch into the branch you’re currently on. Double-check which branch you’re on with git branch before merging.

Merge a branch into your current branch

git merge <BRANCH_NAME>

A common use is keeping your branch up to date with everyone else’s finished work:

Bring the latest main into your branch

git checkout main
git pull
git checkout add-login-page
git merge main

If you and someone else changed the same lines of the same file, Git can’t decide whose version to keep, and you’ll get a merge conflict. Git will mark the clashing spots in the file for you to fix by hand. VS Code highlights these and gives you buttons to pick which version to keep. Once they’re fixed, commit to finish the merge.

Putting It All Together

Here’s what a typical day of work looks like, from start to finish:

A typical workflow

# Start from the official copy, and update it
git checkout main
git pull

# Start a new folder for your work
git checkout -b add-login-page

# ...make your changes...

# Check in your work
git add .
git commit -am "Add the login page"

# Put your new folder in the shared filing cabinet
git push --set-upstream origin add-login-page

# ...make more changes...

# Check in and share again (no --set-upstream needed this time)
git commit -am "Style the login button"
git push

Once your work is pushed, you’ll usually open a pull request on Codeberg to ask for your branch to be merged into main, so someone can review it first.

Further Reading

• Pro Git book (free)
• Official Git documentation
• Codeberg documentation