0

I pushed the X commit to my feature branch.

When I check history via Github Desktop, I realize just one file doesn't need to be in this commit: History seems like as below:

X commit
A file changed-- ok
B file changed-- ok
C file changed-- not ok for me.. I had changed this by mistake.

Is there any way to go back to this original file (the state before my commit) without reverting the commit?

My only way is to find the file from the origin-develop and copy and paste my feature branch and make a new commit for this.

roadRunner
  • 173
  • 1
  • 23

1 Answers1

1

Is there any way to go back to this original file (the state before my commit) without reverting the commit?

Certainly. The file's state before this commit is sitting there in the previous commit. (All commits are snapshots of all the files.)

What you cannot do, however, is alter the commit you have made. Commits are immutable; Git would be pretty useless otherwise.

My only way is to find the file from the origin-develop and copy and paste my feature branch and make a new commit for this.

Yes, and...? So do that.

If what you object to is that you then have two commits where you would prefer to have one, then squash them together after making the second commit; interactive rebase is an easy way to do that, though personally in this situation I would use soft reset, as explained in my What's the difference between git reset --mixed, --soft, and --hard? (this is Regret Type 1). But do not do this if you have already pushed this branch with that previous commit to shared location (such as a pull request). You should not rewrite public history.


Example. We start with this situation (this is a log, so the commits run from newest down to oldest):

* 78f90c1 edited all three files
* 5ec87ed created three files

We edited three files; call them aaa.txt, bbb.txt, and ccc.txt. We regret the edit of ccc.txt and wish to restore it, and it alone, to the state that it was in 5ec87ed.

git restore -s @~1 -- ccc.txt
git add .
git commit -m 'restored ccc.txt'

Done. We now have this:

* 75c192b (HEAD -> what) restored the third file
* 78f90c1 edited all three files
* 5ec87ed created three files

But if we prefer to have only one commit where now we have two (remember, don't do this if you've already pushed the first two commits):

% git reset --soft @~2
% git commit -m 'edited just two files'

Result:

* e0a324a (HEAD -> what) edited just two files
* 5ec87ed created three files
matt
  • 515,959
  • 87
  • 875
  • 1,141
  • if I squash three commits to one commit ( if that file same ) nobody would see any changes in the history regarding this file having been changed. Because it will snapshot again. – roadRunner Apr 09 '22 at 14:01
  • 1
    And my understanding was that that was what you wanted. But if not, then don't do that. I mean, since you say you know how to do the very thing you claimed to want to do, it's hard to see what the question is unless there is some _other_ thing you _also_ want to do, so I was trying to guess what that might be. – matt Apr 09 '22 at 14:05
  • Added example code you can work from. – matt Apr 09 '22 at 14:06
  • you got my point thank you.. I made a pull request and after a change request from my colleague specifically for this file.. I will copy and paste this file and make a new commit.. When my pr is done, I will squash all commit and merge-rebase to dev branch – roadRunner Apr 09 '22 at 14:09
  • 1
    Yes, and just pushing the new commit will automatically append it to the end of the pull request, which is just what you want. — Note that none of that (the pull request) was in _the question you asked_. To get better help, ask better questions. I'm going to leave the squash stuff there, because it might be useful to others; but you should _not_ rewrite history on a branch that has been submitted as a pull request. – matt Apr 09 '22 at 14:11