Git Commands for Beginners: A Practical Workflow Guide

Git commands for beginners become easier when you follow one small change from your editor to a shared repository. You edit a file, review the difference, stage the intended content, commit it locally, and then push it for review. Each step has a different purpose.

This Git tutorial uses current branch and restore commands, explains how to fetch and pull safely, and gives you a practice workflow. Run unfamiliar commands in a disposable repository first. The examples use main and origin; your project may use different names.

Understand the three places your work lives

• Working tree: the files you are editing.
• Staging area, or index: the exact content selected for the next commit.
• Commit history: snapshots already recorded in your local repository.

A remote host such as GitHub, GitLab or Azure Repos stores another repository. A local commit does not automatically upload anything, and a successful push does not automatically mean a change has been reviewed or deployed.

1. Check Git and configure your commit identity

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

Replace the example identity before committing. It becomes part of commit metadata and is not a login credential. Use your hosting provider’s private commit email if needed. To use a different identity for one project, run the same configuration inside that repository without --global.

2. Create a practice repository or clone an existing project

For a new local exercise:

mkdir git-practice
cd git-practice
git init -b main

For an existing project, use its clone URL instead. Copy the address from your repository host; the example below is a placeholder:

git clone https://example.com/team/project.git
cd project

These are alternative starting points. You do not need to initialize a second repository inside a cloned project. Modern git switch and git restore commands require Git 2.23 or later; check your installed version if either command is unavailable.

3. Inspect changes before staging

git status
git diff
git diff --staged

git status identifies the current branch and changed files. git diff shows unstaged changes to tracked files, while git diff --staged shows the next commit’s patch. New untracked files do not appear in a normal diff until staged, so inspect their content too.

4. Create a branch, stage a file and commit

git switch -c docs/update-readme
git add README.md
git diff --staged
git commit -m "Clarify project setup instructions"

Create or edit README.md before staging it. Stage explicit paths while learning, rather than collecting every changed file without review. If you edit the file again after git add, those later edits are not automatically included in the staged version.

To inspect branches and recent history:

git branch -a
git branch --show-current
git log --oneline --decorate -10

Switch to an existing local branch with git switch main. Git normally refuses a switch that would overwrite local changes; investigate that message rather than adding a discard option.

5. Fetch first, then choose how to synchronize

git remote -v
git fetch origin
git status -sb

Fetching downloads remote objects and updates remote-tracking references without integrating them into your current branch. It gives you time to inspect incoming work. Pulling also integrates updates according to the selected options and configuration.

For an existing branch that tracks its intended upstream, this explicit command permits only a fast-forward update:

git pull --ff-only

If local and remote history have diverged, the command stops. Read the history and follow your team’s merge or rebase policy. Do not turn a rejected pull into a force push. On older installations, relying on bare git pull can give different behavior depending on configuration; explicit options make the intention clearer.

6. Push your feature branch for review

git push -u origin docs/update-readme

Check the remote and branch before running it. The -u option sets the upstream for later push and pull operations. Open the project’s pull request or merge request, run its checks, and follow branch-protection rules. Authentication uses your host’s supported method, such as SSH or a credential helper; never put access tokens in committed files.

7. Undo the right thing

Unstage a file while keeping your edits

git restore --staged README.md

In a repository with an existing commit, this restores the staged version from HEAD and leaves your working file alone. It is useful when you staged a change too early.

Discard an unstaged change only when you mean to

git restore README.md

This replaces the working file with its staged version and discards its unstaged edits. Inspect git diff -- README.md first and save anything you need. This command is different from unstaging.

Reverse a published commit

git revert COMMIT_HASH

Replace the placeholder with the intended commit. Revert records a new commit that reverses an earlier change, which usually fits shared history better than rewriting it. Conflicts and merge commits need additional judgment; inspect the result and run project checks.

8. Pause unfinished work with a stash

git stash push -u -m "Pause README work"
git stash list
git stash apply

The -u option includes untracked files, but not ignored files. Applying restores the latest stash without deleting its entry. Inspect the restored changes before removing a stash you no longer need. A stash is temporary local storage, not a backup shared with teammates.

9. Keep generated files and secrets out of Git

Add project-specific patterns to .gitignore, for example:

.env
*.log
node_modules/
.venv/

Ignore rules apply to untracked files; they do not remove something already committed. If a secret was pushed, rotate it and follow the host’s secret-removal procedure. Adding its filename to an ignore file does not erase repository history.

Frequently asked questions

What if Git reports a merge conflict?

Run git status, inspect each conflicted file, and reconcile the intended content. Stage resolved files and follow Git’s instructions for the current merge or rebase. Run the project’s tests before continuing. Do not resolve a conflict by deleting markers without understanding both changes.

Is git checkout obsolete?

No. It remains supported. This guide uses switch for branches and restore for file content because their separate names make the beginner workflow easier to follow.

Which Git commands should beginners avoid copying blindly?

Be especially careful with reset --hard, clean -fd and force pushes. They can discard work or change shared history. First identify the exact problem, the affected files or commits, and your recovery options.

Official documentation and related guides

• Switching branches
• Restoring and unstaging files
• Fetching remote changes and pull options
• Reverting commits
• Stashing work and ignore rules
• Jenkins security and incident response
• Docker security best practices