Basic Git Commands

Summary

Git is a distributed version control system that records a project’s changes as commits and lets you compare or recover earlier states. It does more than simply back up files.

When first using Git, it is important to understand the following workflow.

Edit files in the working directory
    ↓ Check with git status and git diff
Select changes for the next commit in the staging area
    ↓ git add
Record changes in the local repository
    ↓ git commit
Exchange changes with a remote repository
    ↓ git fetch, git pull, git push

Start with the following commands.

git --version
git status
git diff
git add filename
git diff --staged
git commit -m "Describe the change"
git log --oneline
git branch --show-current
git remote -v

Before running commands, check the current repository, branch, and changed files.

pwd
git status
git branch --show-current

git status and git diff are inspection commands that do not record changes as commits. When unsure what to do next, make a habit of checking the current state with these commands first.

Git’s Basic Structure

Git and GitHub: The Difference

Git is a version control tool that manages change history on your local computer. GitHub hosts Git repositories remotely and provides sharing, issues, pull requests, and automation features.

You can use Git without GitHub.

Git
├── Create local repositories
├── Record change history
├── Create and merge branches
└── Compare and restore earlier states

GitHub
├── Host remote repositories
├── Collaborate
├── Pull requests and code review
└── GitHub Actions

Other remote repository options include GitLab, Bitbucket, and a Git server you operate yourself.

The Working Directory, Staging Area, and Repository

Changes in a Git project can be understood through these three areas.

Common file states include the following.

git add does not send files to a remote repository. It places the current changes in the staging area for inclusion in the next commit.

git commit does not send changes to GitHub either. It records staged changes in the local repository. Run git push separately to send them to a remote repository.

Basic Git Command Format

git subcommand options target

Example:

git diff --staged README.md

Checking Installation and User Settings

git --version: Check the Git Version

git --version

Example output:

git version 2.x.x

The actual version depends on your operating system, package repository, and installation date.

Check Current Settings

git config --list --show-origin

This shows both the settings and the configuration files they came from. The output can contain authentication settings or sensitive URLs, so do not share it without checking it first.

To check only the user name and email address, use:

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

Set Your User Name and Email Address

The following values are examples. Use the name and email address you want to appear in your commits.

git config --global user.name "Example User"
git config --global user.email "user@example.com"

--global changes the defaults for your user account. To use different values in one repository, run the commands inside that repository without --global.

git config user.name "Project User"
git config user.email "project-user@example.com"

Check repository-specific settings:

git config --local --list

Preparing a Git Repository

git init: Initialize the Current Directory as a Git Repository

First, check your current location and files.

pwd
ls -la

Create a new Git repository in the current directory.

git init

Git creates a .git directory inside the current directory. It contains commits, branches, and repository settings, so do not edit or delete it as if it were an ordinary project file.

Check the repository’s top-level directory:

git rev-parse --show-toplevel

Running this outside a Git repository may produce an error.

git clone: Clone a Remote Repository

git clone https://github.com/example/project.git

The URL above is an example. git clone normally creates a new project directory, downloads the remote repository’s history and files, and registers the remote under the name origin.

Enter the cloned repository:

cd project
git status
git remote -v

Do not force a clone into a location that already contains a directory with the same name or files you are working on.

Check Whether You Are in a Repository

git status

Inside a Git repository, this shows the current branch and change status. The following error means Git cannot find a repository in the current directory or its parent directories.

fatal: not a git repository

Do not immediately run git init just because you see this error. Check pwd, ls -la, and the project path first. Initializing the wrong parent directory can put a much larger set of files under version control than intended.

Checking Changes

git status: Check the Current State

git status

You can inspect the following.

• Current branch
• Staged changes
• Changes not yet staged
• Untracked files
• Differences from the remote-tracking branch

This is one of the most frequently used commands before and after Git operations.

Short format:

git status --short

Include branch information:

git status --short --branch

In short-format output, the left column represents the staging area and the right column represents the working directory.

Example output:

 M README.md
M  app.js
?? notes.txt

git diff: Inspect Unstaged Changes

git diff

This compares the working directory with the staging area. By default, it shows changes that have not yet been staged.

Inspect a specific file:

git diff README.md

Show only changed filenames:

git diff --name-only

Show change statistics:

git diff --stat

git diff --staged: Review the Next Commit’s Contents

git diff --staged

This shows the difference between the staging area and HEAD, the current commit. Use it to review what will actually go into the next commit.

Inspect a specific file:

git diff --staged README.md

--cached serves the same purpose.

git diff --cached

Excluding Files from Tracking

.gitignore

Record patterns for files and directories you do not want Git to track in the repository’s .gitignore file.

Example:

node_modules/
dist/
.env
*.log

Files such as .env can contain real secrets, so prepare .gitignore before the first commit.

Check whether a file is ignored:

git check-ignore -v .env

Adding a file to .gitignore does not automatically stop Git from tracking it if it is already tracked. If sensitive information has been committed, deleting the file does not remove it from past history. Revoke and replace exposed tokens and passwords immediately; review and obtain approval separately before cleaning up repository history.

Staging Changes

git add: Select Changes for the Next Commit

Stage a specific file.

git add README.md

You can name several files explicitly.

git add README.md app.js package.json

Check after staging:

git status
git diff --staged

Stage All Changes Under the Current Directory

git add .

This stages changes beneath the current directory together. It is convenient, but can also include temporary files, logs, build output, and secrets. Always check before and after running it.

git status --short
git add .
git diff --staged --name-only
git diff --staged

As a beginner, it is safer to name files explicitly and stage only the changes you need whenever possible.

git add -p: Select Parts of a Change

git add -p

Use this to stage changes within a file in smaller pieces. It helps you separate commits when one file contains changes made for different purposes.

This requires interactive choices. Do not approve every hunk without understanding each change.

Creating Commits

git commit: Record Staged Changes

git commit -m "Add installation instructions to README"

A good commit has one main purpose. Write its message so readers can understand what changed and why.

Check the following before committing.

git status
git diff --staged

Check after committing:

git status
git log -1 --oneline

Unstaged Changes Are Not Committed

git commit normally records only the contents of the staging area. Modified files may remain in the working directory, but their unstaged changes are not included in the commit.

Use git commit -a Carefully

git commit -a -m "Update tracked files"

-a automatically stages and commits modifications and deletions of tracked files, but does not include new files. It is easy to skip reviewing changes this way, so beginners should run git add, git diff --staged, and git commit separately.

Amend the Last Commit

git commit --amend

This replaces the last commit’s contents or message with a new commit. Its commit ID changes, so do not use it casually on a commit already pushed to a remote and used by other people.

Viewing Commit History

git log: View Commit History

git log

Show one short line per commit:

git log --oneline

Show a graph and all branches:

git log --oneline --graph --decorate --all

Show only the five most recent commits:

git log -5 --oneline

History for a specific file:

git log --oneline -- README.md

git show: Inspect a Specific Commit

Inspect the current commit:

git show HEAD

Inspect a specific commit:

git show commit-id

Replace commit-id with a value from git log --oneline. Do not copy an example value from another repository.

Show only change statistics:

git show --stat commit-id

Compare Two Commits

git diff earlier-commit-id..later-commit-id

Show only filenames:

git diff --name-only earlier-commit-id..later-commit-id

Managing Branches

A branch is a movable name pointing to a particular commit. Using branches for different tasks keeps changes separate while helping you maintain a stable default branch.

Check the Current Branch

git branch --show-current

List local branches:

git branch

List all local and remote-tracking branches:

git branch --all

Create and Switch to a New Branch

git switch -c docs/git-basic-guide

-c creates a new branch and switches to it.

Switch to an existing branch:

git switch main

Switching branches can change the files in your working directory. With uncommitted changes, the switch may be refused or the changes may carry over, so check git status first.

Create a Branch Without Switching

git branch docs/git-basic-guide

This creates the branch without changing your current branch.

Merge a Branch

For example, to merge a work branch into main, switch to main first.

git status
git switch main
git merge docs/git-basic-guide

Before merging, check that the working tree is clean and that you are on the correct branch.

Merge Conflicts

When the same section has been changed differently, Git may be unable to merge automatically and report a conflict.

git status

A conflicted file may contain markers like these.

<<<<<<< HEAD
Content from the current branch
=======
Content from the branch being merged
>>>>>>> other-branch

Review both versions, decide on the final contents, remove the conflict markers, and check the result. Do not select one side for every conflict without understanding the changes.

Before continuing the merge:

git diff
git status

Delete a Local Branch

Delete a merged branch:

git branch -d docs/git-basic-guide

-d refuses deletion if unmerged commits remain. -D ignores that check and forces deletion, so do not use it for routine cleanup.

Check before deleting:

git branch --merged
git log main..docs/git-basic-guide --oneline

Checking Remote Repositories

git remote -v: List Remotes

git remote -v

Check the remote URLs used for fetching and pushing.

origin is a conventional name for the default remote, but it is not mandatory.

Inspect Remote Details

git remote show origin

Check the remote URL, default branch, and tracking relationships. This command may connect to the remote repository.

Add a Remote

git remote add origin https://github.com/example/project.git

This fails if origin already exists. Check git remote -v first.

Check the remote URL:

git remote get-url origin

Change the remote URL:

git remote set-url origin https://github.com/example/project.git

Check the URL and access permissions before and after changing it to avoid pushing to the wrong repository.

Getting Remote Changes

git fetch: Download Remote History Without Integrating It

git fetch origin

This downloads commits and references from the remote and updates remote-tracking branches, but does not automatically merge them into your current branch.

Review differences after fetching:

git status
git log --oneline HEAD..origin/main
git diff --stat HEAD..origin/main

This is useful when you want to review the remote state before deciding whether to merge it.

git pull: Fetch and Integrate

git pull

git pull fetches remote changes and integrates them into the current branch. Depending on settings and options, it may use a merge or a rebase.

Check before running:

git status
git branch --show-current
git remote -v

If you have uncommitted changes or need to review remote history first, use git fetch and inspect the differences rather than immediately running git pull.

Example specifying the target and integration method:

git pull --ff-only origin main

--ff-only proceeds only when a fast-forward is possible and fails when the histories have diverged. If it fails, inspect the local and remote histories instead of blindly adding other options.

Pushing to a Remote Repository

git push: Send Local Commits

Push using the current branch’s configured remote tracking relationship:

git push

Push a branch for the first time and set its upstream:

git push --set-upstream origin docs/git-basic-guide

Short option:

git push -u origin docs/git-basic-guide

Check before pushing:

git status
git branch --show-current
git remote -v
git log --oneline origin/main..HEAD

Make sure you are not sending secrets, large generated files, or unnecessary history to the remote repository.

Be Careful with Force Pushes

git push --force can overwrite remote branch history and cause other people’s commits to be lost. Do not use it as a default fix on shared or default branches.

Even when a force push is necessary after rebasing or amending commits, check the target branch, remote changes, and team rules, and obtain the user’s approval first. --force-with-lease provides a safeguard that checks remote changes, but it is not unconditionally safe.

Temporarily Saving Work

git stash: Save Uncommitted Changes Temporarily

git stash push -m "Documentation work in progress"

By default, this saves changes to tracked files. New, untracked files are not included.

To include untracked files:

git stash push --include-untracked -m "Stash including new files"

List saved stashes:

git stash list

Inspect a stash:

git stash show --patch stash@{0}

Apply Stashed Changes

Apply while keeping the stash in the list:

git stash apply stash@{0}

After applying it successfully, remove it separately from the list:

git stash drop stash@{0}

git stash pop attempts to remove the entry after applying it. If conflicts are possible or you need to inspect the contents first, separating apply and drop is safer.

Undoing Changes

The appropriate undo command depends on whether the target is the working directory, staging area, or a commit. Check status and differences first.

git status
git diff
git diff --staged
git log -5 --oneline

Unstage Without Discarding Your Work

Remove a file’s changes from the staging area while preserving the contents in your working directory.

git restore --staged README.md

Check:

git status
git diff README.md

Discard Working Directory Changes

git diff README.md
git restore README.md

Newly created untracked files are not deleted by git restore.

Undo a Published Commit with a New Commit

git revert commit-id

This creates a new commit containing the inverse changes instead of deleting the original commit. Use it to undo changes while preserving the history of a shared branch.

Check before running:

git show commit-id
git status

Reverting merge commits or multiple commits requires additional decisions, so follow a procedure appropriate to those cases.

Use git reset Carefully

Depending on its mode and target, git reset can change the branch, staging area, and working directory.

• --soft: moves the branch while preserving the staging area and working directory
• Default --mixed: changes the branch and staging area while preserving the working directory
• --hard: resets the branch, staging area, and working directory to the specified state

In particular, git reset --hard can discard uncommitted changes. Do not run it automatically without checking the current repository and the state you would recover to.

Rewriting commits already shared remotely with reset and then force-pushing can affect other users’ history. For public history, generally consider git revert first.

Be Careful When Cleaning Untracked Files

git clean can delete files and directories Git does not track. Its targets can include uncommitted work as well as build output, so do not treat it as a routine beginner cleanup command.

Even when deletion is needed, inspect the targets with a dry run first and review which files must be preserved. The basic exercise in this article does not run git clean.

Managing Tags

Tags are commonly used to name a particular commit, such as a release.

List Tags

git tag

Create an Annotated Tag

git tag -a v1.0.0 -m "First release"

Check:

git show v1.0.0

Push a Tag

git push origin v1.0.0

An ordinary git push may not automatically send all local tags. Deleting or renaming tags can affect deployment automation and other users’ records, so review those operations separately.

Getting Help

Basic Help

git --help
git status --help
git add --help

Show brief usage information in the terminal:

git status -h
git add -h

View Official Documentation

If your environment supports opening web documentation, use:

git help --web status

Commands and options can vary between Git versions. Check the installed version’s help alongside Git’s official documentation.

Basic Practice

This example uses a new practice directory rather than an existing project. It was not executed in a separate practice repository while preparing this document.

Step 1: Create a Practice Directory

mkdir git-practice
cd git-practice
pwd

Confirm that this is a new directory without existing files.

ls -la

Step 2: Initialize a Git Repository

git init
git status

Step 3: Create a File

printf '# Git Practice\n' > README.md

Check:

cat README.md
git status --short

Step 4: Prepare the First Commit

git add README.md
git status
git diff --staged

Step 5: Make the First Commit

git commit -m "Add README"

Check:

git status
git log --oneline

If your user name and email address are not configured, Git may stop the commit and explain how to set them. Review the values, choose a global or repository-specific scope, and then try again.

Step 6: Edit and Compare the File

printf '\nPractice checking Git status and changes.\n' >> README.md
git status --short
git diff README.md

Step 7: Make the Second Commit

git add README.md
git diff --staged
git commit -m "Add a description to README"

Step 8: Create a Branch

git switch -c docs/example
git branch --show-current

Step 9: Add a File on the Branch

printf 'Git branch practice\n' > branch-note.txt
git add branch-note.txt
git diff --staged
git commit -m "Add branch practice file"

Step 10: Check the Default Branch and Merge

Check the repository’s default branch name.

git branch

If the default branch is main, run:

git switch main
git merge docs/example

The initial branch name can vary by environment, so do not assume it is main as in this example.

Step 11: Review the Final History

git status
git log --oneline --graph --decorate --all

This exercise does not register a remote repository or run git push.

Quick Reference for Common Commands

Key Takeaways

In Git, check the state before taking action.

pwd
git status
git branch --show-current
git remote -v

Before committing, inspect working directory changes and staged changes separately.

git diff
git diff --staged

Stage and commit only the files you need.

git add filename
git diff --staged
git commit -m "Describe the change"

Before remote operations, check the current branch, remote URL, and commits to be sent.

git branch --show-current
git remote -v
git log --oneline origin/main..HEAD

git restore, git reset, git clean, forced branch deletion, and force pushes can lose changes or history. Do not run them automatically without checking the target, scope of impact, and recovery plan.

Precautions and Limitations

• Depending on the repository and configuration, the default branch may be named main, master, or something else.
• Git commands and options can vary with the installed version. Check git --version, -h, and the official documentation.
• git add . can stage unexpected files under the current directory. Check git status and git diff --staged before and after using it.
• .gitignore does not remove committed secrets from past history. Revoke and replace exposed credentials immediately.
• git commit --amend, rebase, git reset, and force pushes can change commit IDs and shared history.
• git reset --hard, git restore, and git clean can discard uncommitted changes.
• Deleting remote branches, force-pushing, and renaming the default branch can affect collaboration, deployment, and automation. Do not perform them without confirmation from the user and collaborators.
• This article introduces the Git CLI. It does not replace comprehensive coverage of rebase, cherry-pick, bisect, submodules, hooks, signing, Git LFS, or repository history rewriting.

Next Steps

Previous article: Link to be added

Next article: Link to be added

References and Sources

• Git Reference — current official documentation for individual Git commands — 2026-08-14
• @@INLINE_0@@ — working directory, staging area, and untracked file indicators — 2026-08-14
• @@INLINE_0@@ — comparing the working directory, staging area, and commits — 2026-08-14
• @@INLINE_0@@ — staging changes and interactive selection — 2026-08-14
• @@INLINE_0@@ — creating commits and the behavior of -a and --amend — 2026-08-14
• @@INLINE_0@@ — unstaging and the source used to restore working directory files — 2026-10-14
• @@INLINE_0@@ — effects of --soft, --mixed, and --hard — 2026-08-14
• @@INLINE_0@@ — updating remote references and remote-tracking branches — 2026-08-14
• @@INLINE_0@@ — fetching remote changes and integrating them into the current branch — 2026-08-14
• @@INLINE_0@@ — updating remote references and force-push options — 2026-08-14
• Pro Git — Git’s three states, basic workflow, branches, and remote repositories — 2026-08-14

Related Documents

• Basic Linux Commands (in Korean)
• Basic Docker Commands (in Korean)