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 vs git commit vs git push

• 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 vs git push

• 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.

Examples

Committing changes

1. After modifying a file, stage it for commit:

git add modified_file.txt

2. Commit the staged changes with a message:

git commit -m "feat: add new feature to modified_file"

You should then see something like:

[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.

Pushing changes

After committing, push the changes to the remote repository:

git push origin main

Terminal output:

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.

When to commit and when to push

• 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.

Recap:

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.