Comprehensive Guide to Resolving Git Push Error: ! [rejected] master -> master (fetch first)

Error Phenomenon and Root Cause Analysis

When developers execute the git push origin master command, they may encounter the following error message:

! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'git@github.com:zapnaa/abcappp.git'

The core reason for this error is that the remote repository's master branch contains commits that are not present in the local repository. In distributed version control systems, multiple developers may push code to the same remote repository simultaneously. When other developers have already pushed new commits to the remote master branch, and the local repository has not synchronized these changes, Git will reject the current push operation to prevent historical conflicts.

Safe Solution: Fetch and Merge

Git's error message clearly indicates the solution—fetch first. The correct handling process should follow these steps:

First, use the git fetch command to retrieve the latest state from the remote repository:

git fetch origin master

This command downloads the latest commit records from the remote repository but does not automatically merge them into the current working branch. It only updates the reference of the remote tracking branch origin/master.

Next, merge the remote changes into the local branch:

git merge origin/master

This merge operation integrates remote changes into the local master branch. If conflicts exist, Git will prompt the developer to resolve them manually before committing.

After completing the merge, you can safely push local changes:

git push origin master

Convenient Alternative: Using git pull

For beginners or developers seeking to simplify the workflow, the git pull command can be used, which essentially combines git fetch and git merge:

git pull origin master

This command automatically performs both fetching remote changes and merging them into the local branch. However, it's important to note that in complex merge scenarios, executing fetch and merge separately provides better control and visibility.

Advanced Scenario: Rebase Solution Using Temporary Branch

In specific situations, particularly when developers want to maintain a clean, linear commit history, a rebase solution based on a temporary branch can be employed:

git fetch origin master:tmp
git rebase tmp
git push origin HEAD:master
git branch -D tmp

The execution flow of this solution is as follows: first, create a temporary branch named tmp to save the latest state of the remote master; then rebase local commits onto the tmp branch; next, push the rebased commits to the remote; finally, delete the temporary branch. This method is particularly suitable for scenarios where merge commits are to be avoided.

Dangerous Operation: Risks of the --force Option

Although using the --force option can force push and overwrite remote history:

git push origin master --force

This approach carries significant risks. In team collaboration environments, force pushing rewrites commit history, causing inconsistencies between other developers' local repositories and the remote repository. This can lead to data loss, collaboration chaos, and may require the entire team to re-clone the repository. Git official documentation explicitly warns against using force push except in extremely special circumstances.

Best Practices and Preventive Measures

To avoid frequently encountering the fetch first error, the following best practices are recommended:

Before starting new development work, always execute git pull or git fetch first to synchronize with remote changes. Establish regular synchronization habits, such as performing git fetch hourly to monitor changes in the remote repository state. In team settings, define clear coordination mechanisms for code pushing to avoid conflicts from multiple developers modifying the same files simultaneously.

Understanding Git's fast-forward merge concept is also crucial. When the local branch can directly move to the latest commit of the remote branch, Git performs a fast-forward merge, which doesn't create additional merge commits. When both local and remote have new commits, a merge commit is needed to integrate changes from both sides.

In-depth Interpretation of Error Messages

Git's error messages typically contain valuable hints. Beyond the main error description, detailed help information is often included:

hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.

These hints clearly indicate the cause of the problem and the solution. Developers should develop the habit of carefully reading error messages.

Conclusion

The ! [rejected] master -> master (fetch first) error is an important mechanism through which Git protects repository integrity. By understanding the fundamental principles of distributed version control and adopting proper fetch-merge workflows, developers can effectively handle such conflicts while maintaining healthy team collaboration environments. Remember that safe methods, though potentially requiring additional steps, prevent potential data loss and team collaboration issues.