When working with Git in collaborative environments, you'll inevitably encounter situations where you need to overwrite remote history. Two commands come into play: git push --force and git push --force-with-lease. Understanding the difference between these commands can save you from accidentally destroying your teammates' work.
Why rewriting history can happen
In professional development environments, clean Git history isn't just a preference, it's a requirement for maintainable codebases. Many teams follow a "one logical commit per feature" guideline, where each merge to the main branch represents a single, complete change. This approach makes code reviews more focused, rollbacks (git revert) cleaner, and debugging significantly easier when you need to trace issues months later. (git bisect)
During development, however, your feature branch accumulates multiple commits: initial implementations, bug fixes, code review responses, and style adjustments. Before merging, teams typically require you to squash these commits into a coherent story or rebase onto the latest main branch to avoid merge commits that clutter the project history.
Additionally, as main branch development continues, your feature branch falls behind. Rebasing your work onto the current main branch creates a linear history that's easier to follow than a web of merge commits. Some teams also enforce commit message standards or require sign-offs that weren't present in your original commits, necessitating history rewrites to meet project guidelines.
These practices, rebasing, squashing, and amending, all change commit hashes, creating the divergence that requires force pushing to update the remote repository.
Push force can be scary at the beginning but when you are used to it, it's pretty easy !
The problem with standard force push
The git push --force command overwrites the remote branch with your local version, regardless of what changes might exist on the remote. This brute-force approach can lead to serious problems in team environments.
A good rule to follow is to only force push on your own feature branch, but sometimes you work on a bigger branch with a colleague
git push --force origin feature-branch
Consider this scenario: You're working on a feature branch, and a colleague pushes some critical bug fixes while you're doing a rebase. If you force push without checking, you'll completely erase their work.
Force-with-lease: the safer alternative
The --force-with-lease option provides a safety net. It only allows the force push if your local reference matches what's currently on the remote. If someone else has pushed changes since your last fetch, the command will fail.
git push --force-with-lease origin feature-branch
Here's how it protects you:
git fetch origin
git rebase origin/main
git push --force-with-lease origin feature-branch
git push --force-with-lease origin feature-branch
Practical code examples
Basic Usage Comparison
git push --force origin feature-branch
git push --force-with-lease origin feature-branch
Real-world workflow
Here's a typical development workflow using force-with-lease:
git fetch origin
git checkout feature-branch
git rebase origin/main
git push --force-with-lease origin feature-branch
Handling rejected pushes
When force-with-lease rejects your push, here's how to handle it:
git fetch origin
git log origin/feature-branch --oneline
git rebase origin/feature-branch
git push --force-with-lease origin feature-branch
When to use each command
Use --force-with-lease when:
- Working on shared feature branches
- You've rebased or amended commits
- Collaborating with other developers
- You want protection against accidental overwrites
Use --force only when:
- You're certain no one else is working on the branch
- You're working on a personal fork
- You need to recover from a corrupted remote state
- You've explicitly coordinated with your team
The bottom line
Force-with-lease should be your default choice for overwriting remote history. It provides the same functionality as force push while protecting against the most common cause of lost work: accidentally overwriting changes you haven't seen.
The extra safety check takes virtually no additional time and can save hours of recovery work. In collaborative environments, this small change in habit can prevent significant frustration and potential data loss.
Make force-with-lease your standard practice, and reserve regular force push for those rare situations where you're absolutely certain about the state of the remote repository.
![TypeScript's [number] Index Signature: Extract Union Types from Arrays](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1752960594694%2Fe2be9492-869f-4169-bb1a-950ee81a3887.png&w=3840&q=75)