Как убедиться, что мой код репозитория git безопасен?

Question

Если бы наша организация перешла от системы VCS с центральным сервером, такой как Subversion, к распределенной VCS, такой как git, как мне убедиться, что весь мой код защищен от сбоев оборудования?

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

Обратите внимание: я не считаю хорошим вариантом «заставлять разработчиков переносить ветки на сервер» — это скучный и разработчики в конечном итоге этого не сделают.

Есть ли общий способ обойти эту проблему?

Некоторые уточнения:

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

Если мы используем DVCS, то разработчик может создать локальную ветку (а на самом деле множество локальных веток).Ни одна из этих веток не находится на центральном сервере и не доступна для резервного копирования до тех пор, пока разработчик не подумает: «О да, мне следует отправить это на центральный сервер».

Итак, разница, которую я вижу (поправьте меня, если я ошибаюсь!):Наполовину реализованные функции и исправления ошибок, вероятно, будут недоступны для резервного копирования на центральном сервере, если мы используем DVCS, но с обычной VCS.Как мне сохранить этот код в безопасности?

Answer 1

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

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

После того как вы настроили центральный репозиторий, вы можете использовать рабочий процесс в стиле cvs/svn для регистрации и обновления.Обновление cvs становится git fetch и rebase, если у вас есть локальные изменения, или просто git pull, если у вас их нет.cvs commit становится git commit и git push.

При такой настройке вы находитесь в аналогичном положении с вашей полностью централизованной системой VCS.Как только разработчики отправят свои изменения (git push), которые им необходимо сделать, чтобы их увидела остальная часть команды, они окажутся на центральном сервере и будут скопированы.

В обоих случаях дисциплина требует предотвращения хранения разработчиками долговременных изменений в центральном репозитории.Большинство из нас, вероятно, сталкивались с ситуацией, когда один разработчик работает над функцией «x», которая требует фундаментального изменения в некотором базовом коде.Это изменение приведет к тому, что всем остальным придется полностью перестраиваться, но функция еще не готова для основного потока, поэтому он просто оставляет ее проверенной до подходящего момента времени.

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

С другой стороны, использование локальных коммитов можно использовать как преимущество.Переместить все локальные коммиты в безопасное место в центральном репозитории не должно быть очень сложно.Локальные ветки могут храниться в пространстве имен тегов, специфичном для разработчика.

Например, для Джо Блоггса в его локальном репозитории можно создать псевдоним, чтобы выполнять что-то вроде следующего в ответ (например) git mybackup.

git push origin +refs/heads/*:refs/jbloggs/*

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

Это помогает при любых бедствиях.Машина Джо выходит из строя, и он может использовать другую машину, получить сохраненные коммиты и продолжить с того места, где он остановился.Джо болен?Фред может получить ветки Джо, чтобы получить необходимое исправление, которое он сделал вчера, но у него не было возможности проверить его на мастере.

Возвращаясь к исходному вопросу.Должна ли быть разница между dVCS и централизованной VCS?Вы говорите, что в случае с dVCS наполовину реализованные функции и исправления ошибок не попадут в центральный репозиторий, но я бы сказал, что разницы быть не должно.

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

В dVCS может произойти то же самое, но должно быть принято то же решение.Если есть важная, но незавершенная работа, ее необходимо сохранить централизованно.Преимущество git в том, что создание этой центральной ветки практически тривиально.

Answer 2

Я думаю, что это заблуждение, что использование распределенной системы контроля версий обязательно означает, что вы должен используйте его полностью распределенным образом.Совершенно справедливо создать общий репозиторий git и сообщить всем, что этот репозиторий является официальным.В обычном рабочем процессе разработки разработчики извлекают изменения из общего репозитория и обновляют свои собственные репозитории.Только в случае, если два разработчика активно сотрудничают над определенной функцией, им может потребоваться получить изменения непосредственно друг от друга.

Если над проектом работает несколько разработчиков, было бы очень утомительно не забывать получать изменения от всех остальных.Что бы ты сделал, если бы ты не сделал есть центральный репозиторий?

На работе у нас есть решение для резервного копирования, которое ежедневно создает резервные копии всех рабочих каталогов и еженедельно записывает всю информацию на DVD.Итак, хотя у нас есть центральный репозиторий, каждый отдельный репозиторий тоже резервируется.

Answer 3

Нередко используется «центральный» сервер в качестве центра управления DVCS, который также предоставляет вам место для резервного копирования.

Answer 4

Мне кажется этот вопрос немного странным.Предполагая, что вы используете нераспределенную систему контроля версий, такую ​​как CVS, у вас будет репозиторий на центральном сервере и работа будет вестись на серверах разработчиков.Как сделать резервную копию репозитория?Как вы создаете резервную копию текущей работы разработчиков?Ответ на эти вопросы — это именно то, что вам нужно сделать, чтобы справиться со своим вопросом.

Используя распределенный контроль версий, репозитории на серверах разработчиков находятся в стадии разработки.Хотите сделать резервную копию?Тогда сделайте резервную копию!Это так просто.

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

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

Даже если у вас нет центрального репозитория, решение то же:резервное копирование работы на машинах разработчика.Ты все равно должен был это сделать.Тот факт, что незавершенная работа находится в распределенных репозиториях, а не в рабочих копиях CVS или в прямых неверсионных каталогах, не имеет значения.

Answer 5

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

Answer 6

Все разработчики в вашей команде также могут иметь свои собственные ветки на сервере (может быть для каждого тикета или только для каждого разработчика и т. д.).Таким образом, они не нарушают сборку в основной ветке, но все равно могут перенести свою незавершенную работу на сервер, для которого создается резервная копия.

Мой собственный git_remote_branch инструмент может пригодиться для такого рода рабочего процесса (обратите внимание, что для него требуется Ruby).Это помогает манипулировать удаленными ветками.

В качестве примечания, говоря о безопасности репо, на своем сервере вы можете настроить перехватчик после фиксации, который выполняет простое клонирование git или отправку git на другую машину...Вы получаете актуальную резервную копию после каждого коммита!

Answer 7

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

Поскольку это делается в хуках post-*, разработчикам не нужно помнить, что нужно делать это вручную.А поскольку мы используем rsync с таймаутом, если сервер выйдет из строя или пользователь работает удаленно, они все равно смогут работать.