Published in


An Alternative to Force Pushing in Git

How to (not) lose commits & alienate colleagues

You and your Git friend.

Git is an amazing version control system and the obvious choice for a lot of software teams around the world. Fishbrain is no exception. However, as your team grows, so does the count of simultaneous features in development. The need to stay up to date with the remote repository increases and helps you avoid nasty conflicts.

Git provides two options for doing this: merge and rebase. Wether to use one or the other is a hot topic on its own, but we will not dig further into it. At Fishbrain we mostly use rebase and as this option rewrites Git history, we need to push --force when getting our code to our remote. Force pushing safely is what this post is all about.

[--force] can cause the remote repository to lose commits; use it with care.

This is a snippet from the Git documentation on push --force. Seeing your work being blown into oblivion by an unsuspecting colleague is some of the least pleasant experiences you can have as a developer. It sucks. If you have been using push --force in your workflow you might see this risk as a necessary evil, but there is actually a way to make sure that it doesn’t happen to you or your colleagues: push --force-with-lease.

Git normally prevents you from rewriting history by making sure that the changes you push are aligned with what has already been pushed before. This means that your pushed commits must have a common past with the remote commits.--force is an option that allows you to bypass Git’s check for correct ancestry in the remote history. The end result of using --force or--force-with-lease is the same but the latter will ensure that your local reference of what is the latest remote commit is actually correct. It allows you to rewrite history, but prevents you from accidentally removing history by keeping the ancestry check.

As the Git documentation says “If somebody else built on top of your original history while you are rebasing, the tip of the branch at the remote may advance with her commit”. By blindly —-force pushing your work you would replace someone else’s. With --force-with-lease, you won’t.

However, there are some pitfalls when using --force-with-lease. If you fetch from the remote repository implicitly, by some mechanism like in an IDE or through a cronjob, you will update your reference of what is the latest work on the remote repository. Meaning that the remote tracking part of Git that checks that your work indeed is based on the latest work on the remote will fail. Workarounds exist though, such as separating the push and fetch references. See Git’s documentation on the push command for more.

At Fishbrain, our mission is to build the best possible tool for people who love fishing. We believe if you love what you’re doing, surrounded by inspiring colleagues in an environment of growth and development, you will achieve great things. See for open positions!




We make an app for fishing, the world’s most popular hobby.

Recommended from Medium

How to Structure Teams for Building Better Software Products

Combining strict order with massive parallelism using Kafka

Takeaways from using AppSync

Kafka Gotchas

How to Be an Effective Team Player

Building a Hybrid Cloud with Azure

Building a Hybrid Cloud with Azure

Reducing API Latency 50x by Making rDNS Lookups Blazingly Fast

SwiftUI with UICollectionView

Image of a collection view on the Vrbo iOS app main screen overlay on a code snippet for a SwiftUICollectionViewCell class.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Klas Eskilson

Klas Eskilson

Software developer at Billogram. Big fan of the outdoors.

More from Medium

Gitty Workflow

Clean Code interpretation by Robert C. Martin (Uncle Bob).

How to simply push from gitlab runner

Setting up JAVA_HOME on MacOS