Как убедиться, что мой код git repo безопасен? - PullRequest
7 голосов
/ 21 сентября 2008

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

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

Обратите внимание, что я не считаю хорошим вариантом "заставить разработчиков отправлять ветки на сервер" - это утомительно , и разработчики в конечном итоге этого не сделают.

Есть ли общий способ решения этой проблемы?

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

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

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

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

Ответы [ 7 ]

12 голосов
/ 21 сентября 2008

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

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

После настройки центрального хранилища вы можете использовать рабочий процесс в стиле 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/*

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

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

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

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

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

4 голосов
/ 21 сентября 2008

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

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

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

1 голос
/ 30 марта 2009

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

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

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

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

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

1 голос
/ 21 сентября 2008

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

0 голосов
/ 24 сентября 2008

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

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

0 голосов
/ 21 сентября 2008

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

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

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

0 голосов
/ 21 сентября 2008

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

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