What is the difference between git add, git commit, and git push?

Imagine you're packing for a trip. git add is like putting clothes into your suitcase (staging area). git commit is like zipping the suitcase shut and labeling it with a tag (creating a permanent snapshot). git push is like handing the suitcase to the airline (uploading to the remote server). You can keep adding items to the suitcase before zipping it, and you can zip multiple suitcases before heading to the airport.

These three commands represent the fundamental Git workflow and map to Git's three main areas: the working directory, the staging area (also called the index), and the repository. When you edit files, changes exist only in your working directory. Running git add selectively moves changes from the working directory into the staging area. This is a deliberate design choice that lets you group related changes into a single, logical commit even if you've modified many files. Running git commit takes everything in the staging area and creates an immutable snapshot in your local repository with a unique SHA-1 hash, author information, timestamp, and commit message.

Internally, git add computes the SHA-1 hash of the file content and stores a blob object in Git's object database (.git/objects). It also updates the index file (.git/index) to point to this new blob. When you run git commit, Git creates a tree object representing the directory structure, a commit object that references this tree plus metadata, and updates the branch pointer (e.g., refs/heads/main) to point to the new commit. The commit object also contains a pointer to its parent commit, forming the chain of history.

In a production team workflow, the separation between commit and push is critical. You might make several local commits throughout the day, squash or rebase them for clarity, and then push a clean set of changes for code review. This workflow is standard at companies running trunk-based development or GitFlow. CI/CD pipelines typically trigger on push events, so understanding when changes become visible to the pipeline matters. A common pattern is to push to a feature branch, which triggers automated tests, and then merge to main via a pull request.

A common beginner mistake is running git commit without first running git add, then wondering why nothing was committed. Another gotcha: git add . stages everything in the current directory recursively, which can accidentally include build artifacts, .env files with secrets, or large binary files. Always check git status before committing. Also, git push can fail if the remote has newer commits. In that case, you need to pull and merge (or rebase) first. Never force-push to shared branches without team agreement.