1

I created a new branch from development branch and started writing code and pushing it to GitHub.
But after a while the development branch was updated.

So I needed to update the changes and rebase my code.
I checked out development and did a git pull and then I checked out the new branch again and did a git rebase development.

After that, I pushed the commits to remote, and now it shows that there are codes from someone else's commit in my commit.

I looked over some documents but was confused about what I should do exactly.

How can I go back to previous state before rebasing?
Or can I solve this from the point I am on now?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Shamim Fahad
  • 132
  • 2
  • 12
  • I don’t see why there’s a problem. “the development branch was updated. So I needed to update the changes”. You did. That’s where the “codes from someone else's commit” came from. You wanted to acquire what had happened on development and you did. – matt Aug 24 '20 at 05:00
  • but they want me to remove their code from my commit – Shamim Fahad Aug 24 '20 at 05:00
  • I mean their code should be in their commit, right? why is it in my commit in the first place? – Shamim Fahad Aug 24 '20 at 05:01
  • @matt I suspect that the OP is confused actually about how rebasing works. The intercalation of someone else's commit before the OP's work is where the confusion might be. – Tim Biegeleisen Aug 24 '20 at 05:02
  • 1
    Code does not live in one commit. Every commit consists of all the files. You rebased, thus causing the other persons changes to become your own history and thus appear in your code. That is what rebasing is. If you’re sorry you rebased, undo it. See https://stackoverflow.com/questions/134882/undoing-a-git-rebase – matt Aug 24 '20 at 05:06
  • Does this answer your question? [Undoing a git rebase](https://stackoverflow.com/questions/134882/undoing-a-git-rebase) – LeGEC Aug 25 '20 at 06:49
  • No, I reordered commits and deleted their commit from my code – Shamim Fahad Aug 25 '20 at 07:16
  • `git pull` is the most overrated Git commit. Forget about it. Always use `git rebase`. On the code level, they produce the same results (and the same conflicts, if there are conflicts). On the Git history level, `git pull` produces useless merge commit that are confusing on review. `git rebase` produces a more clean Git history. – axiac Jul 11 '23 at 18:53
  • `git rebase` after `git pull` is a no-op if you want to rebase on top of the same branch that you merged. Your goal is probably to revert to the state before `git push`. A Git GUI client can help you understand how Git operations work and where you want to go back. – axiac Jul 11 '23 at 18:54

1 Answers1

0

How can I go back to previous state before rebasing?

Undoing the rebase operation

You can use the git reflog command to see the history of what has been done in your git. It records when the updates to the tip of branches and other references were updated in the local repository. Default is 90 days before gc (garbage collection).

You will see a list of every thing you have done in Git, across all branches. Each line will start with an index like HEAD@{5}, and show what that HEAD pointed to at that point in time. Find the place where you want to go back to and use the index to reset your HEAD to that point.

git reset --hard HEAD@{5}

Be careful with git reset --hard command. It will delete any uncommitted changes.

Or can I solve this from the point I am on now?

Interactively rebasing and dropping the commits

First, find the commit hash you want to go back to. That should be the commit just before the first commit you want to remove. You can find this by using git log command.
Once you have got the commit hash, you can start an interactive rebase with the parent of that commit.

git rebase -i <commit-hash>^

In the text editor that comes up, you will see a list of commits that will be rebased (played back). To remove a commit, delete the line or replace pick with drop or d. Once you are done, save and exit the editor.

Git will then replay the remaining commits. If there are conflicts, it will pause and allow you to resolve those conflicts; after which, you can continue the rebase with git rebase --continue.

If you decide at any point that you want to stop the entire process and go back to where you were, you can use git rebase --abort.

Once you are done, you can push your changes to the remote repository.
If the branch has been pushed before, you will need to use git push --force origin branch-name to force the push.

Warning: Force pushing can be dangerous if others are working on the same branch, as it can overwrite their changes. It is a good idea to communicate with your team before doing a force push.

The git push --force-if-includes that I mention here can help secure that step.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250