Нужно ли запрещать git push origin master -f на уровне репозитория?

Question

[MagnetonBora]

В моей команде возникла жестка дискуссия о том нужно ли запрещать делать push'ы в мастера с ключем force на уровне репозитория.

Наш производственный процесс выглядит следующим образом. Когда девелопер берет себе очередной таск, он создает себе отдельную ветку, которая отбита от актуального мастера. Как только таск закончен у нас необходимо создать merge request, который должен просмотреть кто-то из команды. Если все в порядке, то ветка сливается с мастером и удаляется. Мы используем гитлаб, который позволяет слить ветку с мастером по одному клику.

Однажды в мастера попала ветка, которая там быть еще не должна. Так вышло, что висел merge request к которому были замечания, но человек, который просматривал код кликнул не в том месте, где нужно было и слил незаконченную ветку с мастером. Сразу же был сделан реверт, который по сути представляет собой коммит, уничтожающий предыдущий merge. Этот самый реверт спровоцировал пару проблем. В итоге было сделано следующее -- этот самый случайный merge был "вырезан", после чего последовала страшная команда git push origin master --force-with-lease.

На мой взгляд данное решение было оправдано потому, что:

1. В истории версий не будет мусора. Действительно -- только что вошел merge по неосторожности, сверху на него упал реверс-коммит. Но через час, как только будут заимплементированы вещи, которые появились после ревью, будет сделан еще один merge с той лишь разницей, что он будет на несколько коммитов больше. В итоге имеем кучу ненужного в истории кода.
   
2. В нашем конкретном случае если не вырезать неудачный merge, то в конечном итоге после имплементации замечаний пришлось бы делать rebase на актуального мастера (в котором уже был реверс-коммит) и это создало бы кучу конфликтов, которые пришлось бы развязывать.
   
   

На мой взгляд данное решение было более, чем оправдано, тем не менее начался холивар.

Вопросы:

1. Кто как считает -- нужно ли отключать возможность push'а с форсом?
   
2. Что у Вас делают если в мастера случайно попало что-то, чего там быть не должно?
   

Answer 1

[Сергей Протько]

1. Перезапись истории нужна, но ее нужно использовать осторожно. Пуш с форсом в мастер - исключение из правил, и в вашей ситуации это полностью оправдано.

2. В 99% случаев спасает реверт. В остальных случаях - push --force, но это крайне редко.

В целом я фанат rebase-ов, что бы история гита была линейной. Если фичабрэнч не fast forward то ребейзимся на мастер и перезаписываем историю этой ветки. Ну а далее fast-forward merge (а еще лучше - сквошить коммиты перед этим). Но тут могут быть несогласные, потому использую те варианты которые приняты в команде.

Answer 2

[guras256]

На мой взгляд разработку следует вести в ветке develop (как ни странно). Таким образом единственный способ попадания кода в master - слив текущего develop в master.
Таким образом в master всегда будет готовый, рабочий, вылизанный релиз, в то время как текущая разработка ведется в develop.

Что касается вопроса
1. запретить прямой push в master по хорошему надо, но когда возникнет форс мажор и нужно будет срочно что-то вкатить, один хрен полезете включать возможность пуша)
2. реверт делают, что тут еще делать)

Comments

[Сергей Протько]

Частенько develop ветка не нужна, нужен только стабильный мастер. Под "стабильный" я подразумеваю "все работает", то есть тесты зеленые (иначе в мастер это не попадет), и вы уверены что сделали все в соответствии с требованиями. Если не уверены - значит этому еще не место в мастере.

Правда тут маленькое допущение - разработчики адекватны, все покрыто тестами и разработчики реально знают что делать и главное проверяют то что сделали. Я видел много разработчиков которые выкатывали все на тестирование заведома зная что не доделали или просто не проверяя.

master должен быть всегда готов к деплойменту. Если для этого нужна develop ветка - окей, но она может быть и не нужна.

Answer 3

[index0h]

История коммитов на то и история, что бы отображать все изменения в хронологическом порядке.

нужно ли отключать возможность push'а с форсом?

Git push должен быть запрещен, по своей сути - это Домоклов меч, только над головами всей команды.
Несколько раз встречал форсированные пуши после не удачного ребейза. Один раз за коллегой пришлось восстанавливать 2-х недельную историю, не самое приятное занятие.

Что у Вас делают если в мастера случайно попало что-то, чего там быть не должно?

revert + комментарий в баг трекере о причине реверта.

На прошлом проекте релизы были 1 раз утром и опционально днем. Релиз проводился в полу автоматическом режиме, ветки затягивались из багтрекера, а далее намердживались на мастер. В случае конфликта - автоматический реверт. В случае поломки сборки - ручной поиск виновника и ручной реверт.
Форсированный пуш не нужен. Ребейз при этом не прижился.
Да, факапы бывали, для этого и были опциональные релизы днем, что бы автор увидев свой косяк на проде мог в тот же день его асапно исправить.

Comments

[Сергей Кузнецов]

Но у revert тоже есть свои грабли. Если вы позже попробуете повторно слить тематическую ветку в master, то обнаружите, что правки сделанные до предыдущего отменённого слияния не применились, так как revert-коммит, который сейчас в master, отменит их тоже. Перед повторным merge придётся повторно создать revert-коммит уже для того первого revert-коммита.

Либо сразу пересадить тематическую ветку на вершину master, тогда проблемы не будет

git switch feature # перейти в тематическую ветку
git rebase master # пересобрать ветку на базе актуального master 
git push --force # перезаписать тематическую ветку на сервере

Сам Линус Торвальдс написал небольшую инструкцию на эту тему.