For every “update” we do in our local repository, Git creates a reference log entry. In this case, we’ll use the git reflog command which outputs a detailed history of the repository. Now, the great thing about Git is that it is very best to never lose data, so the version of the repository before the rebase is still available. But something bad happened and you want to restore your branch to the way it was before the rebase -i. Then you squashed the commits into one, using git rebase -i and pushed again using push -force. Imagine working on a feature branch, you pulled some changes, created a few commits and completed your part of the feature and pushed your changes up to the main repository. I accidentally -force pushed to my repo, and I want to go back to the previous version. Your only option is to fight fire with fire and push -force this commit back to the branch on top of the bad one:Ĭongratulations! You saved the day! □ 2. The first group of symbols(which look like a commit SHA prefix) is the key to fixing this.ĭ02c26f is your last good commit to the branch before you inflicted damages. In the output of the git push -force command in your terminal look for the line that resembles this one: □ Finally, make sure no one messes with the repo for the next couple of minutes because you have some work to do. □ Second, go to your teammates and confess your sins. You were the last person to push before the mistake? □ If so, all you have to do is to ask him/her to -force push their recent changes!īut even if you are not that lucky you are still lucky enough to find this tutorial. No need to panic! If you are very lucky someone else who is working on the same code pulled a recent version of the branch just before you broke it. You are without a doubt a responsible developer but I bet it happened to you at least once, that you or one of your teammates accidentally ran git push -force into an important branch that should never be messed with and Oops! In the blink of an eye, everybody’s latest work is now lost. Guide: How to deal with destructive -force It’s the same force but with a life vest. force-with-lease gives you the flexibility to override new commits on your remote branch whilst protecting your old commit history. Pretty great right? It becomes even better(!!) you can specify - force-with-lease exactly which commit, branch or ref to compare to. On default, -force-with-lease will refuse to update branch unless the remote-tracking branch and the remote branch points to the same commit ref. The -force option has a not so famous relative called - force-with-lease, which enables us to push -force our changes with a guarantee that we won’t overwrite somebody else’s changes. Shame on you Bob! Alternative: push - force-with-lease you must wonder why? Well… force pushes the changes with no regard to the state of the tracked branch, therefore commits might get lost in the process. One of the common mistakes using this command is when Bob forgets to update (git pull) his local tracked branch, in this case, using the force might cause Bob a lot of trouble. If there is an ancestor commit that exists in the remote and not in local(i.e someone updated the remote and we are not up to date) Git won’t be able to find a linear path between the commits and git push will fail. When our changes are pushed Git automatically searches for a linear path from the current ref to the target commit ref. Integrates the histories by forwarding the remote branch to reference the new commit, also called Fast forward ref.įast forward is simply forwarding the current commit ref of the branch.Copies all the commits that exist in the local branch.A branch for that matter is nothing but a pointer to a single commit. For Git everything is about commits, a commit is an object that includes several keys such as a unique id, a pointer to the snapshot of the staged content and pointers to the commits that came directly before that commit. To understand how git works under the hood we need to take a step back and examine how Git stores its data. You will be surprised how the ‘force’ is actually with you □□ The push command In this tutorial, I will share my discoveries so you too can understand the usage and impact of this command on your project, learn new, safer alternatives, and master the skills of restoring a broken branch. This led me to research why is this command considered to be so harmful? Why does it even exist in the first place? and what happens under the hood? However, to me, it seemed very strange to put all my trust in Git with my projects and at the same time completely avoid using one of its popular commands. It is well known that using Git’s push -force command is strongly discouraged and considered destructive.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |