Learn the Basics of Git and GitHub
Learning Git and GitHub is one of the smartest steps you can take as a developer, whether you are just starting out or already building real projects. At first, both tools can feel intimidating because people often talk about them as if they are the same thing. They are not. Git is the version control system that helps you track changes in your files. GitHub is the online platform that stores Git repositories and makes collaboration easier.
That difference matters a lot. Git works on your computer. GitHub works on the internet. Git helps you save versions of your code. GitHub helps you share that code with other people, work on teams, review changes, and keep your project safe in a remote place.
In real life, coding without Git is like writing a book without draft history. Imagine if every time you changed a chapter, you had to save the whole book under a new file name like book-final, book-final-2, book-final-really-final, and book-final-last-version. That gets messy fast. Git gives you a clean and intelligent way to save progress, go back in time, compare changes, and experiment without fear.
GitHub adds the human side. It helps teams talk, review, comment, and work together. A developer in Morocco can push code, a designer in France can review it, and a tester in Canada can open an issue about a bug. Everyone stays connected through one shared place.
This article will guide you through the basics of Git and GitHub in a simple, practical, and human way. You will learn the main commands, the most important concepts, and how to use both tools in a real workflow. You will also see code examples and simple schemas to help the ideas stick.
Why Git matters in the real world
Before learning commands, it helps to understand why Git exists at all.
Let’s say Sara is building a small website for her portfolio. She changes the homepage, then modifies the contact form, then updates the colors, then adds a new section. Two days later, she notices the site broke after one of her edits. Without Git, she may not know which change caused the problem.
Now imagine the same story with Git.
Sara makes a commit after finishing the homepage. She makes another commit after editing the contact form. She makes a third commit after changing the design. When something breaks, she can look at the history, compare versions, and even return to the exact point before the bug appeared. That is the power of version control.
Git helps you:
track your progress
recover old versions
work on several features at once
collaborate with others
keep a clear record of changes
avoid losing work
For beginners, the most important thing to understand is that Git is not magic. It is simply a very organized memory for your project.
Git and GitHub are not the same thing
This is one of the most common beginner confusions.
Git is the version control tool. It lives on your computer and manages your project history.
GitHub is a cloud platform that hosts Git repositories online. It adds collaboration features like pull requests, issues, project boards, wiki pages, and continuous integration.
A simple way to remember it:
Git = the engine
GitHub = the garage and service center
You can use Git without GitHub.
You cannot use GitHub properly without Git, because GitHub is built around Git repositories.
Other platforms work similarly too, such as GitLab and Bitbucket, but GitHub is one of the most popular.
The basic idea behind version control
Version control means keeping track of changes over time.
Here is the simplest possible workflow:
You start with a project.
You make a change.
You save that change as a snapshot.
You make more changes.
You can always return to any previous snapshot.
Git stores these snapshots as commits. A commit is like a save point in a game. Each commit has:
a unique ID
a message
an author
a timestamp
a record of what changed
When you make a commit, Git records the state of your project at that moment. If you need to, you can inspect the commit history later.
A simple Git workflow schema
Here is a basic workflow schema to help you picture Git:
flowchart LR
A[Working Directory] --> B[Staging Area]
B --> C[Local Repository]
C --> D[Remote Repository on GitHub]
This diagram shows the flow of changes:
Working Directory: the files you edit on your computer
Staging Area: a place where you prepare changes for a commit
Local Repository: the saved Git history on your machine
Remote Repository: the copy stored on GitHub
That staging area is important. It lets you choose exactly what goes into the next commit.
The three main states in Git
Git usually talks about three states:
1. Working directory
This is where your files live while you are editing them.
2. Staging area
This is where you place changes before committing them.
3. Repository
This is where Git stores committed snapshots.
Think of it like cooking:
Working directory = ingredients on the counter
Staging area = ingredients you have selected for the recipe
Repository = the finished dish stored for later
This comparison is simple, but it helps many beginners understand the idea.
Installing Git
Before using Git, you need to install it.
On Windows, you can install Git from the official Git website.
On macOS, you can use Homebrew or install from the Git website.
On Linux, you can install it through your package manager.
After installation, check that it works:
git --version
If Git is installed correctly, it will return the version number.
Setting up Git for the first time
After installing Git, you should set your identity. This information is attached to your commits.
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"
You can also check your settings:
git config --global --list
This tells Git who you are, so your commits are properly labeled.
Creating your first repository
A repository is the folder where Git tracks your project.
To create a new repository:
git init
This command creates a hidden .git folder inside your project directory. That folder contains all the information Git needs to manage the repository.
If you already have a project and want Git to manage it, move into that folder first and then run git init.
Checking the status of your project
One of the most useful Git commands is:
git status
This shows what is happening in your project.
It tells you things like:
which files were modified
which files are staged
which files are untracked
which branch you are on
For beginners, git status should become a habit. Many developers use it constantly because it gives a clear picture of the repository state.
Adding files to Git
When you create a file, Git does not automatically track it. You must add it.
Suppose you create a file called index.html.
To stage it:
git add index.html
To stage all modified files:
git add .
The . means “everything in the current folder.”
Use git add when you want to prepare changes for the next commit.
Making your first commit
A commit is a saved version of your project.
After staging your changes, commit them like this:
git commit -m "Add homepage structure"
The message should be short, clear, and meaningful. Good commit messages help you and your team understand the history later.
A few examples of good commit messages:
git commit -m "Fix login validation"
git commit -m "Add footer layout"
git commit -m "Update readme instructions"
Try to avoid meaningless messages like:
git commit -m "update"
git commit -m "fix"
git commit -m "stuff"
Those messages tell you almost nothing later.
Viewing commit history
To see your project history, use:
git log
This gives you a list of commits in reverse chronological order.
A shorter version is:
git log --oneline
This is useful when you want a quick overview.
A sample output might look like this:
a1b2c3d Add navbar
d4e5f6g Fix form submission
h7i8j9k Initial commit
Each commit has a unique ID, even if only the first part is displayed.
Understanding branches
Branches are one of Git’s most powerful features.
A branch lets you work on a separate line of development without affecting the main codebase.
Imagine Ahmed is building a shop website. He wants to add a new payment system, but he does not want to risk breaking the main site. He creates a new branch for the feature. While he works there, the main branch stays stable.
That is the beauty of branching: safe experimentation.
Branch schema
flowchart LR
M[main branch] --> F[feature/payment branch]
F --> R[review and test]
R --> M2[merge back into main]
This shows how branches usually work:
the main branch stays clean
a feature branch contains work in progress
after testing, the branch can be merged back
Creating a branch
To create a branch:
git branch feature-login
To switch to it:
git checkout feature-login
Or, in newer Git versions, you can do both with:
git switch -c feature-login
That command creates the branch and switches to it right away.
Switching between branches
To move to another branch:
git switch main
Or older Git syntax:
git checkout main
Changing branches is useful when you need to jump from one feature to another.
For example:
you may be working on a blog post editor
then suddenly you need to fix a bug on the homepage
you switch branches, fix the bug, commit it, and return to your feature later
This keeps work organized and clean.
Merging branches
After finishing work on a branch, you often merge it back into the main branch.
Example:
git switch main
git merge feature-login
This brings the changes from feature-login into main.
Sometimes merges are simple. Sometimes they produce conflicts. That is normal in team work.
What merge conflicts are
A merge conflict happens when Git cannot automatically decide how to combine two sets of changes.
This usually occurs when two people edit the same lines in the same file, or when one person changes a file in one branch and another person changes the same part elsewhere.
Git will mark the conflict inside the file, and you have to resolve it manually.
A conflict might look something like this:
<<<<<<< HEAD
<p>Welcome to my site</p>
=======
<p>Welcome to our site</p>
>>>>>>> feature-homepage
You must choose the correct content, edit the file, and then save it.
After resolving the conflict, stage the file and commit it.
git add index.html
git commit -m "Resolve merge conflict in homepage"
Conflicts can be stressful at first, but they are a normal part of teamwork. They are not signs of failure. They are simply Git asking for human judgment.
Comparing branches and changes
Sometimes you want to see what changed between versions.
You can compare differences with:
git diff
This shows line-by-line changes that have not yet been committed.
You can also compare branches:
git diff main feature-login
This helps you review work before merging.
Restoring files
Git helps you go back when something goes wrong.
If you changed a file but want to discard local modifications, you can restore it.
In newer Git versions:
git restore index.html
To unstage a file:
git restore --staged index.html
These commands are useful when you accidentally staged something too early or made changes you no longer want.
Be careful with restore commands. They can remove local work if used incorrectly.
Stashing temporary work
Sometimes you are in the middle of a task, but you need to switch to another branch quickly. You are not ready to commit yet. In that case, stash your changes.
git stash
This temporarily stores your modified files and returns your working directory to a clean state.
Later, you can bring the changes back:
git stash pop
Stashing is helpful when you are interrupted in the middle of work.
For example, Lina may be editing a dashboard feature when her team asks her to fix an urgent typo in the footer. She stashes her current changes, switches tasks, then returns later and resumes exactly where she left off.
Remote repositories and GitHub
So far, everything has been local. Now let us move to GitHub.
A remote repository is a version of your Git repository stored on another server. GitHub is the most common remote host for many developers.
When you push your code to GitHub, you create a backup online and make it easier to share with others.
Creating a repository on GitHub
On GitHub, you can create a new repository by choosing:
repository name
description
public or private visibility
README file
license
.gitignoretemplate
If you are starting from scratch, GitHub can create the repository for you, and then you connect your local project to it.
Connecting local Git to GitHub
To connect a local repository to GitHub, you add a remote.
Example:
git remote add origin https://github.com/username/project-name.git
Then push your branch:
git push -u origin main
The origin name is a common default remote name. It simply refers to the remote repository.
The -u option sets the upstream branch, which makes future pushes easier.
Pushing changes
When you push, you send your local commits to GitHub.
git push
This command uploads your commits to the remote repository.
For beginners, it helps to think of push as “send my changes to the online copy.”
Pulling changes
Pulling is the opposite direction.
git pull
This fetches changes from GitHub and merges them into your local branch.
Imagine your teammate updates the README file or fixes a bug while you were offline. When you pull, you get those updates too.
In team projects, pulling regularly helps prevent large conflicts later.
Cloning a repository
If you want a copy of an existing GitHub repository on your computer, you clone it.
git clone https://github.com/username/project-name.git
Cloning downloads the project and sets up Git so your local copy is linked to the remote repository.
This is often the first command used when joining an existing project.
A GitHub collaboration schema
Here is a simple workflow diagram for team collaboration on GitHub:
flowchart TB
A[Developer clones repo] --> B[Creates branch]
B --> C[Makes changes]
C --> D[Commits locally]
D --> E[PUSH to GitHub]
E --> F[Open pull request]
F --> G[Review by teammates]
G --> H[Merge into main]
This is a very common process in modern software teams.
Pull requests explained
Pull requests are one of GitHub’s most important collaboration tools.
A pull request, or PR, asks the team to review your changes before merging them. It does not literally “pull” code in the human sense. The name comes from the idea of requesting that changes be pulled into another branch.
A PR is useful because it allows:
code review
discussion
suggestions
testing
safe merging
Let’s say Noor adds a new payment feature. Instead of merging it immediately, she opens a pull request. Her teammate checks the code, notices a missing error message, leaves a comment, and asks for a small fix. Noor updates the branch, and then the PR is approved.
This human review step is valuable. Good code is not only about syntax. It is also about clarity, maintainability, and teamwork.
Issues in GitHub
GitHub issues are used to track bugs, tasks, improvements, and ideas.
Examples of issues:
“Login button not working on mobile”
“Add dark mode to settings page”
“Improve homepage loading speed”
“Translate the UI into French”
Issues help teams organize work. They are like a project conversation board.
A good issue usually includes:
a clear title
a description
reproduction steps if it is a bug
screenshots or logs if needed
labels such as bug, enhancement, or help wanted
Forks and why they matter
A fork is your own copy of someone else’s repository on GitHub.
Forks are very common in open-source work. If you find a project you want to improve, you can fork it, make changes in your own copy, and then propose those changes back to the original project.
This is how many people contribute to open source without needing direct write access.
A simple workflow:
fork the repository
clone your fork locally
create a branch
make your changes
push to your fork
open a pull request to the original repository
README files
The README file is often the first thing people see when they visit your repository.
A good README usually includes:
project name
description
features
installation steps
usage instructions
screenshots
contribution guide
license
A clear README makes your project friendlier to other humans. It lowers the barrier to entry and helps someone understand your work in minutes instead of hours.
The .gitignore file
Some files should not be tracked by Git. For example:
environment files
compiled output
cache files
log files
local editor settings
That is what .gitignore is for.
Example:
node_modules/
.env
dist/
.DS_Store
This tells Git to ignore those files and folders.
Ignoring unnecessary files keeps repositories clean and prevents sensitive data from being committed by mistake.
Git tags
Tags are useful when you want to mark an important point in history, such as a release.
Example:
git tag v1.0.0
Tags are often used for versions like:
v1.0.0
v1.1.0
v2.0.0
This makes it easy to identify official releases.
Basic Git commands you should know
Here is a practical list of commands every beginner should learn.
git init
git status
git add .
git commit -m "message"
git log --oneline
git branch
git switch -c new-branch
git switch main
git merge feature-branch
git diff
git clone URL
git pull
git push
git remote -v
git stash
git restore file.txt
You do not need to memorize everything in one day. Learn the commands through use, not pressure.
A simple day-in-the-life example
Let us follow Daniel, a junior developer.
Daniel starts a new feature: a contact form on a company website.
He clones the project:
git clone https://github.com/team/company-website.git
He creates a branch:
git switch -c feature-contact-form
He edits the HTML, CSS, and JavaScript files.
He checks the status:
git status
He stages the changes:
git add .
He commits:
git commit -m "Add contact form layout"
He pushes the branch:
git push -u origin feature-contact-form
Then he opens a pull request on GitHub, where his teammates review the changes.
This simple story is the daily rhythm of Git and GitHub in many real teams.
Another useful schema: commit lifecycle
flowchart LR
A[Edit file] --> B[git add]
B --> C[git commit]
C --> D[git push]
D --> E[GitHub repository]
E --> F[Teammate reviews]
F --> G[Merge]
This schema represents a standard flow from local editing to remote collaboration.
Common beginner mistakes
Everyone makes mistakes when learning Git. That is normal.
1. Committing too rarely
If you wait too long between commits, it becomes harder to understand what changed.
2. Using vague commit messages
Messages like “fix” or “update” are not helpful later.
3. Forgetting to pull
If others changed the remote repository, you should pull before pushing.
4. Mixing unrelated changes in one commit
Try to keep commits focused. One task per commit is often easier to manage.
5. Panicking about conflicts
Merge conflicts happen. They are part of collaborative development.
6. Not using branches
Working directly on main for everything can make projects harder to manage.
Good commit message habits
A good commit message should answer the question: what changed?
Examples:
git commit -m "Fix broken signup validation"
git commit -m "Add responsive navbar"
git commit -m "Update API endpoint for profiles"
git commit -m "Remove unused CSS classes"
A message should be clear enough that another developer can understand it without opening the diff.
If your team follows a commit convention, that is even better. Some teams use prefixes such as:
feat: add search bar
fix: correct login redirect
docs: update installation guide
style: improve spacing in header
This makes the history easier to scan.
GitHub profile and social proof
GitHub is not only for code storage. It also acts like a professional portfolio.
Recruiters and clients often look at:
repositories
contributions
pinned projects
README quality
activity history
collaboration style
A clean GitHub profile can show that you know how to work in a team, document your work, and manage code responsibly.
For many developers, GitHub becomes a living portfolio.
GitHub Actions in simple terms
GitHub Actions is a tool for automation. It can run tests, build projects, or deploy websites automatically when something happens in your repository.
For example:
when code is pushed, run tests
when a pull request opens, check formatting
when a release is created, deploy the app
A basic workflow file might look like this:
name: CI
on:
push:
branches:
- main
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Get code
uses: actions/checkout@v4
- name: Set up Node
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm install
- name: Run tests
run: npm test
This example means that every push to main triggers tests automatically.
That saves time and reduces mistakes.
A small Git example with a real file
Suppose you have a file called app.py.
Initial content:
print("Hello, world!")
You make a change:
print("Hello, Git and GitHub!")
Now you check the diff:
git diff
You may see the replacement of the printed text.
Then you stage and commit:
git add app.py
git commit -m "Update greeting message"
This is the essence of Git: a tracked, meaningful record of change.
A small HTML example
Let us say you are building a web page.
index.html:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>My First Git Project</title>
</head>
<body>
<h1>Welcome</h1>
<p>This project is under version control.</p>
</body>
</html>
Later, you update the page:
<body>
<h1>Welcome</h1>
<p>This project is under version control.</p>
<button>Explore</button>
</body>
Then you commit:
git add index.html
git commit -m "Add explore button"
This tiny example shows how Git tracks even small UI changes.
A practical workflow for beginners
Here is a simple workflow you can follow every time:
clone or initialize a repository
create a branch for your task
make changes
check status
review diff
stage files
commit with a good message
push to GitHub
open a pull request
review feedback
merge when approved
That sequence is one of the most common patterns in software development.
How humans actually use Git and GitHub
This part matters.
Git and GitHub are not just technical systems. They are part of how people cooperate.
A developer writes code.
A teammate reads it.
A reviewer asks a question.
A tester reports a bug.
A project manager tracks the task.
An open-source contributor submits a fix.
A maintainer decides whether to merge it.
That is why good communication matters as much as good commands.
A helpful commit message is a form of respect.
A clear README is a form of kindness.
A thoughtful pull request is a form of teamwork.
The best Git habits are not only about efficiency. They are also about making life easier for other humans who will read and use your work.
A Git mental model that helps beginners
Think about a Git repository as a notebook with many saved pages.
the working directory is your current draft
the staging area is the page you chose to save next
the commit history is the notebook archive
GitHub is the shared library copy
This mental model helps reduce confusion when commands start to feel abstract.
When to use Git every day
You should use Git whenever you want to track changes in a project, especially when:
building websites
writing scripts
working with a team
experimenting with new features
managing source code
keeping safe backups of your work
Even solo developers benefit from Git because it gives structure and history.
When GitHub becomes especially useful
GitHub is especially useful when you need:
remote backup
collaboration
code review
issue tracking
project visibility
open-source contribution
deployment automation
A developer using Git alone has good version control.
A developer using Git with GitHub gains collaboration and visibility.
A realistic branch naming example
Good branch names make projects easier to navigate.
Examples:
feature/login-page
feature/payment-integration
bugfix/navbar-overlap
docs/update-readme
refactor/user-service
These names make it obvious what each branch is for.
A realistic project folder schema
flowchart TB
A[Project Root] --> B[src]
A --> C[public]
A --> D[tests]
A --> E[README.md]
A --> F[.gitignore]
A --> G[package.json]
A repository often contains code, documentation, configuration, and ignored files together. Git helps keep all of that organized.
Tips for learning Git faster
The fastest way to learn Git is to use it regularly on small projects.
Try this:
create a practice repository
make a file
commit it
edit it again
view the log
create a branch
merge it back
intentionally make a conflict in a test project
resolve it carefully
Learning by doing is much more effective than trying to memorize everything at once.
Common Git and GitHub vocabulary
Here are some words you will hear often:
Repository: a project tracked by Git
Commit: a saved snapshot of changes
Branch: a separate line of development
Merge: combining changes together
Clone: copying a repository locally
Push: sending commits to GitHub
Pull: bringing remote changes to your machine
Fork: creating your own copy of a repository on GitHub
Pull request: asking for changes to be reviewed and merged
Remote: a repository hosted online
Staging area: the place where changes wait before commit
These terms become easier with practice.
A beginner-friendly Git cheat sheet
# Start a repository
git init
# Check current status
git status
# Add files
git add .
# Commit changes
git commit -m "Your message"
# View history
git log --oneline
# Create a branch
git switch -c feature-name
# Switch branches
git switch main
# Merge a branch
git merge feature-name
# See differences
git diff
# Clone a repo
git clone URL
# Add a remote
git remote add origin URL
# Push changes
git push -u origin main
# Pull updates
git pull
# Temporarily save work
git stash
# Restore a file
git restore file.txt
Keep this cheat sheet nearby when you begin.
Final thoughts
Git and GitHub are not difficult because the ideas are impossible. They are difficult because they are new. Once the concepts click, they become one of the most useful parts of your developer toolkit.
Git gives you control over your project history.
GitHub gives you a place to share, collaborate, review, and grow.
Together, they support both the technical side of coding and the human side of working with others.
A beginner who learns Git early gains confidence, safety, and structure. A beginner who learns GitHub also learns how real teams work. That combination is powerful.
Start small. Make one commit. Create one branch. Open one pull request. Read one diff carefully. Then repeat.