Git for beginners: save your progress, one step at a time

1. Git keeps checkpoints. GitHub holds a shared copy.

Git is a tool that records the history of a project. You choose when to create a checkpoint, called a commit. Each commit records a snapshot and a message explaining what changed. Later, you can compare versions, inspect an older one, or undo a committed change.

GitHub is an online service where you can keep a copy of a Git project and collaborate with other people. Git runs on your computer and can record commits offline. You need a connection when you send those commits to GitHub.

A repository, usually shortened to repo, is your project and its Git history. Local means the copy on your computer. Remote means another copy, often hosted on GitHub. These words will come up a lot, but that’s all they mean here.

ON YOUR COMPUTER

Git

The tool that keeps your project’s checkpoints.

ONLINE

GitHub

A place for a remote copy, reviews, and collaboration.

2. The everyday loop: edit, stage, commit, push

Saving a file and making a commit are separate actions. Save writes your edits to the file. Commit records a checkpoint in Git. Push sends your commits to the remote copy.

Staging is the choosing step in between. Say you edited five files, but only two belong in this checkpoint. You stage those two. Git records the staged content when you commit. If you edit a file again after staging it, stage the newer changes too.

3. Start with a visual app

You can use Git through buttons instead of typed commands. For this exercise, use GitHub Desktop on macOS or Windows. The official download and setup links are at the end of this post. On Linux, use the terminal route below.

Create a GitHub account, install GitHub Desktop, and sign in. During setup, choose the name and email attached to your commits. Your GitHub no-reply email is an option if you prefer to keep your personal address private.

In Desktop, choose File → New repository. Name it my-first-repo, pick a local folder you can find, and check Initialize this repository with a README. Then create the repository. A README is a text file that explains the project. Here, it gives us something simple to edit.

If you already have a project on GitHub, clone it instead. Clone means download a working copy with its Git history. Use File → Clone repository and choose the project and local folder. Don’t create a second new repository inside an existing one.

4. Make your first commit

Open your new repository folder in a text editor. Open README.md, add “Welcome to my site.” on a new line, and save the file. This is our whole change. You do not need to build an actual website.

Return to GitHub Desktop. In Changes, leave README.md checked. Read the comparison on the right. This is called a diff: it shows what changed. A plus sign and green usually mean a line was added; a minus sign and red mean a line was removed.

Type “Add a welcome message” in the Summary field. Click Commit to main. Here, main is the branch you are working on. Open History and you should see your new checkpoint.

5. Send that checkpoint to GitHub

For this new repository, click Publish repository. Keep Keep this code private checked for practice, then publish it. After future commits, the button you’ll usually use is Push origin.

Origin is the usual nickname for the linked remote repository. Push origin means send your local commits to that copy. Open the repository on GitHub and confirm your welcome text is there. That is your proof that the commit made it across.

Push does not, by itself, publish a website. A hosting service may be configured to deploy when you push, but that is a separate setup. Follow your project’s deployment rules when working on a real site.

6. Give an experiment its own branch

A branch is a separate line of work in the same repository. Imagine you want to try a different welcome message. Create a branch called new-headline from main. You can commit the experiment there while main keeps its existing committed version.

In Desktop, start on main and use Branch → New branch to create new-headline. Make your edit, review it, and commit. Publish or push that branch. On GitHub, open a pull request from new-headline into main to propose the changes.

A pull request, or PR, is a place to review and discuss a proposed change. Opening one does not automatically combine the branches. After review and any required checks, merge combines the work. Then switch back to main locally and fetch and pull the updated version.

Before switching branches, commit your work or use the app’s stash option to set it aside. Branches are useful, but project rules come first: some projects intentionally work directly on main.

7. Pull and pull request mean different things

Before starting another work session, check for incoming changes. Save and commit any unfinished work before pulling. If Git cannot combine the histories automatically, pause and read what it needs instead of repeatedly clicking sync.

8. Optional: try the same thing in a terminal

A terminal is a window where you type instructions. Use Terminal on macOS, Git Bash on Windows, or a Linux terminal. Install Git from the official link below, then run git --version to check it is available.

Set the name and email recorded on your commits once. Replace the example values below with yours. These settings label your commits; they do not log you in to GitHub.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Create a small practice project

Run these lines one at a time in a folder outside your existing projects. mkdir creates a folder, cd moves into it, and git init starts Git history. Use a new folder name if my-git-practice already exists.

mkdir my-git-practice
cd my-git-practice
git init -b main

Save, select, and record your change

In your text editor, create README.md inside my-git-practice, type “Welcome to my site.” and save. Return to the terminal in that folder. Run the commands below one at a time.

Status tells you what Git sees. At first, README.md is untracked, meaning it is not in Git history yet. Add stages the file. Diff --staged shows the selected content. Commit records it, and log shows your history. If a long view opens, press q to exit.

This exercise stays on your computer. To share it, use Desktop’s File → Add local repository, choose this folder, and publish it. Terminal-only sharing also needs a remote and authentication; follow GitHub’s linked setup instructions rather than guessing at credentials.

git status
git add README.md
git diff --staged
git commit -m "Add a welcome message"
git log --oneline

9. When something looks wrong

Start with git status, or the Changes and History views in Desktop. Find out what is saved, committed, and shared before undoing anything.

• “I committed, but GitHub hasn’t changed.” Check the repository and branch, then push. A new local repository needs to be published first.
• “There’s nothing to commit.” Make sure you saved the file and opened the correct repository. The change might already be committed, or the file might be ignored.
• “I picked the wrong file.” Before committing, uncheck it in Desktop. In a repo with an existing commit, git restore --staged README.md removes that file from the selection and keeps your edits.
• “My push was rejected.” Check the message: it could be missing permission or newer remote commits. Save and commit your work, check access, then fetch and review incoming changes. Don’t jump to force push.
• “There’s a merge conflict.” Git needs help combining edits. Read both versions, decide what the finished file should say, remove any conflict markers, save, and test. Mark it resolved and complete the merge. Ask the other author if the intent is unclear.
• “I committed a mistake.” For a simple, ordinary commit, revert creates a new commit that reverses its changes and preserves the history. Review the target first. A revert can also conflict, so get help if it is unclear.

10. Three habits that make Git easier

• Make small, meaningful commits. “Fix contact form validation” tells you more than “stuff.” A clear message helps future you understand why something changed.
• Read the diff before committing, including changes made by AI. Stage only what belongs in that checkpoint, and check that the result works.
• Keep passwords, API keys, and real customer data out of the repo. A .gitignore file tells Git which untracked files to leave out. It does not remove tracked files or erase history. If you committed a secret, revoke or rotate it and get help cleaning the history.

Keep this little cheat sheet handy

Replace REPO_URL with the project’s clone URL. Push and pull assume authentication, a linked remote, and an upstream branch. The first push of a new branch commonly uses git push -u origin new-headline. Pull with --ff-only stops when histories have diverged so you can review what happened and choose the next step.

For your next practice round, change the welcome message again. Read the diff, commit with a useful message, push, and confirm it on GitHub. Once that loop feels familiar, try the same change on a branch.

Sources & further reading

• Git: what it is and how snapshots work
• Download GitHub Desktop
• GitHub Desktop: your first repository
• GitHub Desktop: review and commit changes
• GitHub: branches and pull requests
• Install Git
• GitHub: add locally hosted code
• Git command reference: staging
• Git command reference: commits
• Git command reference: pull
• Git command reference: restore
• Git command reference: revert
• Git: ignore files