Git and GitHub for absolute beginners

What version control is, how Git differs from GitHub, the handful of commands you will use every day, your first repository step by step, and how to undo the common mistakes.

Git is a version control tool that records every change to your code, so you can go back, compare versions and work with others without overwriting each other. GitHub is a website that hosts Git repositories online. Beginners need only a handful of commands: init, add, commit, push, pull and branch, plus the habit of committing often.

Almost every software team uses Git, and your GitHub profile is often the first thing a recruiter or client looks at. This guide starts from zero and gets you to your first repository online, then covers branches, pull requests and how to undo common mistakes.

What is version control, and why do you need it?

If you have ever had files called project_final.docx, project_final_v2.docx and project_final_REALLY_final.docx, you have done version control by hand. It is messy, and it breaks down completely when several people edit the same files.

Git solves this properly. Each time you save a meaningful change, you make a commit: a snapshot of your project with a message explaining what changed. You can see the full history, compare any two versions, go back to an earlier one, and work on experiments without risking the version that works.

What is the difference between Git and GitHub?

You can use Git without GitHub, and there are other hosting services. But Git plus GitHub is the most common combination, especially for beginners building a public portfolio.

What are the key ideas?

How do you create your first repository?

Install Git from the official site, then open a terminal. First, tell Git who you are; this is recorded in every commit:

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

Create a project folder, turn it into a repository, and check its status:

mkdir my-first-repo
cd my-first-repo
git init
git status

Create a file, for example a README.md describing the project. Then stage it and commit it:

git add README.md
git commit -m "Add README with project description"

Now put it on GitHub. Create a new, empty repository on GitHub, then connect your local repo to it and push. GitHub shows these exact commands when you create a repository:

git branch -M main
git remote add origin https://github.com/your-username/my-first-repo.git
git push -u origin main

Refresh the GitHub page and your file is there. From now on, the daily loop is simple: edit, git add, git commit, git push.

What are branches and pull requests?

A branch lets you work on something new without touching the working version. Create one, switch to it, make commits, and push it:

git switch -c add-contact-page
# edit files, then:
git add .
git commit -m "Add contact page with form"
git push -u origin add-contact-page

On GitHub, you then open a pull request asking to merge add-contact-page into main. Teammates review the changes, comment and approve, and then it is merged. This is how nearly every professional team works, so practise it even on solo projects.

To get changes others have pushed, run git pull before you start work each day.

What should you never commit?

Never commit passwords, API keys, or files such as .env that contain secrets. Once pushed to a public repository, assume a secret has been seen, even if you delete it later; Git keeps history. If it happens, revoke and replace the key immediately.

Create a .gitignore file listing what Git should ignore:

.env
node_modules/
__pycache__/
*.log

What is a merge conflict, and how do you fix one?

A merge conflict happens when two branches change the same lines of the same file, and Git cannot decide which version to keep. It is normal, not a disaster. Git marks the conflict inside the file like this:

<<<<<<< HEAD
<h1>Welcome to our store</h1>
=======
<h1>Welcome to Sharma General Store</h1>
>>>>>>> add-store-name

The part above the ======= line is your current branch; the part below is the incoming branch. Edit the file so it contains the version you actually want, delete the three marker lines, then stage and commit the result. Most code editors, including VS Code, highlight conflicts and offer buttons to accept one side or both. Pulling often and keeping branches short-lived makes conflicts smaller and rarer.

How do you write a good commit message?

Write what the commit does, in the imperative, as if completing “This commit will…”. Good: Fix login error when email has capital letters. Unhelpful: changes, update, asdf. Small, focused commits with clear messages make your history readable, and reviewers notice.

What are the common mistakes, and how do you undo them?

The golden rule: git status tells you almost everything, so run it constantly. And avoid rewriting history that others have already pulled; use git revert, which adds a new commit that undoes an old one, instead.

How does GitHub work as a portfolio?

For beginners and career switchers, GitHub is a living CV. A few well-documented projects, each with a clear README explaining what it does, how to run it and what you learned, say more than a certificate. Regular commits show consistency. Our realistic plan for switching to tech explains how to build that portfolio over time.

Two excellent free references: the Pro Git book on the official Git website, and GitHub’s getting-started documentation.

Git is part of the very first phase of Program Zero: Phase 0 covers Git and GitHub alongside Linux, the command line and how the internet works, so every project after that lives in a repository. For how Git fits into the wider skill set, see Program Zero’s full-stack developer roadmap for India.

Frequently asked questions

Related reading