Как можно сохранить доступность определенного состояния хранилища git?

Question

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

Есть истории о том, как из-за ветвления, слияния и перебазирования истории теряются / становятся недоступными / кошмаром, чтобы добраться и т. Д. В то же время, легкая обработка ветвления для экспериментальной разработки функций что заставляет нас задуматься о переходе с SVN на GIT.

Итак: Какие правила мы должны соблюдать, чтобы гарантировать, что мы легко и всегда сможем получить состояние кода, который был запущен для данного анализа? Использовать только основную ветку для анализов? Если да, то какие операции должны быть запрещены в основной ветке?

РЕДАКТИРОВАТЬ: два хороших предложения объясняются ниже: Пометка важных коммитов сделает анализ прозрачным и воспроизводимым (antlersoft). Это не требует никаких новых правил, кроме как оставить теги в покое. Этот рабочий процесс тегирования не требует правил для перебазирования и слияния. Предложение Тома Андерсона полезно в том смысле, что центральное хранилище, в котором должен размещаться весь код, к которому прикреплены теги (это будет соглашение / правило), могло бы предоставить другим членам доступ к этим частям кода.

Answer 1

Решение этого не должно включать ограничение того, что вы можете сделать в любой отрасли. Просто используйте git-теги и не удаляйте и не перемещайте их. Пометьте коммит, который вы используете для запуска каждого анализа, и запишите тег фиксации вместе с анализом (это очень похоже на то, что вы делаете в svn, за исключением того, что вместо номера ревизии, сгенерированного VCS, вы задаете имя тега). Тогда версия для анализа и вся его история всегда будут доступны, независимо от того, что еще вы делаете (перебазирование и т. Д.) В ветке.

Answer 2

Я знаю, что эта ветка старая, но я просто хочу прояснить одну вещь ...
Перебазировка не удаляет историю и не удаляет коммиты.Он только добавляет новые коммиты и перемещает ветку ref.
Пока на коммит ссылается что-либо (ветвь, тег или другой коммит), он будет жить вечно.
Только старые объекты, на которые нет ссылок, удаляются, если они старыедумаю, что по умолчанию это 30 дней), и вы делаете сбор мусора или подобное.

Answer 3

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

Скорее, это означает, что вы никогда не перебазируете (и т. Д.) В хранилище, из которого вы выполняете анализ.Люди могут свободно перемещаться в других хранилищах.Возможно ли для вас создать репозиторий «Золотой мастер», в который все помещают код, с политикой без ребазирования, и использовать его для проведения анализа?Затем люди могут разрабатывать код так, как им нравится локально, и переходить в этот репозиторий, когда он готов к запуску.Это довольно нормальный рабочий процесс для команд, использующих DVCS.

Если людям нужно запускать анализ (как бы для публикации) из своих локальных репозиториев, то все сложнее.Я бы посоветовал всем иметь два хранилища локально: одно для разработки и одно для анализа.Перебазирование разрешено в репозитории разработки, но код должен быть передан в репозиторий анализа для использования (а затем в остальную часть команды).Это немного слабее, потому что это единственное соглашение, которое запрещает людям перебазировать в хранилище анализа, тогда как с центральным хранилищем, которое никто не использует напрямую, перебазировка просто не то, что произойдет.