Comments 14
Мне казалось, что данную проблему вполне решает сервер, который отклонит non fast forward push. Чем этого не хватает?
Да, и в таком случае придётся править историю коммитов в своей локальной ветке, чтобы разрешить проблему. Лично мне хотелось бы до этого не доводить.
Вообще-то своя локальная копия — пожалуй, единственное место, где править историю этически допустимо. Более того, править локальную историю полезно, чтобы в публичный репозиторий был в разных смыслах лучше.
Править локальную историю придётся из-за досадного изменения по невнимательности уже опубликованного коммита. Решение, которое я предложил направлено на пресечение подобного ошибочного коммита по невнимательности, ещё на этапе его совершения, а не спустя уже какое-то количество времени (и коммитов).
On branch master
Просто не стоит работать в мастере. Вы можете сколько угодно изменять вашу ветку, до того момента, пока она не вошла в мастер.
А поможет вам в этом prompt в терминале
Как минимум, с мастером может понадобиться по-работать хотя бы один раз — при слиянии ветки обратно в этот самый мастер. Кстати, чаще всего лично мне хочется сделать --amend именно после слияния…
Кроме того, мастер не является единственной веткой, которая пушится на сервер. Даже ветка my-own-temp-branch-for-this-bugfix может быть запушена на сервер — ежели баг оказался не таким простым и затронул модули, которые писал другой разработчик. Или просто пришло начальство и сказало передать текущие дела кому-нибудь другому и срочно заняться чем-то еще.
Кроме того, мастер не является единственной веткой, которая пушится на сервер. Даже ветка my-own-temp-branch-for-this-bugfix может быть запушена на сервер — ежели баг оказался не таким простым и затронул модули, которые писал другой разработчик. Или просто пришло начальство и сказало передать текущие дела кому-нибудь другому и срочно заняться чем-то еще.
Думаю, что многое зависит от постановки рабочего процесса с Git, который заведён в компании (в отделе/в сообществе). Где-то сотрудники заводят свои локальные ветки, которые сами и мержат в итоге; где-то заводят свои удалённые ветки и пушат туда (доступ к master-ветке ограничен), периодически обновляя их при помощи rebase из master-ветки (чтобы не создавать merge-коммиты).
Данный хук может пригодиться в похожем случае, когда программисты работают со своими удалёнными ветками, в которые некоторые (не особо опытные) сотрудники иногда выполняют push -f =)
Данный хук может пригодиться в похожем случае, когда программисты работают со своими удалёнными ветками, в которые некоторые (не особо опытные) сотрудники иногда выполняют push -f =)
ну вот я неопытный Вася, допустим работаю я в своей bugfix-foo-bar, делаю туда push -f. Зачем кому-то тащить мой коммит и что-то с ним делать, пока я работаю над какой-то функциональностью? Если это требуется — значит разработчику дали слишком большую задачку, а разработчик не разбил ее на более мелкие, которые можно было бы по очереди пулл-реквестить в мастер.
Ну например фича это взаимодейсвие фронтэнд/бэкэнд
Почему бы двоим людям не работать в общей ветке на одной фичей
Почему бы двоим людям не работать в общей ветке на одной фичей
Потому что это идиотизм. Git позволяет легко и непринужденно разделить разработку, ветвиться сколько угодно, делать это быстро и без проблем.
Если, скажем, фронт-ендщику нужны изменения бэк-эндщика для продолжения работы над фичей, то ему вовсе не обязательно работать в той же ветке, что и бэк-эндщик. Он может смерджить ветку бэк-эндщика в свою и работать дальше. А бэк-эндщик продолжит работать в своей ветке.
Sign up to leave a comment.
Использование перехватчиков (hooks) в Git для блокирования правки опубликованных коммитов