Как убедиться, что мой код git repo безопасен?
Если бы наша организация переключилась с VCS на центральном сервере, подобном Subversion, на распределенную VCS, такую как git, как я могу убедиться, что весь мой код защищен от аппаратного сбоя?
С VCS центрального сервера мне просто нужно делать резервную копию репозитория каждый день. Если бы мы использовали DVCS, то на всех машинах разработчика было бы множество ветвей кода, и если бы это оборудование могло выйти из строя (или разработчик потерял свой ноутбук или его украли), то у нас не было бы никаких резервных копий,
Обратите внимание, что я не считаю хорошим вариантом "заставить разработчиков отправлять ветки на сервер" - это утомительно, и разработчики в конечном итоге этого не сделают.
Есть ли общий способ обойти эту проблему?
Некоторые уточнения:
В случае VCS с центральным сервером все должно быть на центральном сервере, кроме самых последних изменений разработчика. Так, например, если разработчик решает в ветке внести исправление, эта ветка находится на центральном сервере и сразу же доступна для резервного копирования.
Если мы используем DVCS, тогда разработчик может создать локальную ветвь (и фактически много локальных ветвей). Ни одна из этих веток не находится на центральном сервере и не доступна для резервного копирования до тех пор, пока разработчик не подумает: "О да, я должен перенести это на центральный сервер".
Таким образом, я вижу разницу (поправьте меня, если я ошибаюсь!): Наполовину реализованные функции и исправления, вероятно, не будут доступны для резервного копирования на центральном сервере, если мы используем DVCS, но с нормальной VCS. Как мне сохранить этот код в безопасности?
7 ответов
Я думаю, вы обнаружите, что на практике разработчики предпочтут использовать центральный репозиторий, а не перемещаться между локальными репозиториями друг друга. После того, как вы клонировали центральное хранилище, работая с любыми ветвями отслеживания, выборка и отправка становятся тривиальными командами. Добавление полдюжины пультов дистанционного управления во все локальные репозитории ваших коллег - это боль, и эти репозитории могут быть не всегда доступны (выключены, на ноутбуке, взятом домой и т. Д.).
В какой-то момент, если вы все работаете над одним проектом, вся работа должна быть интегрирована. Это означает, что вам нужна ветка интеграции, где все изменения объединяются. Это, естественно, должно быть где-то доступно для всех разработчиков, это не относится, например, к ноутбуку ведущего разработчика.
После того, как вы настроили центральное хранилище, вы можете использовать рабочий процесс в стиле cvs/svn для регистрации и обновления. cvs update становится 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/*
Это одна команда, которую можно использовать в любой момент (например, в конце дня), чтобы обеспечить безопасное резервное копирование всех его локальных изменений.
Это помогает при всевозможных бедствиях. Машина Джо взрывается, и он может использовать другую машину и получать сохраненные коммиты и продолжать с того места, где он остановился. Джо болен? Фред может получить ветки Джо, чтобы получить исправление "должно быть", которое он сделал вчера, но у него не было возможности протестировать против хозяина.
Вернемся к исходному вопросу. Должна ли быть разница между d VCS и централизованным VCS? Вы говорите, что наполовину реализованные функции и исправления не окажутся в центральном репозитории в случае d VCS, но я бы сказал, что не должно быть никакой разницы.
Я видел много случаев, когда наполовину реализованная функция остается на одном рабочем месте разработчиков при использовании централизованного VCS. Он либо принимает политику, позволяющую возвращать половину написанных функций в основной поток, либо необходимо принять решение о создании центральной ветви.
В d VCS может случиться то же самое, но должно быть принято то же самое решение. Если есть важная, но незавершенная работа, ее необходимо сохранить централизованно. Преимущество git состоит в том, что создание этой центральной ветви является почти тривиальным.
Я считаю ошибкой то, что использование распределенной VCS обязательно означает, что вы должны использовать ее полностью распределенным образом. Полностью допустимо создать общий репозиторий git и сообщить всем, что репозиторий является официальным. Для нормального рабочего процесса разработчики извлекают изменения из общего репозитория и обновляют свои собственные репозитории. Только в случае двух разработчиков, активно сотрудничающих над определенной функцией, им может потребоваться вытащить изменения непосредственно друг от друга.
Поскольку над проектом работают несколько разработчиков, было бы очень утомительно помнить о том, чтобы получать изменения от всех остальных. Что бы вы сделали, если бы у вас не было центрального хранилища?
На работе у нас есть решение для резервного копирования, которое ежедневно создает резервные копии всех рабочих каталогов и еженедельно записывает все на DVD. Таким образом, хотя у нас есть центральное хранилище, каждый отдельный резервный копируется тоже.
Нередко в качестве авторитета в DVCS используется "центральный" сервер, который также предоставляет вам место для резервного копирования.
Я нахожу этот вопрос немного странным. Предполагая, что вы используете нераспределенную систему контроля версий, такую как CVS, у вас будет репозиторий на центральном сервере, и работа будет продолжаться на серверах разработчиков. Как вы делаете резервную копию хранилища? Как вы поддерживаете работу разработчиков? Ответ на эти вопросы - именно то, что вы должны сделать, чтобы справиться со своим вопросом.
Используя распределенный контроль версий, репозитории на серверах разработчиков просто находятся в стадии разработки. Вы хотите поддержать это? Тогда поддержите это! Это так просто.
У нас есть автоматизированная система резервного копирования, которая собирает любые каталоги с наших машин, которые мы указываем, поэтому я добавляю к этому последнему любые репозитории и рабочие копии на моей машине, включая git и CVS.
Кстати, если вы используете распределенный контроль версий в компании, выпускающей продукт, то у вас будет центральное хранилище. Это тот, от которого вы освобождаетесь. Это может быть не на специальном сервере; это может быть на жестком диске какого-то разработчика. Но хранилище, из которого вы выпускаете, является центральным хранилищем. (Полагаю, если вы еще не выпустили, у вас его еще может не быть.) Я чувствую, что у всех проектов есть одно или несколько центральных хранилищ. (И действительно, если у них более одного, это два проекта и один - форк.) Это также относится и к open source.
Даже если у вас не было центрального хранилища, решение остается тем же: резервное копирование на машинах разработчика. Вы должны были делать это в любом случае. Тот факт, что работа находится в распределенных репозиториях вместо рабочих копий CVS или прямых неверсионных каталогов, не имеет значения.
Вы можете сделать так, чтобы домашние каталоги разработчика монтировали удаленные устройства по локальной сети. Тогда вам остается только позаботиться о том, чтобы сделать сетевое хранилище безопасным. Или, может быть, вы можете использовать что-то вроде DropBox, чтобы беспрепятственно скопировать локальное хранилище в другом месте.
Мы используем rsync для резервного копирования отдельных каталогов разработчиков.git в каталог на сервере. Это настройка с использованием сценариев-оберток вокруг git clone, а также хуков post-commit и т. Д.
Поскольку это делается в хешах post-*, разработчикам не нужно забывать делать это вручную. И поскольку мы используем rsync с таймаутом, если сервер отключается или пользователь работает удаленно, они все равно могут работать.
Все разработчики в вашей команде также могут иметь свои собственные ветви на сервере (могут быть за тикет или только за разработчика и т. Д.). Таким образом, они не нарушают сборку в основной ветке, но все равно отправляют свою работу на резервный сервер.
Мой собственный инструмент git_remote_branch может пригодиться для такого типа рабочего процесса (обратите внимание, что он требует Ruby). Это помогает манипулировать удаленными ветвями.
В качестве дополнительного примечания, говоря о безопасности репо, на вашем сервере вы можете настроить хук post-commit, который выполняет простой клон git или push git на другую машину... Вы получаете актуальную резервную копию после каждого коммита!