Understanding and Resolving Git Push Rejections

Git is a powerful version control system, but encountering errors during git push can be frustrating. One common error message is "remote rejected: master -> master (branch is currently checked out)". This tutorial explains the reasons behind this rejection and provides several solutions.

Why Does This Happen?

The error occurs when you attempt to push changes to a remote branch that is currently checked out (i.e., actively being used) in the remote repository. Git prevents this operation by default to avoid potential inconsistencies and data loss.

Here’s the problem: a push updates the remote branch’s history. If someone is actively working on that branch, those local changes might be overwritten or become difficult to merge cleanly. Git prioritizes the integrity of the remote repository and protects it from accidental corruption.

Imagine two developers working on the same file. If one directly overwrites the other’s changes via a push to the active branch, it can lead to lost work and a messy history.

Core Concepts

Remote Repository: A version of the project hosted on a server (e.g., GitHub, GitLab, or a private server).
Local Repository: The version of the project on your computer.
Branch: A separate line of development within a repository. master (or main) is the primary branch.
Checked Out Branch: The branch you are currently working on. Changes you make are applied to this branch.

Solutions

Here are several ways to resolve this issue, ranging from best practices to quick fixes:

1. Use Bare Repositories (Recommended)

The most robust solution is to use a bare repository on the remote server. A bare repository contains only the Git history; it doesn’t have a working directory (the files you actively edit). This means no one can directly edit files on the remote server, eliminating the possibility of conflicts.

To convert an existing repository to a bare repository on the remote server:

git config --bool core.bare true

After running this command, remove any files or directories except the .git directory. This ensures that only the Git history remains. Then, you can push to this repository without encountering the rejection error.

2. Push to a Different Branch

Instead of pushing directly to the master (or main) branch, create a separate branch for your changes. This allows you to integrate your work without disrupting the active branch on the remote.

Create a new branch locally:
```
git checkout -b feature/my-new-feature
```

Commit your changes to the new branch:

git add .
git commit -m "Implemented my new feature"

Push the new branch to the remote:
```
git push origin feature/my-new-feature
```
Create a Pull Request (or Merge Request): On platforms like GitHub or GitLab, you can then create a pull request to merge your feature/my-new-feature branch into master. This allows for code review and ensures a clean integration.

3. Pull Before Pushing (If Appropriate)

If you’re collaborating with others and want to integrate their changes before pushing your own, you can pull from the remote repository before pushing. This merges the remote changes into your local branch.

git pull origin master

Important: Be mindful of potential conflicts when pulling. Resolve any conflicts before committing and pushing.

4. Temporarily Allow Pushing to a Checked-Out Branch (Not Recommended for Production)

While strongly discouraged for production environments, you can temporarily configure the remote repository to allow pushing to a checked-out branch. This carries the risk of data loss and inconsistencies.

Edit the .git/config file on the remote server and add the following section:

[receive]
denyCurrentBranch = warn

Or, to completely disable the check:

[receive]
denyCurrentBranch = false

Caution: Only use this approach if you fully understand the risks and are in a controlled environment (e.g., a development server). It’s best to revert this setting after you’ve finished your work.

Best Practices

Use Bare Repositories for Remote Servers: This is the most reliable solution to prevent conflicts and data loss.
Branching Strategy: Adopt a well-defined branching strategy (e.g., Gitflow, GitHub Flow) to manage changes effectively.
Regular Pulls: Regularly pull changes from the remote repository to stay up-to-date.
Code Review: Implement code review processes to ensure code quality and prevent errors.