Loading
September 27, 2026
Bytebloop.com How to Use Git Featured Image

How to Use Git: Step-by-Step Guide for Beginners in 2026

Introduction

Git is a distributed version control system used to track changes in software projects and collaborate with other developers. Instead of relying on folders filled with different versions of the same project, Git records changes in a repository so developers can review history, create separate development branches and return to earlier versions when necessary.

Git is commonly used together with platforms such as GitHub, which provide remote repositories and collaboration features such as pull requests, code review and branch management. GitHub’s documentation describes branches as isolated spaces for developing features, fixing bugs or experimenting before changes are merged into the main codebase.

Whether you are learning programming, working on a personal project or collaborating with a development team, learning how to use Git is an important practical skill.

In this guide, you will learn how to install Git, configure your identity, create a repository, commit files, connect a project to GitHub, create branches, open pull requests, rebase a branch and recover from common mistakes.


What Is Git?

Git is a distributed version control system that keeps track of changes made to files in a project.

With Git, you can:

  • Track project history
  • See what changed between versions
  • Create and manage branches
  • Collaborate with other developers
  • Restore earlier versions
  • Experiment without changing the main branch
  • Share code through remote repositories

A Git repository contains the information Git needs to track the project, including its history and references to branches and commits.

You can use Git locally without GitHub or another hosting service. GitHub is a separate platform that can host Git repositories and provide collaboration tools around them.


Git vs GitHub: What Is the Difference?

Beginners often confuse Git and GitHub, but they are not the same thing.

Git is the version control software running on your computer.

GitHub is an online platform that hosts Git repositories and provides additional collaboration features.

Think of it this way:

Git = version control system

GitHub = online platform for hosting and collaborating around Git repositories

You can learn Git without creating a GitHub account, but GitHub is useful when you want to share your projects or collaborate with other developers.

GitHub’s official documentation provides additional information about working with repositories and collaboration.


Basic Git Concepts You Should Know

Before running Git commands, it helps to understand a few important terms.

Repository

A repository, often called a repo, is a project tracked by Git.

It contains the files you are working on as well as Git’s version history.


Commit

A commit is a saved snapshot of changes in your Git history.

For example:

git add .
git commit -m "Add login page"

The commit message explains what was changed.


Branch

A branch creates a separate line of development.

You can use one branch for the main project and another for a new feature or bug fix.

GitHub recommends branches as a way to isolate development work before it is merged into the default branch.


Remote

A remote is a reference to another copy of a repository, commonly hosted online.

For example:

origin

is a commonly used name for the main remote repository.


Pull Request

A pull request, often abbreviated as PR, proposes changes from one branch to another for discussion, review and merging.

GitHub’s current pull-request workflow allows developers to create a branch, make commits, open a pull request, request reviews and then merge the changes.


Step 1: Install Git

The first step is installing Git on your computer.

For Windows, download Git from the official Git website:

Download Git for Windows

As of September 2026, the official Git for Windows page lists Git 2.55.0 as the latest maintained build and shows it was released on August 20, 2026.

After installation, open Command Prompt, PowerShell or Git Bash.

Run:

git --version

You should see a Git version number.

For example:

git version 2.55.0

The exact version may change as new releases are published.


Step 2: Configure Your Git Identity

Git records an author name and email address in commits.

Set them with:

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

To check your settings:

git config --global --list

You can also check individual values:

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

Use an email address you are comfortable associating with your commits. If you plan to connect your commits with GitHub, use an email configuration that matches how you want your contributions attributed on GitHub.


Step 3: Create a Project Folder

Create a project folder and move into it.

For example:

mkdir my-project
cd my-project

You can also use an existing project folder.

Check its contents with:

ls

On Windows Command Prompt, you can use:

dir

Step 4: Initialize a Git Repository

Inside the project directory, run:

git init

This initializes a Git repository in the folder. Git’s official documentation describes git init as creating an empty Git repository or reinitializing an existing one.

You should see a message similar to:

Initialized empty Git repository

A hidden .git directory is created to store Git’s repository data.

You can check the repository status using:

git status

Step 5: Create or Add Project Files

Suppose your project contains:

index.html
style.css
script.js

You can check which files Git sees with:

git status

Git may show them as untracked files.

Untracked means Git sees the files but they have not yet been added to the staging area.


Step 6: Stage Your Changes

Git uses a staging area to prepare changes for the next commit.

To stage a specific file:

git add index.html

To stage several files:

git add index.html style.css script.js

To stage all changed files in the current project:

git add .

Then check the status:

git status

The files should now appear as staged changes.


Step 7: Create Your First Commit

Once your changes are staged, create a commit:

git commit -m "Add initial project files"

A commit records a point in your project’s history.

Good commit messages should describe the change clearly.

Examples:

git commit -m "Add homepage layout"
git commit -m "Fix navigation menu"
git commit -m "Update authentication flow"

Avoid vague messages such as:

update
changes
stuff
final

Clear commit messages make project history easier to understand later.


Step 8: Create a GitHub Repository

Now you can create an online repository on GitHub.

Visit:

GitHub

Sign in and select New repository.

GitHub’s current repository creation workflow allows you to choose a repository name, description and visibility, along with optional initial content such as a README.

For a simple project that already exists locally, creating an empty GitHub repository can make the first push simpler because your local repository already has its own history.

After creating the repository, copy its HTTPS URL.

It may look like:

https://github.com/yourusername/my-project.git

Step 9: Connect Your Local Repository to GitHub

Inside your local project folder, run:

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

Check the remote:

git remote -v

You should see something similar to:

origin  https://github.com/yourusername/my-project.git (fetch)
origin  https://github.com/yourusername/my-project.git (push)

origin is simply the conventional name for the remote repository.


Step 10: Set the Main Branch

Many modern GitHub repositories use main as the default branch name. GitHub’s documentation states that new repositories use main by default unless the default branch naming is configured differently.

To rename your current branch to main:

git branch -M main

Check the branch:

git branch

You should see:

* main

Step 11: Push Your Code to GitHub

Now push your local branch:

git push -u origin main

The -u option establishes the upstream relationship between your local branch and the remote branch.

After the first push, future pushes can often be performed with:

git push

Refresh your GitHub repository and your project files should now appear online.


Step 12: Check Your Git Status

One of the most useful Git commands is:

git status

Use it frequently.

It tells you things such as:

  • Your current branch
  • Modified files
  • Untracked files
  • Staged changes
  • Whether your working tree is clean

For example:

On branch main
nothing to commit, working tree clean

This means Git does not currently see uncommitted changes.


Step 13: Create a Feature Branch

One of the biggest advantages of Git is branching.

Instead of making every change directly on main, create a separate branch for your feature.

A traditional command is:

git checkout -b feature-login

Modern Git also provides the dedicated switch command:

git switch -c feature-login

The official Git documentation describes git switch -c as creating and switching to a new branch.

For beginners, git switch -c is often easier to understand because it clearly represents the branch-switching operation.


Step 14: Make Changes on the Feature Branch

Now work on your feature.

For example, you might modify:

login.html
style.css
script.js

Check the changes:

git status

You can inspect exactly what changed using:

git diff

This is useful before staging and committing your work.


Step 15: Commit Feature Changes

Stage the changes:

git add .

Then commit:

git commit -m "Implement login form"

It is generally easier to understand project history when commits represent logical pieces of work rather than one enormous collection of unrelated changes.

GitHub’s pull-request quickstart also recommends keeping changes focused and using small, meaningful commits.


Step 16: Push the Feature Branch to GitHub

Push your feature branch:

git push -u origin feature-login

After the branch is uploaded, GitHub can display the branch and provide options for creating a pull request.


Step 17: Create a Pull Request on GitHub

Open your repository on GitHub.

Select the option to create a pull request for your new branch.

Set:

Base: main

Compare: feature-login

Add:

  • A descriptive title
  • A summary of the changes
  • Testing information
  • Screenshots where useful
  • Any relevant issue references

GitHub’s official pull-request workflow describes a PR as a proposal to merge changes from one branch into another, with review and discussion before merging.


Step 18: Review and Merge the Pull Request

Before merging, review:

  • Changed files
  • Commit history
  • Tests
  • Potential bugs
  • Comments from reviewers

If everything is ready, the pull request can be merged into main.

After merging, you can usually delete the feature branch on GitHub.

Deleting a branch after its work is merged keeps the repository easier to navigate. GitHub documents branch deletion as part of normal branch management.


Step 19: Delete the Local Feature Branch

After the branch has been merged, switch back to main:

git switch main

Then delete the local feature branch:

git branch -d feature-login

If the remote branch has not already been deleted on GitHub, you can remove it with:

git push origin --delete feature-login

Step 20: Keep Your Local Main Branch Updated

When working with other developers, your local main may become outdated.

First fetch the latest remote information:

git fetch origin

Then update your local branch:

git pull origin main

Before beginning new work, it is useful to make sure your base branch is current so that your feature branch starts from the latest project state.


Step 21: Understand Git Rebase

Rebase moves a series of commits onto another base commit.

For example:

git rebase main

Interactive rebase allows you to edit, reorder, combine or remove commits. Git’s documentation specifically describes interactive rebase as a way to edit a series of commits.

For example:

git rebase -i HEAD~4

This lets you review the last four commits.

You may see:

pick 1234567 Add login form
pick 2345678 Fix login button
pick 3456789 Update login validation
pick 4567890 Fix typo

You can change later commits to:

pick 1234567 Add login form
squash 2345678 Fix login button
squash 3456789 Update login validation
fixup 4567890 Fix typo

The exact result depends on which commits you select and how you edit the rebase plan.


Step 22: Be Careful With Rebase

Rebase changes commit history.

That means you should be careful when rebasing commits that other people are already using.

Git’s documentation warns that rebasing shared history has implications for collaborators.

For a personal feature branch that has not yet been merged, interactive rebase can be useful for organizing commits before opening or updating a pull request.


Step 23: Push a Rebasing Branch Safely

After rebasing a branch that has already been pushed, Git may reject a normal push because the remote history is different.

In that situation, you may use:

git push --force-with-lease origin feature-login

The important part is:

--force-with-lease

Git documents this option as a safer alternative to blindly forcing an update: it checks that the remote reference is still at the expected value before replacing it.

Avoid casually using:

git push --force

on shared branches because rewriting remote history can remove commits that another contributor has already pushed.


Useful Git Commands for Beginners

Here is a practical command reference:

CommandPurpose
git --versionCheck Git version
git config --global user.nameView configured username
git config --global user.emailView configured email
git initCreate a Git repository
git statusCheck repository status
git add .Stage changes
git commit -m "message"Create a commit
git logView commit history
git diffView unstaged changes
git branchList branches
git switch -c branch-nameCreate and switch to a branch
git switch mainSwitch branches
git merge branch-nameMerge a branch
git fetchDownload remote references
git pullFetch and integrate remote changes
git pushUpload commits
git clone URLCopy a remote repository locally
git remote -vView remote URLs
git rebase mainRebase current branch
git stashTemporarily store local changes

Common Git Mistakes and How to Avoid Them

1. Forgetting to Check Git Status

Before committing, run:

git status

This helps you understand which files are modified, staged or untracked.


2. Making Every Change Directly on Main

Directly developing everything on main can make collaboration more difficult.

Use feature or topic branches for isolated work.


3. Writing Unclear Commit Messages

Instead of:

git commit -m "update"

write:

git commit -m "Fix mobile navigation menu"

The second message provides useful context when reviewing project history.


4. Committing Sensitive Files

Do not accidentally commit:

  • Passwords
  • API keys
  • Private credentials
  • Secret configuration files
  • Local environment files

A .gitignore file can help prevent specific files from being tracked.

For example:

.env
node_modules/
dist/

5. Rebasing Shared Branches Without Coordination

Rebase rewrites commit history, so be careful when other developers are working from the same branch.


6. Force-Pushing Carelessly

Use --force-with-lease rather than blindly forcing shared branch updates when a rewritten history really is required. Git specifically documents the lease mechanism as a check against overwriting newer remote work.


Git Best Practices

Commit Small, Logical Changes

A commit should ideally represent one meaningful piece of work.

Instead of one giant commit:

Update project

you could have:

Add login form
Add login validation
Fix mobile login layout

Use Clear Branch Names

Useful examples include:

feature/search-bar
feature/user-login
bugfix/mobile-menu
bugfix/payment-error
docs/readme-update

The exact naming convention can vary between teams.


Pull or Fetch Regularly

Keeping your branch informed about upstream changes helps reduce surprises when you eventually integrate your work.


Review Before You Commit

Use:

git diff

and:

git status

before committing.

This gives you a chance to catch accidental changes.


Keep Pull Requests Focused

A focused pull request is easier for reviewers to understand.

GitHub’s own quickstart recommends keeping a first pull request focused and simple because smaller changes are easier to review and merge.


Advanced Git Topics

Once you understand the basic workflow, you can explore additional Git features.

Git Stash

Temporarily save local modifications:

git stash

Restore them later:

git stash pop

This can be useful when you need to switch branches without committing unfinished work.


Git Hooks

Git hooks can automatically run scripts at specific stages of the Git workflow.

For example, a team can use hooks to perform checks before certain commits or pushes.


Git Submodules

Submodules allow one Git repository to reference another repository as a dependency.

They can be useful in specific project structures but add additional complexity, so beginners generally do not need them immediately.


Git Reflog

The reflog records movements of references such as HEAD and can sometimes help recover commits or branch states after an accidental reset or other mistake.

It is an especially useful recovery tool once you become more comfortable with Git.


A Simple Git Workflow for Beginners

For many projects, the workflow can look like this:

Create / Clone Project
        ↓
Check git status
        ↓
Create Feature Branch
        ↓
Write Code
        ↓
git add
        ↓
git commit
        ↓
git push
        ↓
Open Pull Request
        ↓
Review + Test
        ↓
Merge into main
        ↓
Delete Feature Branch

The exact workflow can differ between teams, but understanding this cycle gives beginners a strong foundation.


Git Workflow Example

Imagine you are adding a search feature.

Start from the latest main:

git switch main
git pull origin main

Create a branch:

git switch -c feature/search

Make your code changes.

Check the changes:

git status
git diff

Stage the files:

git add .

Commit:

git commit -m "Add search feature"

Push:

git push -u origin feature/search

Then open a pull request on GitHub.

After review and testing, merge the pull request into main.

This workflow keeps the feature separate from the main development line until it is ready.


Frequently Asked Questions

What is Git and why should I use it?

Git is a distributed version control system that records changes to files and helps developers manage project history, branches and collaboration.

Is Git the same as GitHub?

No. Git is the version control system, while GitHub is an online platform that hosts Git repositories and provides collaboration features.

How do I create a new Git repository?

Navigate to your project folder and run:

git init

Git’s official documentation uses git init to create a new repository.

How do I create a new branch?

You can use:

git switch -c feature-name

or the traditional:

git checkout -b feature-name

What does git add do?

git add stages changes so they can be included in the next commit.

What does git commit do?

git commit records staged changes as a new snapshot in the repository history.

What does git push do?

git push sends local commits to a remote repository.

What does git pull do?

git pull retrieves changes from a remote repository and integrates them into the current branch according to the configured pull behavior.

What is a pull request?

A pull request is a proposal to merge changes from one branch into another so the changes can be reviewed and discussed before merging. GitHub documents this as a core collaboration workflow.

Should beginners learn Git rebase?

Yes, but start with the basics first. Understand commits, branches, pull, push and merge before using rebase regularly.

Is Git difficult to learn?

Git has a learning curve because it introduces concepts such as staging, commits, branches, remotes and history. However, the basic workflow can be learned step by step through regular use.


Key Takeaways

  • Git is a distributed version control system for tracking project changes.
  • Git and GitHub are different tools that are often used together.
  • git init creates a repository.
  • git add stages changes.
  • git commit records changes in project history.
  • Branches let you isolate features and bug fixes from the main development line.
  • GitHub provides pull requests for reviewing and merging changes.
  • git status and git diff are useful everyday commands.
  • Rebase can help reorganize commit history but should be used carefully on shared branches.
  • --force-with-lease is preferable to blindly force-pushing when rewritten history must be pushed.
  • Clear commits, meaningful branch names and focused pull requests make collaboration easier.

Conclusion

Learning how to use Git becomes much easier when you approach it as a simple workflow rather than trying to memorize every command at once.

Start by installing Git and configuring your identity. Create or clone a repository, make changes, stage them and commit them with clear messages. Once you are comfortable with the basics, introduce branches so features and fixes can be developed separately from main.

GitHub can then extend this workflow by allowing you to push branches, create pull requests, request reviews and merge completed work.

As your projects become more advanced, you can explore rebase, stash, hooks, submodules and reflog. You do not need to master every Git command on day one.

The most important step is building a consistent workflow: check your status, make focused changes, commit meaningful work, keep branches organized and review changes before merging.

For developers working with modern software projects, Git provides a reliable foundation for managing code history and collaborating without losing track of changes.


Related Reading

AI for Developers Explained

Web Application Security Explained

AI Automation Software Explained

BYTE BLOOP Software Category


Official Sources

Git Official Website

Git Documentation – git init

Git Documentation – git switch

Git Documentation – git rebase

Git Documentation – git push

GitHub – Creating a Repository

GitHub – Pull Request Quickstart

GitHub – Managing Branches

Leave a Reply

Your email address will not be published. Required fields are marked *

You Missed