Git : How to reset the history of all the repositories associated with a project?
We are two developpers working on a project, using a central repository on BitBucket.
Sometimes I want to reset the history to a specific revision (I know this loses information) :
git.exe reset --mixed 0e827d5fcb7d9b git.exe push --all --force
This correctly resets the history to the revision I want. But if the second developer doesn’t do the same thing, if he doesn’t reset his own local repository, then the next push he is going to make will add back all the commits I removed with that reset!
When there are only two developers on the project, it’s not that bad. I could probably ask the other dev to run the same reset on its local repo and the history on BitBucket will stay as I want. But I’d like to know if there is a way to force the reset of the history of all the repositories associated with that project? A way to force the second dev to have its local repo to be resetted as mine before he can push to BitBucket again?
Or maybe I’m missing something obvious (I’m not a Git master)…
3 Solutions collect form web for “Git : How to reset the history of all the repositories associated with a project?”
You could simply reset and create a separate branch.
git checkout -b newBranch 0e827d5fcb7d9b git push -u origin newBranch
Pushing that new branch would allow you to have your own branch to reset and force push without bothering the second developer.
But if you want to force the second developer to reset his/her own workspace before pushing back, you should:
- reset (as you are doing)
amend the commit (forcing the commit 0e827d5fcb7d9b to have a new SHA1)
git commit --amend -m "reset branch"
Then any push from other developers would be rejected by default, as being non-fast-forward.
They would need to fetch, and either rebase their own branch on top of
origin/master. Or reset they own working tree to the new
With your current model of all devs having write access to the “central” repo, this is impossible.
However, this entire workflow does not scale well for too many developers. You might want to consider another topology of repos, where each dev has a private and a public repo. All devs have write access to their own public repo (SSH), and read-only access to the others’ public repos (HTTP?).
Each dev pushes his changes to his own public repo, and asks the Dictator to pull from it. The Dictator in turn fetches from the dev’s public repo into his own local one, and inspects the branch. He rejects it if it’s based on a previously deleted commit.
This assumes having a Dictator in the project who is responsible for merging others’ stuff. The dictator’s
origin remote will point to his own public repo and he will have other remotes to his fellow devs’ public repos to pull from. The other devs will also have an extra remote, best called
upstream, pointing to the Dictator’s public repo, to fetch the official state of the project.
No, there is no way to force other developers to do anything.
It helps if you understand that a branch in
git is nothing of substance. It is simply and literally just a string pointing to a commit. It has no structure and nothing else to it.
This means that
git push --all --force does nothing special except updating all the branch “sticky notes” on the remote to point to whichever commits you have them pointing at in your local repository.
To get the other developers to take your changes, you have to communicate with them and tell them to do something like
git fetch ; git branch -D somebranch ; git checkout somebranch which will have the effect of deleting their own
somebranch sticky note and replace it with yours (that they just fetched from the remote).
somebranch can be
master since there is nothing magic about the
master branch at all, it also is just a sticky note pointing to some commit.
If you do as you said, i.e. a
reset followed by a forced push, you have created havoc with the other developers anyways; they basically only have the choice of either taking your changes as is, or overwriting them in the same fashin; merging or other things are pretty much out of the question as they will likely end up in chaos.