Is it possible to delete previous commits and only remain the current one?

Asked

Viewed 135 times

6

While I was modifying the profile README, I ended up making many attempts and solving some errors, it generated me 90 commits in a single file.

I wonder if you can delete all the previous commits and leave only the current one.

My profile: https://github.com/tayhsn

  • Yes it is possible.

  • 1

    otimoo. can you tell me how? by favorrr

  • I could see that I am very beginner né kkkkk I made a hundred and so many changes to get a result, imagine me venturing in this there, I don’t want to fuck everything

  • I thought the github profile was really cool, where do I get the template from? Congratulations.

  • https://github.com/anuraghazra/github-readme-stats the Stats and the Most used Languages was from that repository

  • Thanks!! I had a lot of work to do it works well kkkkk but I gave it. now I just want to tidy up, I have 10x commits that Repositorios. Ah, if you want to know about the skills, just open the raw of the readme and copy, it’s the easiest way

  • https://stackoverflow.com/q/5189560

  • thanks, but I’m not sure I understand very well. Voce could pass me the command?

Show 3 more comments

2 answers

5

I don’t know if the Github interface can do it, but anyway I prefer the command line.

First you clone the repository on your machine:

git clone http://url.do.repositorio

Obviously, by changing url.do.repositorio by the repository URL you want to move.

Then to go back 90 commits and "join" all in one:

git reset --soft HEAD~90
git commit -m "juntando 90 commits"

The "joining 90 commits" message can be exchanged for whatever you want, of course.

Basically, HEAD~90 means "90 commits back" and reset --soft back to this commit, but without modifying the files (read here to better understand what git reset ago).

That is, I go back 90 commits, but without modifying the current content of the files. And then I do a commit, that will have all the changes of the 90 commits (because the contents of the files will not be changed).

In other words, the repository was like this:

commit 1
commit 2
....
commit 90
commit 91 <-- estou aqui

Going back 90 commits, I get the first one, but the content of the files remains the same as commit 91:

commit 1 <-- após git reset --soft HEAD~90, estou aqui
...
commit 91 <-- mas o conteúdo dos arquivos continua igual a este

After the git commit:

commit 1
commit novo <-- novo commit, contendo o conteúdo dos 90 commits (do 2 ao 91)

By the way, this is an important detail: if you have exactly 90 commits, to return to the first you must use HEAD~89.

Another detail is that this whole process will create a new commit, and the previous ones will be outside the "tree" (it won’t be possible to get to them since they were "lost" and replaced by the new commit). Remembering that this way you will have 2 commits (the first and the new).

So when sending to Github, you should do git push -f to overwrite old commits. Only read here to understand the implications of a "push force".

And instead of using the amount, you can also do the reset for a specific commit, using its hash:

git reset --soft hash-do-commit

Being that the hash is that huge text that appears in git log. Example:

$ git log
commit a493c0d479c37cbec9c9899d4fb97c323b7c3364 (HEAD -> master)
Author: Fulano
Date:   2018-09-01 13:12:01

    juntando tudo

commit 36da3462ecbce934cd88c96d8a3205ca25b5a489
Author: Fulano
Date:   2018-09-01 13:11:45

    primeiro commit

In this case, a493c0d479c37cbec9c9899d4fb97c323b7c3364 and 36da3462ecbce934cd88c96d8a3205ca25b5a489 are the hashes of the 2 existing commits.


Another way is to use rebase.

I made an example with only 4 commits:

$ git log --oneline 
7566a92 (HEAD -> master) quarto commit
668185f terceiro commit
8bc39c6 segundo commit
36da346 primeiro commit

And I want to put everything into one, so just do:

git rebase -i HEAD~3

Note that the highest possible value in HEAD~N is the amount of commits minus 1.

This will open a screen like this:

pick 8bc39c6 segundo commit
pick 668185f terceiro commit
pick 7566a92 quarto commit

... mais um monte de informações

In the "information pile" there is a brief explanation of the available options. To join the commits, I choose the "squash" option, or simply "s". So just edit the information to look like this:

pick 8bc39c6 segundo commit
s 668185f terceiro commit
s 7566a92 quarto commit

... o resto você não mexe

That is, the first on the list I keep, the rest I put together (I do the "squash").

Then another screen/editor will open with the commit messages of all commits involved in the operation (i.e., in your case all 90 messages will appear).

Edit the message and save. All commits will be merged into one (remembering that you will also end up with 2 commits: the first and the new one that was generated now).

Then it will also be necessary to do the git push -f to update the remote repository.

In the case of 90 commits, this process is a bit more boring because you would have to edit many lines, and so the first option above (with reset) seems quicker to me.

4

I would like to propose one more option besides those described by hkotsubo:

  • redo the commit
  • rebase interactive with squash
  • merge with squash

To make the merge with squash I will demonstrate by joining the last 8 commits of history below:

* b992307 (HEAD -> main, origin/main) Preload above the fold assets
* 0c056bf Tune responsive and supported styles
* 689ae42 Add logo in english page
* 558897c Fix typo
* 7a75bed Add social preview meta tags
* a77ab4e Update background fallback color
* f0ed2ee Reduce code indent size
* aec4690 Add fallback background color, reduce CSS
* 8980c33 Merge 'look-and-feel' into main
  1. identify the first commit to unify: aec4690 Add fallback...
  2. copy the previous commit ID: 8980c33
  3. create a temporary branch in that commit: git checkout -b tmp 8980c33
  4. merge the branch with squash: git merge --squash main
  5. commit (squash merge does not do the commit): git commit -m "Descrição ..."
  6. remove the previous branch: git branch -D main
  7. rename temporary branch to main: git branch -m tmp main
  8. send to remote forcing override: git push -f origin main

Note: You have to be very careful when rewriting your GIT history, whether other people use the repository or whether it’s a public project, this action will "break" the history for other people. Always take this into account when you need to do some history rewriting action, if possible use an alternative process.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.