Может ли git rebase полностью удалить удаленную историю? - PullRequest
10 голосов
/ 15 июля 2011

Поскольку мы рассматриваем переход от SVN к git на работе, коллега выразил обеспокоенность тем, что злонамеренный или подверженный случайным действиям разработчик может использовать git rebase для удаления удаленной истории из нашего общего репо.

Редактировать: Как указано в ответах, целые ветви также могут быть удалены из удаленного репозитория с помощью git push origin :branch-name.

Это реалистичная проблема? Если да, то какой подход мы можем предпринять, чтобы предотвратить это?

Ответы [ 3 ]

6 голосов
/ 02 августа 2011

Я склонен согласиться с вашим коллегой, что здесь есть проблема, потому что:

  • независимо от того, насколько хорошо вы доверяете своим коммиттерам, всегда есть вероятность человеческой ошибки
  • более обременительные процессы проверки (например, Геррит) не всегда уместны
  • восстановление из резервных копий может быть медленным и PITA

Рассматривали ли вы параметры конфигурации receive.denyNonFastForwards и receive.denyDeletes? AFAICT они доступны в Git 1.6 и далее.

Из Pro Git:

Если вы перебазируете коммиты, которые вы уже нажали, а затем попытаетесь нажать снова или иным образом попробуйте отправить коммит в удаленную ветку, которая не содержит фиксации, на которую в данный момент указывает удаленная ветвь, вам будет отказано Это вообще хорошая политика; но в случае ребаз, вы можете определить, что знаете, что делаете, и можете принудительно обновите удаленную ветку с флагом -f для вашей команды push.

Чтобы отключить возможность принудительного обновления удаленных веток до ссылки без ускоренной перемотки, установите receive.denyNonFastForwards

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

Как упоминает автор, это правило также может быть применено через ловушку приема (которая описана ниже в Pro Git ).

Эти методы должны защищать от случайной (или злонамеренной) потери истории в вашем общем репо.

3 голосов
/ 15 июля 2011

История может быть испорчена с помощью rebase, но обычно удаленное репо не принимает изменения, которые изменяют историю (если вы не используете git push --force), но даже более того, разработчик с правами push может полностью удалить ветку (git push origin: branch-name). Итак, простые правила:

  • Не разрешайте push-разрешения разработчикам, которым вы не доверяете.

  • Когда репо является общим, не связывайтесь с историей, избегайте использования rebase на прошлых коммитах. Вместо этого используйте merge или cherry-pick, если вам нужно добавить что-то из другой ветки, в этом случае история не будет затронута.

  • Вы можете придерживаться политики не использовать 'push -f' для общего репо, и в этом случае разработчик будет знать, что если push отклонен, то что-то идет не так (скорее всего, локальная ветвь не обновлена удаленный) и должен решить проблему локально, а не принудительно нажимать.

Относительно вашего вопроса, как предотвратить - используйте Gerrit систему ревизий, это как промежуточный шаг на пути фиксации между локальным репозиторием разработчика и мастер-репо с хорошим веб-интерфейсом для ревизии, вы можете дать разрешения на передачу в хранилище ревизий кому угодно, но изменения будут объединены с вашей основной веткой после проверки и одобрения (что требует некоторых разрешений, которые вы обычно предоставляете основным разработчикам). Вы можете увидеть, как это выглядит в проекте Mahara: https://reviews.mahara.org В этом конкретном случае, только роботу-герриту разрешено нажимать на мастера (что является здесь ), и никому другому.

1 голос
/ 07 января 2013

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

...