D
D
Demigodd2019-04-22 22:05:21
git
Demigodd, 2019-04-22 22:05:21

Why is force push dangerous?

Why is git push -f so dangerous?
Some say never force push if you are working in a team. Although why not, no one says.
So I thought, such a situation arose, I did git commit --ammed to change the author of the commit and I had to do git push --force, since simple push did not work.
Is it safe to merge such a branch with the main one?
That is, a test branch was created from mastera in this branch, the last commit was changed with the help of ammed and push -f was made.

Answer the question

In order to leave comments, you need to log in

1 answer(s)
I
Igor Deyashkin, 2019-05-16
@Demigodd

BD_l3ftoverZ! answered in principle correctly - you can overwrite other people's changes, but this is not the only danger.
The problem is also that someone received the old versions of the commits. And if changes were made to the contents of the commits during force pushing (for example, they were swapped and as a result the "amount of changes" remained the same, but the order changed), conflicts will arise during the pull when trying to rebase (surge) old versions of commits to new ones. And here it all depends on the experience and attentiveness of the developer who encountered this. If he is experienced enough, he will understand what is going on and correctly resolve the situation. And if not, he will start resolving conflicts, mess up when resolving them, and when pushing, he will not check that he is pushing not only his commits that he was going to, but also the old versions of the commits rebasened for new versions, and this will be ... unpleasant.
Вот реальная ситуация, которая произошла у меня на работе. К сожалению, за давностью лет конкретные детали я помню смутно, но в целом все было примерно так. В какой-то момент появилась ошибка. Причем код, в котором она была был очень "говнокод", человек его написавший уже уволился и понять в каком месте этот говнокод написан неправильно, не понимая "логики" автора было очень сложно. С помощью git-bisect я нашел проблемный коммит и стал дальше раскручивать клубок. В итоге выяснилось, что было нарушено по крайней мере три важных правила работы с гитом (описанные во внутренней вики и обязательные к исполнению) и если бы хотя бы одно из них нарушено не было - все было бы ок.
1. Я сделал пуш в мастер и оперативно осознав, что что-то там не так быстренько поправил и залил форсед пушем исправления. Это было важно сделать именно так. Я решил, что во-первых, маловероятно, что кто-то успел сделать пулл, а во-вторых, даже если он и сделал - когда у него возникнут конфликты он либо сам все поймет, либо обратится ко мне. Первое нарушение. Мне следовало уведомить всех разработчиков об этом и объяснить как нужно правильно действовать.
2. Естественно, один разработчик успел сделать пулл и отребэйзил на старый мастер ветку этого уволившегося и стал доделывать таск. Когда спустя продолжительное время он стал ребэйзить эту ветку на мастер у него полезли конфликты. Он не понял из-за чего эти конфликты возникли. Но храбро все их решил. Етественно, не правльно, уже хотя-бы потому, что он вообще не должен был их решать. Нарушение второго правила - "решай конфликты только тогда, когда ты понимаешь почему они возникли". Обратись он ко мне - все было бы в порядке.
3. Когда он стал пушить свои изменения он нарушил третье правило: "Всегда проверяй список коммитов, которые ты пушишь". Он не заметил, что кроме "своих" коммитов, он так же пушит чужие, старые версии коммитов мастера, которые он отребэйзил на новые. Он должен был это заметить и забить тревогу - что такое, откуда эти коммиты, я их не делал. Опять же, обратись он ко мне - я бы на месте бы разобрался в чем дело, и исправил ситуацию.
Так что не надейтесь на авось (как я в данном случае).
In general, it turns out like this - if you understand that both problems - 1) overwriting other people's changes and 2) the fact that someone has old versions of commits are not relevant - feel free to force push. For example:

  • This is a task branch in which only you work and, according to the workflow, no one should take any commits from it without your knowledge.
  • You know exactly who has access to the branch and you are sure that these people will handle the situation correctly. You warned them and they know what to do in such situations.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question