Understanding the differences between `git commit` and `git push`

Greg Foster
Greg Foster
Graphite software engineer


Note

This guide explains this concept in vanilla Git. For Graphite documentation, see our CLI docs.


In Git, the workflow for saving and sharing changes involves several steps, each serving a specific purpose in the version control process. This guide will explore these differences, along with related commands like git stage and git pull.

  • git stage (or git add) prepares changes for a commit by adding them to the staging area. The staging area, also known as the index, serves as an intermediate snapshot of your work, a buffer between your working directory (where you make changes) and your repository (where your history and commits live). The staging area allows you to curate and prepare changes before committing them to the project's history. Adding changes to the staging area is the first step in capturing modifications to your project in Git.
  • git commit takes everything from the staging area and records it as a snapshot in the repository's history, providing a clear, descriptive message for the changes made.
  • git push uploads your committed changes to a remote repository, sharing them with others and backing them up on a server.
  • git commit is a local operation; it affects only your local repository and does not interact with the remote repository. Until they're pushed, commits exist only on your local machine.
  • git push is a network operation that transfers commits from your local repository to a remote repository. This makes these commits accessible from the remote repository.
  1. After modifying a file, stage it for commit:
Terminal
git add modified_file.txt
  1. Commit the staged changes with a message:
Terminal
git commit -m "feat: add new feature to modified_file"

You should then see something like:

Terminal
[main 1d2a3f4] feat: add new feature to modified_file
1 file changed, 1 insertion(+)

This output indicates that the commit was successful, showing which branch it was made on (main), the commit hash (1d2a3f4), and the changes made (1 file changed, 1 insertion). For now this commit only exists locally.

After committing, push the changes to the remote repository:

Terminal
git push origin main

Terminal output:

Terminal
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 358 bytes | 358.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/yourusername/yourrepo.git
4a5b6c7..1d2a3f4 master -> master

This output details the process of pushing your commits to the remote server, including the objects transferred and the update from the previous commit hash (4a5b6c7) to the new one (1d2a3f4) on the master branch.

  • Commit often: Each commit should represent a logical unit of work. Committing often makes it easier to understand changes and revert them if necessary.
  • Push selectively: Push your changes when they are ready to be shared or when you need to collaborate with others. Pushing is necessary to actually having your changes take effect in the remote repository.

git commit records your changes locally, allowing for detailed tracking and control over your project's evolution. git push uploads these commits to the remote repository. Together, these commands form the backbone of Git's distributed version control, enabling seamless teamwork and project management.

For more information see Git's official documentation.

Graphite
Git stacked on GitHub

Stacked pull requests are easier to read, easier to write, and easier to manage.
Teams that stack ship better software, faster.

Or install our CLI.
Product Screenshot 1
Product Screenshot 2