An Alternative to Force Pushing in Git

How to (not) lose commits & alienate colleagues

Klas Eskilson
Feb 16, 2019 · 3 min read
Image for post
Image for post
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!

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

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