How-To Guides

How to Use Git and GitHub for Non-Developers

Track changes to any folder of work, go back in time when something breaks, and back it all up to the cloud -- without writing a single line of code.

01. What Is Git (and Why Would a Non-Developer Care)?

Git is a version control system. Every time you save a snapshot of your work -- a "commit" -- Git records exactly what changed, who changed it, and when. You can then roll back to any previous version, see the history of a single file, or branch off and experiment without touching the original.

Developers use Git to manage code, but it works just as well for writers, researchers, students, spreadsheet tinkers, or anyone who has ever ended a file's name with _final_v2_REAL_FINAL.docx. With Git, there is one canonical version of every file, plus an auditable history of every change you ever made.

GitHub is the cloud host for Git repositories. You keep your Git history on your computer, and you push a copy of it to GitHub for safekeeping (and sharing). GitHub is to Git roughly what Google Drive is to a local folder -- a place to sync and back up the work.

The mental model: think of Git as a lab notebook. Every "commit" is an entry -- a labelled snapshot you can flip back to. GitHub is the online backup of that notebook, plus a place to share it with collaborators.

What this guide covers

  • •Installing Git on Windows, Mac, or Linux in a couple of minutes.
  • •Creating a free GitHub account and configuring Git with your name and email.
  • •Making your first local repository and your first commit.
  • •Pushing that repository up to GitHub as a backup.
  • •The simple daily workflow you will repeat forever after.
  • •Cloning, branching, and merging -- what they are and when to use them.

Step 1. Install Git

Git is a single small program. Installation takes a couple of minutes and you only ever do it once per computer.

Windows

  1. 1.Download the installer from git-scm.com.
  2. 2.Run the installer. The defaults are sensible -- just keep clicking Next.
  3. 3.Verify it worked: open "Git Bash" (a new entry in your Start menu) and run git --version. You should see a version number, not "command not found".

macOS

Git is included with the Xcode Command Line Tools. The easiest install is to open Terminal and run:

git --version

If Git is not already installed, macOS will prompt you to install the Command Line Tools. Agree and wait. Verify with git --version again once it finishes.

Linux (Debian / Ubuntu)

sudo apt update && sudo apt install git

On Fedora replace apt with dnf; on Arch use pacman -S git. Confirm with git --version.

Choose your terminal. On Windows use Git Bash (it ships with the installer). On Mac and Linux the built-in Terminal works fine. Every command in this guide is run inside that terminal.

Step 2. Create a GitHub Account

GitHub is where your Git history will live in the cloud. The free tier gives you unlimited public and private repositories, more than enough for personal use. You only ever need to make this account once.

  1. 1.Go to github.com and click the big "Sign up" button.
  2. 2.Pick a username. This becomes part of every repository URL you share (e.g. github.com/yourname/my-project), so pick something you do not mind showing people.
  3. 3.Use an email you actually check -- GitHub sends security alerts and notifications here. You can sign in with that email or set up passkeys later.
  4. 4.Choose the Free tier when prompted. You do not need a paid plan for anything in this guide.
  5. 5.Verify your email when the confirmation message arrives. Unverified accounts cannot create repositories.

Save this password in a password manager. You will use it every time you push from your computer. GitHub also supports passkeys and 2FA -- enable at least 2FA from Settings → Password and authentication to protect your repositories.

Why a free account is enough

  • •Unlimited public and private repositories.
  • •2,000 minutes/month of free GitHub Actions (more than enough for personal automation).
  • •GitHub Pages for hosting a simple website for free.
  • •Unlimited collaborators on private repositories (with a limited number of private actions).

Step 3. Configure Git With Your Name and Email

Git stamps every commit with a name and an email so you can tell who made which change. You only set these once per computer -- Git remembers them for every repository you create afterwards. Use the same email you signed up to GitHub with so commits show up linked to your account.

Set your name:

git config --global user.name "Your Name"

Set your email:

git config --global user.email "[email protected]"

Set your default branch name to "main":

git config --global init.defaultBranch main

Older Git versions defaulted to "master" as the main branch name. Modern convention is "main". Setting it once globally means every repository you create will use "main" from the start -- matching what GitHub expects when you push.

Verify your settings:

git config --global user.name
git config --global user.email

Each command prints back the value you set. If either one is blank, you have a typo in the original --global command. There is no "save" step -- Git stores the config the moment you press Enter.

Per-repo override: if you ever want a different identity for a single repository (for example, work email on a work project), run the same commands without --global from inside that repository's folder. The local value overrides the global one.

Step 4. Create Your First Repository

A "repository" (or "repo") is just a folder that Git is watching. Any folder on your computer can be turned into a repo with one command. Let us make a tiny project, put a file in it, and record the first snapshot.

Make a folder and step inside it:

mkdir my-project
cd my-project

Turn the folder into a Git repository:

git init

Git responds with Initialized empty Git repository in ... and creates a hidden .git/ folder inside your project. That hidden folder is where every snapshot, every log entry, every change is stored. You never edit it by hand.

Create a file inside the folder:

echo "# My Project" > README.md

This makes a simple README.md file with one line of text. Use any text editor you like -- VS Code, Notepad, TextEdit -- to open and edit this file later.

Stage the file -- tell Git you want to include it in the next snapshot:

git add .

The dot means "everything in this folder". For a single file you could also write git add README.md. The "staging area" is Git's holding pen -- files in it are queued to be saved in the next commit.

Create your first commit:

git commit -m "first commit"

The -m flag attaches a short message to the snapshot. From now on you can always come back to this exact point in the file's history. Check it with git log --oneline -- you should see one entry.

The three-stage rhythm: Git always moves in three beats -- edit → stage (add) → commit. You edit files in your editor, then choose which changes to stage with git add, then permanently record them with git commit. Every Git workflow you ever see is just those three steps on repeat.

Step 5. Push Your Repository to GitHub

Right now your repository only exists on your own computer. If the laptop dies, the history dies with it. Pushing to GitHub makes a backup copy in the cloud and lets you pull the same repository to any other machine. This is where most of the value of Git lives for a non-developer.

  1. 1.Create an empty repository on GitHub. Sign in to github.com, click the + in the top-right, choose "New repository". Give it a name (e.g. my-project), choose Public or Private, and click "Create repository".
  2. 2.Copy the repository URL GitHub shows you on the next page. It looks like https://github.com/yourname/my-project.git.
  3. 3.Tell your local repo where the remote lives. Back in your terminal, run:

git remote add origin https://github.com/yourname/my-project.git

"origin" is just the conventional nickname for the GitHub copy of your repo. You can call it anything, but every Git tutorial in the world uses "origin", so stick with it.

Push your history up to GitHub for the first time:

git push -u origin main

The -u flag tells Git to remember that your local main branch should track origin/main. You only need this flag on the first push -- after this, plain git push is enough.

The first push will ask for your GitHub username and password. Use your GitHub username, and for the password use a Personal Access Token (GitHub no longer accepts account passwords for HTTPS pushes). Create one under Settings → Developer settings → Personal access tokens → Generate new token, give it "repo" scope, and paste the long string when prompted.

Skip the password prompt forever: on Windows use the Git Credential Manager that ships with Git for Windows; on Mac run git config --global credential.helper osxkeychain; on Linux use git config --global credential.helper store. Git will then remember your token so you only paste it once.

Step 6. The Daily Workflow

Once a repository exists, day-to-day Git is just three commands on repeat. You make some changes to your files, save them in your editor, stage what you want to keep, commit with a message, and push. That is the whole loop.

The cycle in detail

  1. 1.Edit files in your normal editor. Save them as usual. Git does not care what editor you use -- it sees the changes on disk.
  2. 2.Check what changed with git status. This prints a list of modified, new, and untracked files. It is the single most useful Git command -- run it constantly.
  3. 3.Stage the changes you want to keep with git add <file> or git add . to stage everything.
  4. 4.Commit with a descriptive message:

git commit -m "Add intro paragraph to README"

  1. 5.Push the new commit to GitHub:

git push

Refresh the GitHub page for your repository and the new commit shows up with your message and timestamp. That is it -- you have used Git productively.

Useful supporting commands

  • git statusSee which files have changed and which are staged. Run this constantly.
  • git diffSee exactly what lines you added or removed, before staging. Add --staged to see what is queued for the next commit.
  • git log --onelineA compact one-line-per-commit history of the project. Great for browsing what you have done.
  • git log -pThe full history with the actual code/text changes shown for every commit.
  • git pullFetch and merge any new commits that exist on GitHub (e.g. someone else edited there, or you edited on another computer). Always pull before you push if you work from multiple machines.

A safe pattern for solo work: start every session with git pull (in case you worked elsewhere), do your work, then git add → git commit → git push at logical breakpoints (not just at the end of the day).

Step 7. Cloning, Branching, and Merging

Once you have a repository on GitHub, three more tools become useful: cloning it onto a new computer, branching off to experiment safely, and merging that experiment back in. None of them are required for solo work, but they unlock the real power of Git once you understand them.

Cloning -- get a copy on a new machine

Cloning downloads a full copy of a repository, complete with its entire history, to any computer. Use this when you want to work on the same project from a new laptop, or grab someone else's public repo.

git clone https://github.com/yourname/my-project.git

This creates a folder called my-project in your current directory, with all the files and the full hidden .git history. You can start editing immediately -- no git init needed.

Branching -- experiment without risk

A branch is a parallel timeline. You can make whatever changes you want on a branch, and your main branch stays untouched. If the experiment works, you merge it back in. If it does not, you throw the branch away and nothing is lost.

git checkout -b feature/my-changes

This creates a new branch called feature/my-changes and switches to it. Edit, stage, and commit as normal -- but now those commits live on the branch, not on main.

Switching branches

git checkout main # back to the main branch
git checkout feature/my-changes # back to your experiment

Your files on disk change instantly to match whichever branch you are on. Git stores the other branch's state in its hidden history and swaps it back when you switch again.

Merging -- bring the experiment back

Once you are happy with a branch, switch back to main and merge the branch in:

git checkout main
git merge feature/my-changes

All the commits from the branch are now part of main. Push to GitHub and the remote reflects it. Delete the experimental branch with git branch -d feature/my-changes when you are done with it.

Pull requests are GitHub's layer on top of merging. Instead of merging a branch yourself, you push it to GitHub and open a Pull Request -- a page where you (or a collaborator) can review the changes, comment, and click a button to merge. Useful even solo, as a way to record "here is what I changed and why" before folding it back into main.

Quick Tips

  • •Write descriptive commit messages. "Update README" tells you nothing in three months. "Add troubleshooting section for router DNS step" tells you everything. Future-you will thank present-you.
  • •Commit small and often. One logical change per commit beats one giant end-of-day commit. Smaller commits are easier to roll back individually and easier to understand.
  • •Use a .gitignore file to tell Git which files or folders to never track. Common entries: .DS_Store, node_modules/, *.tmp, large media files you do not want in the cloud.
  • •Never commit secrets. API keys, passwords, tokens -- if you commit them they are in history forever. Use .gitignore, or git rm --cached <file> to un-stage a file you added by accident.
  • •Run git status compulsively. It is non-destructive and always tells you the truth about where you are. If anything ever feels confusing, git status and git log --oneline will orient you.
  • •Commit before you experiment. About to refactor a file you are unsure about? Commit the working version first. Then if the experiment goes sideways, git checkout . or git reset --hard HEAD restores the known-good state.
  • •Use branches for anything risky. Even solo, a branch costs nothing and means your main folder never ends up in a half-broken state if you get interrupted.
  • •Pull before you push on shared repos. If a collaborator pushed since you last pulled, your push will be rejected. Run git pull first to integrate their work, then push the combined result.

Need More Help?

Git's command surface looks intimidating but the daily loop is just three commands. If you would like a guided first-commit walk-through on your actual project -- including getting GitHub authentication set up painlessly -- book a free call and we will get you pushing with confidence.

Book a Free Call Contact Us