I pushed my changes in master (git)

Oops!!!

When we work on big projects we are always taught to avoid directly pushing our code in the master branch. And if something like this happens, it is obvious that we will panic.

But you should know that you can fix everything up very easily. You just have to trust yourself and know what you are going to do next.

A lot of times I have faced this issue. When one person pushes the changes in the master branch by mistake and his/her friends try to help fix things. But instead of helping, they end up making it worse. This blog contains the process to reset the situation to the point when changes were first committed to the master (i.e. when no experimentation had taken place). And the process to get all the changes in your branch and remove them from the master. And push everything as it should be.

Let’s analyse the situation.

Fig-1: Initial situation when changes were committed to master branch

Let me decipher it. You have to start reading the lines of git log command from bottom to top. I created a new git project. Initially, some commits were done in master (4a72f2a to f714b78). Then a ‘new-branch’ was created. Instead of doing the changes in ‘new-branch’, I moved back to master and committed in ‘master’ itself (cb25074 and 491ff7d).

Now let’s do some experimentation to worse things up.

Fig-2 Doing experiments to resolve things

I have reset the head of the ‘master’ branch twice. Okay, what does that mean? And how has this worsened the situation?

What is HEAD?

HEAD is the reference of your last commit or the last action that you did in git. As you can see in both Fig-1 and Fig-2, there is a ‘HEAD’ in cyan colour in each git log.

You can try doing git reflog. You’ll see HEAD in all the lines. HEAD@{0} means the latest action. HEAD@{1} means the action before that and so on… You can also see the commit hash (in yellow) in both git log and git reflog.

Fig-3: git reflog: everything that I have done till now

What is git reset?

Git reset means going back to a particular commit. When in Fig-2, I did git reset --hard HEAD^, that means going back one commit. As you can see in Fig-3, the commit hash in HEAD@{1} is equal to the commit hash in HEAD@{3}, and the commit hash of HEAD@{0} is equal to the commit hash of HEAD{4}. So I basically moved back to commit f714b78.

We’ll be using git reset a lot in this blog.

How is the situation worsened?

If you notice, since we moved back two commits, the last two commits are gone now. We don’t have the changes that we did in those two commits…

This is the panic situation, right? Will you write that code again? But if you missed something then?

Hey hey hey! Don’t worry. It’s okay. The only thing that I can say to console you right now is - git doesn’t delete anything. 😁

Let’s go back to the place where we had all the commits (in master)

Do git reflog. I am referring to Fig-3.

Identify the commit that you last did in master that was correct. For me, it is 491ff7d. Because, after that, I have done the experimentations.

Enter this command:

git reset --hard [your-commit-hash]

For me, it is:

git reset --hard 491ff7d

Fig-4: Went back to the initial situation

Yayy!!! Atleast we are back to where we started. Let’s discuss what we have to do now.

Actual steps to follow

1. We need our changes in ‘new-branch’. So, before deleting anything from ‘master’ we should get the changes in ‘new-branch’.
2. Push the changes of ‘new-branch’.
3. Delete the unwanted changes of ‘master’.
4. Push the changes of ‘master’.

Let’s follow that:

1. Get changes from master to new-branch

Fig-5: Pull master in new-branch

git checkout new-branch
git pull . master

First I checked-out to the new-branch.

Then I took a pull from the local master. The ‘.’ before master means local. How did I know that ‘.’ is local?

Well when we do git remote -v we can see the path of ‘origin’. This ‘origin’ is nothing but a short name given by us for that path. We can make more remotes also (which is not in the scope of this blog).

So basically, if let’s say, the remote origin path is ‘https://github.com/user-name/repo-name.git’. And we want to take a pull from the master branch from ‘origin’ we could do any of these:

git pull origin master
git pull https://github.com/user-name/repo-name.git master

Since right now, we want to take a pull from local, its path is the current folder. And the current path is — ‘.’. I hope that answers the question.

2. Push the changes of new-branch to remote

Since I have not set up any remote for this, I can’t show an image here. But here is the command:

git push

3. Delete the unwanted changes of master

Now you want to take your master to the commit where new-branch initially was. Or maybe some other commit. Just do the git reflog or the git log that I am using. Figure out the hash of commit where you want to go. In my case, it is f714b78.

First checkout to master:

git checkout master

And then go back to that commit:

git reset --hard [commit-hash]

In my case:

git reset --hard f714b78

Fig-6: Go back to certain commit in master

Oops! I did a mistake here. I entered the reset command before going to ‘master’. But then in the next command, I reverted back. Then checked-out to ‘master’. Then went back to that commit. You can see the log now. But where is ‘new-branch’ in git log?

Since master is on a commit which was done before new-branch was created, log doesn’t show any commit after f714b78. But if we checkout to ‘new-branch’ and do git log.

Fig-7: git log from new-branch

4. Push the changes of master

Again checkout to master

git checkout master

Since again I have not set up remote, I won’t be able to show any images. But, when you’ll try to push

git push

It will give you an error. Error is something like, the local branch is behind the remote branch. This is because you have pushed the master when it was on the commit 491ff7d (check Fig-1 for best clarity on the scenario). And now you have reverted back to commit f714b78. That means remote master has more commits than the local master. And thus it will ask you to pull the changes before pushing them. But if you pull at this time, you’ll go back to step-2. And you’ll have to reperform step 3.

The best way to push the changes here is to force push.

git push origin +master
OR
git push --force
OR
git push -f

The ‘+’ before master means force push the changes in the master branch.

And here you go. Back to the place where you should be.

Don’t forget to checkout to your branch again. Otherwise, you’ll have to refer to this blog again.

And with that wish you a very happy coding.