9 votes

Why should not I rewrite published commits?

I always read and say that it is dangerous to rewrite commits published in git (that is, they can exist in third party repositories).

What problems does it cause, punctually? Why do these problems occur?


Gepser Points 2525

It is not recommended to make git commit --amend or git reset in the public archives, for the simple reason that the commits new replace the old ones and in the history of your repository is going to look as if a piece of it just disappeared.

However, these tools are there for a reason and that reason is that they are useful for polishing or enhance the story of our repositories. For example, if you had a repository with a lot of commits useless or obsolete then you have the opportunities to put them together with commits yes are significant and at the end of the history of your repository will look neat and clean.

You can see more information on occasions in which it is useful to rewrite the history of the repositories here.

The note of caution is for other developers who might have cloned your repository to not have problems navigating in the history of commits. If that happens, and you do various amends simultaneous could result in confusion rather large in the repository even though the probability is very small.

You can see a little more detail this here (in English).


eloyesp Points 1062

The main problem is that other users may perform work on the history original. Since the people who already have the original story in general will continue to work on it, when you try to mix the changes are different versions of the commits, and the situation is confusing.

For example, given a repo with three commits (A, B, C), while John works in a commit D, someone changes B and C (for example change the message or fixes a bug), when John tries to do a push commit D to find that they can't because it is non-fast-forward (or is it that there are things in origin that are not locally and would be lost).

Graphically the situation is the following:

A - B - C - D (master)
  \ B'- C'    (origin/master)

Then, it often happens that this build merges unnecessary, as what usually happens is that by using a pull and a push to become the commits B and C are original to the story.

A - B - C - D - M   (master, origin/master)
  \ B'- C'- - /

That is why it is important, that if it is necessary to change history in git, communicate this to all employees so that they can prepare.

To prepare, a simple way that works in many cases is to use git pull --rebase in these cases, adapting our commit to the new story:

A - B'- C'- D'(master)

More complex cases are resolved using git rebase and git reset.

I always read and say that it is dangerous to rewrite history published in git.

Then it is not dangerous, but confusing. In some cases it is even a good thing to do, but always warned the others to be ready. It is very common for these changes to be made in specific branches of the work a small group of people and the communication is more easy.

The only case dangerous, is when you mistakenly attempt is made to delete a password or some secret if this was already posted already that it is very possible that once published you have distributed copies.


Elenasys Points 67941

One of the objectives of version control is to have a history of code versions, changes made, etc. It is "dangerous" because if you write about a revision, you will simply never be able to access it, "a piece of history is lost in time" ...


HolaDevs is an online community of programmers and software lovers.
You can check other people responses or create a new question if you don't find a solution

Powered by: