Git and GitHub for Beginners: Commit, Push, Pull, and Deploy in the Right Order

July 21, 2026Updated: July 25, 2026Articles

When you first use Git, unfamiliar terms such as commit, push, pull, and merge appear all at once. I initially could not tell which meant “save,” which meant “send,” and which meant “publish.”

The confusion becomes easier to untangle when you stop memorizing isolated definitions and instead ask: Where is the change now, and where does this operation move it? This guide follows a typical Git and GitHub workflow and explains the first 12 terms a beginner will encounter.

Git and GitHub are different things

Git is a system for managing the history of file changes, including on your own computer. It lets you return to an earlier state and separate changes by purpose.

GitHub is an online service where Git-managed projects can be stored, shared, and reviewed with other people. Git is the tool that creates the history; GitHub is a place where that history can be shared.

Apps such as GitHub Desktop and SourceTree can make Git feel invisible, but buttons labeled Commit, Push, and Pull still run Git operations underneath.

Changes move through three storage stages

Git feels complicated because saving a file does not send it straight to GitHub. A change moves through several stages.

Working files: The state saved by your editor
Local repository: The state recorded as a commit on your computer
Remote repository: The state shared to GitHub by pushing the commit

Deployment is a further step that makes the result available as a website or application.

Operation	What happens?	Does GitHub change?	Does the live site change?
Save a file	The working file is updated	No	Usually no
Commit	The change enters local history	No	Usually no
Push	Commits are sent to the remote	Yes	Only if configured to do so
Deploy	The result is placed in a user-facing environment	Not necessarily	Yes

Three terms before work begins

1. Repository: the container for a project and its history

A repository is the unit that contains a project’s files and Git history. The copy on your computer is the local repository; the copy on GitHub is the remote repository.

2. Clone: create a local copy of a GitHub repository

Cloning copies a remote repository and its history to your computer. You normally do it once when you first join a project, then continue working in the same folder.

3. Branch: separate a change from the main line

A branch is a parallel line of history. Instead of changing main, which may be used for releases, you can experiment on a work branch and merge it later.

Two terms for recording changes

4. Staging: choose what goes into the next commit

Staging selects which edited changes will be included in the next commit. On the command line, this is commonly done with git add.

You can select only the changes relevant to one purpose, even when a file contains several edits. It is also the last good place to check for unwanted files or secrets before committing.

5. Commit: record selected changes in local history

A commit records selected changes in Git history together with a message. It normally lives on your computer first and has not yet been sent to GitHub.

A specific message such as “Add pronunciation to glossary search” is much easier to understand later than “Update.”

Two terms for exchanging changes with GitHub

6. Pull: bring new remote changes into your local branch

A pull retrieves changes from the remote and integrates them into the current local branch. This is how you receive work added by another person or computer.

It is more than a simple download: the standard operation fetches and then integrates. Check the state first if you have uncommitted local changes.

7. Push: send local commits to GitHub

A push sends commits from your local repository to the remote. Commit and push are separate, so you can create history even without an internet connection.

A push may be rejected if the remote already contains newer work. Do not immediately force-push. Pull or fetch first and inspect what changed.

Two terms for bringing work into main

8. Pull request: review changes before integration

A pull request is a GitHub feature for reviewing and discussing the difference between a work branch and a destination such as main. It is often abbreviated to PR.

It is not the same as git pull. Despite the similar name, a pull request is a proposal and review space for merging one branch into another.

9. Merge: combine two branches

A merge integrates changes from one branch into another. When both branches changed the same area differently, Git reports a merge conflict.

A conflict is not a broken repository. It means Git cannot decide which result is correct, so a person must understand both intentions and choose what remains.

The final term that delivers work to users

10. Deploy: make the website or app available

Deployment places a website or application on a server or another environment where users can access it. It is not an operation that records Git history.

Push and deploy are separate, but some projects automatically deploy after a push or merge to main. In that setup, the Push button can become the beginning of a release, so checks before pushing matter more.

The complete workflow in order

Clone the repository
Create a work branch from main
Edit and save files
Stage the relevant changes
Commit them to local history
Pull remote updates when necessary
Push the work branch to GitHub
Review the change in a pull request
Merge it into main when approved
Deploy to the production environment

A small personal site may skip branches and pull requests. In a team or a project with automatic deployment, separating the review stages helps prevent mistakes.

The terms do not change when AI performs the Git operations

Tools such as GitHub Copilot and Codex can edit files, inspect Git state, and help create commits. The impact of commit, push, and deploy remains the same when an AI runs the operation.

Push and deploy are especially important because they affect systems outside your computer. Before delegating them, confirm:

Which repository and branch will be changed
Exactly what the commit contains
Whether pushing will trigger an automatic deployment

At first, ask the AI: “Do not execute anything yet. Explain the current state and the operations that would be required.” Building the habit of reading the diff and understanding the impact is safer than running a command you do not recognize.