Git and GitHub for Complete Beginners

Imagine you are writing an essay. You save it as "essay_final.docx." Then you make changes and save it as "essay_final_v2.docx." Then "essay_ACTUALLY_final.docx." Then "essay_final_final_FINAL.docx." You have five copies, you cannot remember what changed between them, and your folder is a mess.

Git solves this problem for code. Instead of saving multiple copies of your project, Git keeps one copy and tracks every change you make over time. Each set of changes is called a "commit," and every commit has a message explaining what changed and why. You can go back to any commit at any time. You can see exactly what changed between any two points in your project's history.

But Git does more than just track changes. It also lets you create "branches," which are parallel versions of your code. You can work on a new feature in a branch without affecting your main code. If the feature works, you merge it in. If it does not, you delete the branch. Your main code was never at risk.

Every professional development team uses Git. Every job listing expects it. Every open source project is built on it. Learning Git is not something you do after you learn to code. It is something you learn alongside coding, from day one.

This trips up almost every beginner. Git and GitHub are related but different.

Git is a program that runs on your computer. It tracks changes in your files. It works entirely offline. You do not need an internet connection to use Git. It was created by Linus Torvalds (the person who also created Linux) in 2005, and it is free and open source.

GitHub is a website (github.com) owned by Microsoft. It hosts Git repositories online so you can share your code, collaborate with others, and have a backup in case your laptop dies. GitHub is the most popular platform for hosting code, but it is not the only one. GitLab and Bitbucket do similar things.

The relationship: you use Git on your computer to track changes. You use GitHub to store a copy of your project online and share it with others. When you "push" code, you are sending your local Git history up to GitHub. When you "pull" code, you are downloading changes from GitHub to your computer.

You need Git installed on your machine (see our Windows setup guide for installation steps). You also need a free GitHub account. Go to github.com and sign up. Choose a professional username, something close to your real name. This will be on your resume.

Git has dozens of commands. You need five right now. Here they are, in the order you will use them.

1. git init

git init

This tells Git to start tracking a folder. You run it once, at the beginning of a new project. It creates a hidden .git folder that stores all the tracking information. You never need to touch that folder directly.

2. git add

git add index.html           # Stage one specific file
git add .                    # Stage all changed files

This "stages" your changes, which means marking them as ready to be committed. Think of it as putting items in a box before sealing it. You can stage one file at a time or use git add . to stage everything that changed. For beginners, git add . is fine most of the time.

3. git commit

git commit -m "Add contact form to homepage"

This saves a snapshot of all your staged changes with a message describing what you did. The -m flag lets you write the message inline. Commit messages should be short and describe the change: "Add login page," "Fix broken nav link," "Update footer styles." Not "updated stuff" or "changes."

4. git push

git push origin main

This sends your commits from your computer to GitHub (or wherever your remote repository is). After pushing, your code is backed up online and visible to anyone with access to the repository. The first time you push, you might need to set up authentication (GitHub now uses personal access tokens or SSH keys instead of passwords).

5. git pull

git pull origin main

This downloads changes from GitHub to your computer. If you work on multiple devices, or if a teammate pushed changes, you pull to get their updates. Always pull before you start working to make sure you have the latest code.

That is it. Init, add, commit, push, pull. These five commands will carry you through your first months of coding. Everything else (branches, merges, rebasing, stashing) builds on these fundamentals.

Here is the step-by-step workflow you will follow for every new project.

Step 1: Create a repository on GitHub.

1. Go to github.com and click the "+" icon in the top right, then "New repository."
2. Give it a name (use lowercase and hyphens: my-portfolio-site, not My Portfolio Site).
3. Add a description (one sentence about what the project does).
4. Choose "Public" so employers can see your work.
5. Do NOT check "Add a README file" if you already have code locally. If you do, it will create a conflict when you try to push.
6. Click "Create repository."

GitHub will show you a page with setup instructions. The ones you care about are under "push an existing repository from the command line."

Step 2: Connect your local project to GitHub.

cd your-project-folder
git remote add origin https://github.com/yourusername/your-repo-name.git
git branch -M main
git push -u origin main

The git remote add origin command tells Git where to push your code. The -u flag in the push command sets up tracking so future pushes only need git push without the extra arguments.

Step 3: The daily workflow.

git pull                    # Get latest changes
# ... write some code ...
git add .                   # Stage your changes
git commit -m "Describe what you did"
git push                    # Send to GitHub

Do this every time you finish a meaningful chunk of work. Some developers commit every 30 minutes. Others commit a few times a day. The point is to commit frequently enough that each commit represents a clear, small change. If something breaks, you can go back to the last commit and only lose a small amount of work.

Once you are comfortable with the basic workflow, branches are the next concept to learn. They are simpler than they sound.

A branch is a copy of your code that you can change without affecting the main version. Imagine you want to add a dark mode to your portfolio site. You are not sure it will work. Instead of changing your main code and potentially breaking things, you create a branch:

git checkout -b add-dark-mode

This creates a new branch called "add-dark-mode" and switches you to it. Any changes you make now only exist on this branch. Your main branch is untouched. If dark mode works, you merge the branch back into main. If it is a disaster, you delete the branch. No harm done.

To switch between branches:

git checkout main              # Switch to main branch
git checkout add-dark-mode     # Switch to your feature branch

Pull requests (PRs) are a GitHub feature, not a Git feature. When you push a branch to GitHub, you can open a pull request, which is a way to propose merging your branch into main. Pull requests let other people review your code before it gets merged. In a professional team, you almost never push directly to main. You create a branch, push it, open a pull request, get feedback, and then merge.

For your personal projects, you can push directly to main. But practicing the branch and PR workflow early is a good habit. When you join a team, it will already feel natural.

To merge a branch locally (without a pull request):

git checkout main          # Switch to main
git merge add-dark-mode    # Merge your branch into main
git push                   # Push the merged code to GitHub

Every beginner hits these problems. Here is what to do when they happen.

"I accidentally committed a file I should not have."

Create a .gitignore file in the root of your project. List the files and folders Git should ignore:

node_modules/
.env
.DS_Store
*.log

The node_modules folder is the most common one. It contains downloaded packages and can be thousands of files. Never commit it. Always add node_modules/ to your .gitignore before your first commit. If you already committed it, remove it with:

git rm -r --cached node_modules
git commit -m "Remove node_modules from tracking"

"I made changes but forgot to pull first, and now there is a conflict."

This happens when you and someone else (or you on a different computer) changed the same file. Git will mark the conflicting sections in the file with markers like <<<<<<< and >>>>>>>. Open the file, choose which version to keep, remove the markers, then add and commit. VS Code has a built-in merge conflict editor that makes this easier by showing you both versions side by side.

"My commit message has a typo."

If it is your most recent commit and you have not pushed yet:

git commit --amend -m "Corrected commit message"

If you have already pushed, leave it. A typo in a commit message is not worth the headache of rewriting Git history.

"I want to undo my last commit."

git reset --soft HEAD~1

This undoes the commit but keeps your changes staged. You can make adjustments and commit again. Do not use --hard unless you genuinely want to delete your changes permanently.

"I am stuck in Vim and cannot exit."

Press Escape, type :q!, press Enter. This happens when Git opens Vim as a text editor (usually during a merge or rebase). To prevent it, configure Git to use VS Code instead: git config --global core.editor "code --wait"

Your GitHub profile is your developer portfolio. When you apply for jobs in Kenya or anywhere else, employers will look at your GitHub. Not to judge the quality of your code (they know you are a beginner), but to see that you actually build things and commit regularly.

Push everything. Every tutorial project, every experiment, every half-finished idea. A messy GitHub with 30 projects is more impressive than a clean GitHub with nothing on it. You can always delete or archive repos later.

Write README files. Every repository should have a README.md that explains what the project does, how to run it, and what you learned building it. This is the first thing people see when they visit your repo. A README does not need to be long. Three to five sentences is enough for a small project.

Contribute to your green squares. GitHub shows a contribution graph on your profile, a grid of green squares representing how often you commit. Consistent green squares show discipline and regular practice. You do not need to commit every single day, but a profile with regular activity looks better than one with a burst of commits followed by months of nothing.

Use descriptive repo names. weather-dashboard tells an employer what the project is. project1 tells them nothing. my-first-react-app is fine. test123 is not.

Start building your GitHub profile now, alongside your first project. By the time you are ready to apply for jobs, you will have months of commit history and a collection of projects that demonstrate your growth. That is worth more than any certificate.