A Practical Git Workflow: Add, Commit, Fetch, Pull, and Push

The short answer

For ordinary Git work, keep one model in mind: your changes move from the working tree to the staging area, then into your local repository, and only then to a remote repository.

working tree -> staging area -> local repository -> remote repository
                 git add        git commit          git push

Most Git confusion comes from not knowing which of those four places currently contains a change. Start with git status; it is the safest command in a Git workflow because it tells you what Git sees before you change anything.

A minimal daily workflow

When you have finished one focused change:

git status
git add src/app/page.tsx
git commit -m "fix: correct homepage copy"
git push origin your-branch

Do not reach for git add . by default. Stage the files that belong to one intention, inspect them, and make a commit that someone else can review or revert without untangling an entire afternoon's work.

Start a repository or copy an existing one

git init

Create a new local repository in the current directory:

git init

Use it for a brand-new project. If the project already exists on GitHub or GitLab, cloning is usually the better start.

git clone

Copy an existing remote repository to your Mac:

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

For a repository you contribute to regularly, SSH is convenient once your key is configured. HTTPS is fine for read-only copies or when your organization's setup calls for it.

git status

Run this before staging, pulling, restoring, or switching branches:

git status

It reports your current branch, modified-but-unstaged files, staged files, and whether your branch is ahead of or behind its remote counterpart. Treat it as a dashboard, not as an error message.

Why add and commit are separate

Stage a change with git add

git add src/lib/posts.ts

git add does not make a commit. It selects the version of a file that the next commit will contain. That separation is what lets you turn a mixed set of edits into clear, reviewable history.

Before committing, review exactly what is staged:

git diff --staged

Record the staged change with git commit

git commit -m "feat: add related content recommendations"

A useful commit message explains what changed. If the reason is not obvious from the change, include it in the commit body or pull request description. For a repeatable local quality gate, pair this workflow with Husky and Commitlint once that guide is available in your project.

Fetch, pull, and push are not interchangeable

git fetch: download without changing your branch

git fetch origin

Fetch updates your view of the remote repository but does not merge those commits into your current branch. Use it when you want to inspect incoming work first.

git pull: fetch, then integrate

git pull origin main

Pull combines a fetch with integration into your current branch, usually through a merge or rebase depending on repository configuration. It is convenient, but inspect git status and make sure your working tree is clean first; otherwise you can mix remote changes and local edits into a harder-to-understand conflict.

git push: send committed work to the remote

git push origin feature/seo

Only committed changes can be pushed. Unstaged files and staged-but-uncommitted work stay local.

Work on a branch, not directly on main

Create and switch to a branch for one feature or fix:

git switch -c fix/build-warning

A healthy default is simple:

• Keep main in a releasable state.
• Give each independent change its own branch.
• Review and test before merging.

If you regularly need two working directories for separate branches, use Git worktree rather than repeatedly stashing unrelated changes.

Restore the right thing

git restore is useful, but it can discard work. Read git status first and target a specific file.

Remove a file from the staging area

git restore --staged src/app/page.tsx

The file remains in your working tree; it is simply no longer selected for the next commit.

Discard an uncommitted file change

git restore src/app/page.tsx

This replaces the current uncommitted content with Git's saved version. Back up or copy any work you may need before running it.

A realistic, low-risk loop

git switch -c fix/build-warning
git status
git add src/app/layout.tsx
git diff --staged
git commit -m "fix: remove deprecated middleware usage"
git fetch origin
git push origin fix/build-warning

This is safer than long-running development directly on main: it gives you a small review unit, an easy rollback point, and a clearer route to collaboration.

Common mistakes to avoid

• Thinking git add has already saved a commit.
• Trying to push before committing.
• Running destructive commands without checking git status.
• Staging every file with git add . when the changes are unrelated.
• Treating pull as harmless while you have unfinished local work.
• Developing directly on main for days.

Where to go next

• Need parallel branches without stashing? Read Git worktree versus stash.
• Setting up Git, Node, environment variables, and linting in a front-end repository? Continue with the project configuration files guide.
• Want a keyboard-first daily loop? Learn the VS Code shortcuts that matter most on Mac.

For command details and edge cases, use the official Git documentation. The durable habit is simpler: check status, stage intentionally, commit one coherent change, then push the branch.