-1

I have change some file, added one file and execute below command :

step 1. git add -A

step 2. git commit -m 'test'

after that when use : git push origin integration then it will take long time because i have mistakenly added one large size file. so i just need to remove this last commit and need to start with step 1 so i remove this large file and push again

Dhaval Vaghela
  • 440
  • 4
  • 20
  • 3
    Possible duplicate of [How to undo the most recent commits in Git](https://stackoverflow.com/questions/927358/how-to-undo-the-most-recent-commits-in-git) – Nir Duan Feb 07 '18 at 11:29

1 Answers1

4

This answer assumes that your push has not yet succeeded, but you have made the commit. In this case, since no one else has seen your branch with the large commit, you should be safe in actually nuking that commit:

git reset --hard HEAD~1

This will remove the head commit, and after this you may continue your work. A slightly nicer, less risky option, would be to instead do a soft reset:

git reset --soft HEAD~1

This would leave the changes from the top commit in the stage. You could then unstage the large file, and recommit your work.

Note that if you have already made a successful push with that large commit, then you have a much bigger problem on your hands. Now, even if you revert that commit, the large file will still be a part of the history in the repo. In this case, you will need a tool like the BFG repo cleaner to remove the large file.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
  • Thanks for your ans. But can i use this command safely ? it means it will stay as it is all commit which is push before this last commit ? – Dhaval Vaghela Feb 07 '18 at 11:20
  • @Camit1dk If you completely don't need the commit with the large file, _and_ you _haven't_ yet pushed that branch, then a hard reset is appropriate. If you _do_ need some of the work, then do a soft reset and unstage the large file. If you _have_ already pushed, then do neither of these. You have a big problem, and will have to remove that large file from the history using a more heavy-weight tool. – Tim Biegeleisen Feb 07 '18 at 11:23
  • And yes, all commits before the last one (both in your working copy and on origin) will be completely untouched and safe with either of the solutions in Tim's answer. – anothernode Feb 07 '18 at 11:27
  • "completely obliterate the head commit" - I understand you said this for simplicity and brevity, but isn't it misleading? – evolutionxbox Feb 07 '18 at 11:32
  • @evolutionxbox Git is fairly flexible in its own language, even in the official docs themselves. I changed my language to use "remove" instead of "obliterate." – Tim Biegeleisen Feb 07 '18 at 11:35
  • Heh. I guess it’s just the word used implies the commit can’t be recovered. – evolutionxbox Feb 07 '18 at 11:36
  • Yes, I suspected this was your concern. Of course, it should be in the reflog, unless some mean person wiped that too :-) – Tim Biegeleisen Feb 07 '18 at 11:36