A Comprehensive Guide to Viewing Unpushed Commits and Differences Between Local and Remote in Git

In the daily use of the distributed version control system Git, developers often need to confirm the changes committed locally before pushing code to a remote repository. This not only prevents accidental pushes of incorrect code but also ensures smooth team collaboration. This article systematically explains how to view differences between local and remote tracking branches based on Git's core commands.

Understanding the Relationship Between Local and Remote Branches

In a Git workflow, when using the default configuration of git clone, local branches are typically associated with remote tracking branches named origin. For example, the local master branch tracks origin/master, meaning origin/master is a local reference point for the remote repository's master branch. To view unpushed commits, the essence is to compare the commit history of the local branch with that of the remote tracking branch.

Using git log to View Commit Differences

Git offers the powerful git log command to display commit history. With specific syntax, it can precisely compare commit differences between two branches.

Viewing Commits Present Locally but Not Remotely

To view all commits that have been made locally but not yet pushed to the remote repository, use the command:

git log origin..HEAD

Here, origin is the default name for the remote tracking branch, and HEAD points to the latest commit on the current local branch. The double-dot .. syntax means "commits that are in the second branch but not in the first." Thus, this command lists all commits in HEAD (local branch) that are not in origin (remote tracking branch), i.e., unpushed commits.

Viewing Commits Present Remotely but Not Locally

In some cases, it may be necessary to fetch remote updates first before comparing differences. Execute:

git fetch
git log HEAD..origin

git fetch downloads the latest data from the remote repository to the local remote tracking branch (e.g., origin/master) without merging into the current branch. Then, git log HEAD..origin shows commits that are in origin but not in HEAD, i.e., updates present remotely but not locally. This is useful for checking conflicts or new changes before pushing.

Practical Application Example

Suppose a developer has committed multiple files on the local master branch over several days without pushing. By running git log origin..HEAD, they can view detailed information about these commits, including commit IDs, authors, dates, and commit messages. For example:

commit abc123
Author: John Doe <john@example.com>
Date:   Mon Jan 15 10:00:00 2024 +0800
    Added new feature X

commit def456
Author: John Doe <john@example.com>
Date:   Tue Jan 16 14:30:00 2024 +0800
    Fixed bug in module Y

This provides a clear view of the commit history, helping the developer confirm which changes are about to be pushed.

Supplementary Method: Using git diff to View File Differences

Beyond viewing commit history, sometimes it's necessary to understand the specific changes in files. The command git diff --stat origin/master.. mentioned in Answer 1 can quickly summarize modified files and their line changes in unpushed commits. For example:

src/main.py | 5 +++--
tests/test.py | 10 ++++++++++
2 files changed, 13 insertions(+), 2 deletions(-)

This offers a concise overview, suitable for quickly verifying the scope of changes before pushing. Combining git log and git diff allows developers to fully grasp unpushed changes.

Workflow Recommendations and Best Practices

In real-world development, it is advisable to use these commands regularly to maintain repository synchronization. For instance, before each intended push, first run git fetch to update the remote tracking branch, then use git log HEAD..origin to check for remote updates that need merging, followed by git log origin..HEAD to confirm local commits. This effectively avoids push conflicts and code overwrite issues.

Furthermore, understanding the semantics of branch comparisons in Git is crucial. The double-dot syntax A..B means "commits in B but not in A," while the triple-dot syntax A...B means "commits in either A or B but not in both." For viewing unpushed commits, the double-dot syntax is more direct and commonly used.

Conclusion

Through the commands git log origin..HEAD and git log HEAD..origin, developers can efficiently view commit differences between local and remote branches, ensuring the accuracy and safety of push operations. Combined with supplementary tools like git diff --stat, this enhances the reliability of version control workflows. Mastering these core concepts helps reduce errors and improve development efficiency in team collaborations.