Использование перехватчиков (hooks) в Git для блокирования правки опубликованных коммитов

[@cypok]

Мне казалось, что данную проблему вполне решает сервер, который отклонит non fast forward push. Чем этого не хватает?

[@Humbucker]

Да, и в таком случае придётся править историю коммитов в своей локальной ветке, чтобы разрешить проблему. Лично мне хотелось бы до этого не доводить.

[@janatem]

Вообще-то своя локальная копия — пожалуй, единственное место, где править историю этически допустимо. Более того, править локальную историю полезно, чтобы в публичный репозиторий был в разных смыслах лучше.

[@Humbucker]

Править локальную историю придётся из-за досадного изменения по невнимательности уже опубликованного коммита. Решение, которое я предложил направлено на пресечение подобного ошибочного коммита по невнимательности, ещё на этапе его совершения, а не спустя уже какое-то количество времени (и коммитов).

[@janatem]

Ок, я осознал, что невнимательно прочитал статью. Проблема действительно есть, хотя я с ней ни разу не сталкивался, поскольку завел привычку смотреть, где кончается опубликованная история, и начинается моя локальная, прежде чем вносить деструктивные изменения (вроде commit --amend или rebase -i).

[@hell0w0rd]

On branch master

Просто не стоит работать в мастере. Вы можете сколько угодно изменять вашу ветку, до того момента, пока она не вошла в мастер.

А поможет вам в этом prompt в терминале

[@mayorovp]

Как минимум, с мастером может понадобиться по-работать хотя бы один раз — при слиянии ветки обратно в этот самый мастер. Кстати, чаще всего лично мне хочется сделать --amend именно после слияния…

Кроме того, мастер не является единственной веткой, которая пушится на сервер. Даже ветка my-own-temp-branch-for-this-bugfix может быть запушена на сервер — ежели баг оказался не таким простым и затронул модули, которые писал другой разработчик. Или просто пришло начальство и сказало передать текущие дела кому-нибудь другому и срочно заняться чем-то еще.

[@hell0w0rd]

Слияние — ок, но вы же сливаете, при этом создается коммит, историю это только продвигает, а не перезаписывает.
Ветки, которые пулятся на сервер должны пулиться вне зависимости от того, изменилась ли история ветки, или нет.
Не понимаю зачем менять историю, когда вы кому-то передаете свои дела.

[@Humbucker]

Думаю, что многое зависит от постановки рабочего процесса с Git, который заведён в компании (в отделе/в сообществе). Где-то сотрудники заводят свои локальные ветки, которые сами и мержат в итоге; где-то заводят свои удалённые ветки и пушат туда (доступ к master-ветке ограничен), периодически обновляя их при помощи rebase из master-ветки (чтобы не создавать merge-коммиты).
Данный хук может пригодиться в похожем случае, когда программисты работают со своими удалёнными ветками, в которые некоторые (не особо опытные) сотрудники иногда выполняют push -f =)

[@hell0w0rd]

ну вот я неопытный Вася, допустим работаю я в своей bugfix-foo-bar, делаю туда push -f. Зачем кому-то тащить мой коммит и что-то с ним делать, пока я работаю над какой-то функциональностью? Если это требуется — значит разработчику дали слишком большую задачку, а разработчик не разбил ее на более мелкие, которые можно было бы по очереди пулл-реквестить в мастер.

[@kromxr]

Ну например фича это взаимодейсвие фронтэнд/бэкэнд
Почему бы двоим людям не работать в общей ветке на одной фичей

[@hell0w0rd]

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

[@Mezomish]

Если, скажем, фронт-ендщику нужны изменения бэк-эндщика для продолжения работы над фичей, то ему вовсе не обязательно работать в той же ветке, что и бэк-эндщик. Он может смерджить ветку бэк-эндщика в свою и работать дальше. А бэк-эндщик продолжит работать в своей ветке.