Какая часть вашего проекта должна быть в контроле исходного кода?

54

Один из разработчиков начал работу над новым проектом Drupal, и системный администратор предложил, чтобы они только помещали подкаталог sites / default в систему управления версиями, потому что это «сделает обновления легко создаваемыми по сценарию». Оставляя в стороне это сомнительное утверждение, возникает еще один вопрос - какие файлы должны находиться под контролем исходного кода? И есть ли ситуация, когда какой-то большой кусок файлов должен быть исключен?

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

Тем не менее, я хотел бы получить другие мнения по этому поводу. Есть ли какие-то аргументы для того, чтобы не держать все под контролем?

muffinista
источник
2
Все, что генерирует окончательное представление (включая документацию), должно находиться под контролем версий при условии, что хранилище возможно. Похоже, что генерация кода здесь сомнительно связана с управлением версиями, в которой я бы проверил утверждения о простом написании сценариев (читай: создание) обновлений из того, что вы версировали.
МрГомез

Ответы:

71

Я бы сказал, что минимум, который должен содержать исходный контроль, - это все файлы, необходимые для воссоздания работающей версии проекта. Это даже включает файлы DDL для установки и изменения любой схемы базы данных, и в правильной последовательности тоже. Минус, конечно, инструменты, необходимые для сборки и выполнения проекта, а также все, что может быть автоматически получено / сгенерировано из других файлов в системе контроля версий (таких как файлы JavaDoc, созданные из файлов Java в системе управления версиями).

FrustratedWithFormsDesigner
источник
1
@EdWoodcock: Вы правы, получение правильного порядка может быть реальной болью, но иногда вы хотите воссоздать определенное состояние базы данных или при необходимости применить определенные изменения при тестировании, а не отбрасывать / воссоздавать все это. Я считаю, что это зависит от проекта.
FrustratedWithFormsDesigner
1
Точка взята, есть уровень или прагматизм, необходимый для этого.
Эд Джеймс
3
@JayBazuzi: рабочая станция направляющие установок (в системе управления версиями) следует выделить необходимые средства и зависимость, а также как установить и где получить средства из. Поддержание полезного инструментария является важным, но не цель управления версиями. Я полагаю, что если бы вы ДЕЙСТВИТЕЛЬНО хотели, вы можете добавить установочный файл / .msi и некоторые файлы инструкций, но это может оказаться невозможным на некоторых рабочих местах. Вы действительно хотите ли проверить в VisualStudio Pro 2010 или IBM RAD, XMLSpy и т.д., в вашей исходной системе управления? Многие рабочие места контролировали развертывание этих инструментов.
FrustratedWithFormsDesigner
2
@artistoex: это раскалывает волосы. Обычно предполагается, что сборочная коробка имеет те же библиотеки, что и блоки разработки. Если они различаются, значит, что-то не так с ИТ-менеджером. Все, что вам (в идеале) понадобится, это просто исходный код. В некоторых проектах это не применимо, но для большинства так и должно быть.
Майк С
1
@Mike, я имел в виду это. Я думаю, что это был Кент Бек в книге о XP, которая действительно предложила это. Неплохая идея. Вы почти на 100% уверены, что сможете восстановить все факторы сборки. И не забывайте, что среда, скорее всего, меняется в ходе проекта.
artistoex
29

Лучше всего поместить все под солнцем в систему контроля версий.

  • Код

  • Библиотеки

  • Ресурсы

  • Сценарии сборки / развертывания

  • Сценарии создания и обновления базы данных

  • Некоторая документация

  • Конфигурационные файлы для конкретной среды

Единственное, что не следует помещать в систему контроля версий, - это артефакты сборки для вашего проекта.

maple_shaft
источник
5
Убедитесь, что «определенная документация» не зависит от конкретного инструмента. Я сталкивался с несколькими проектами, которые использовали что-то вроде фрейма SunOS для создания документации, они отметили все файлы «.mif», но не полученные .ps или .pdf файлы. Теперь, когда SunOS и Frame отошли на свалку истории, многие дизайнерские документы существуют только в виде заветных бумажных копий.
Брюс Эдигер
2
@BruceEdiger В этом случае я бы лично хотел получить информацию как о выходе, так и об инструменте. Если инструмент исчезнет, ​​у вас по крайней мере будет статическая электронная копия :)
maple_shaft
Одно из преимуществ крупной компании, занимающейся процессами, заключается в том, что исходный код идет в vcs, сгенерированный материал должен идти в систему управления конфигурацией, поэтому даже если ваш инструмент не работает, вы все равно будете контролировать результаты
jk.
Как насчет конкретной версии компилятора (ов), которую вы используете? Черт, почему не вся ОС?
Внуаз
18

Я бы сказал, что;

  • любой файл, необходимый для сборки, попадает в систему контроля версий
  • любой файл (который может быть), сгенерированный сборкой, не

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

Люк Грэм
источник
15

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

HLGEM
источник
15

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

Некоторые из ответов здесь говорят «не помещайте двоичные файлы в систему контроля версий». Это неверно. Когда вы работаете над продуктом с большим количеством стороннего кода и множеством двоичных библиотек от поставщиков, вы включаете двоичные библиотеки . Потому что, если вы этого не сделаете, то в какой-то момент вы собираетесь выполнить обновление, и у вас возникнут проблемы: сборка будет прервана, потому что сборочная машина не имеет последней версии; кто-то дает новому парню старые компакт-диски для установки; в вики проекта есть устаревшие инструкции относительно того, какую версию устанавливать; и т.д. Хуже того, если вам нужно тесно сотрудничать с поставщиком для решения конкретной проблемы, и они отправляют вам пять наборов библиотек в неделю, вы должныбыть в состоянии отследить, какой набор двоичных файлов показал, какое поведение. Система контроля версий - это инструмент, который решает именно эту проблему.

Некоторые из ответов здесь говорят «не переводите инструментальную цепочку в систему контроля версий». Я не скажу, что это неправильно, но лучше всего поместить инструментальную цепочку в систему контроля версий, если у вас нет для этого надежной системы управления конфигурацией (CM) . Опять же, рассмотрите вопрос обновления, как указано выше. Хуже того, я работал над проектом, в котором было четыре отдельных варианта набора инструментов, которые я получил при найме на работу - все они в активном использовании ! Одним из первых, что я сделал (после того, как мне удалось заставить сборку работать), была поставлена ​​цепочка инструментов под контроль исходного кода. (Идея надежной системы CM была вне надежды.)

А что происходит, когда разные проекты требуют разных наборов инструментов? Пример: через пару лет один из проектов получил обновление от поставщика, и все Makefile сломались. Оказывается, они полагались на более новую версию GNU make. Так что мы все обновились. Упс, все файлы Makefile другого проекта сломались. Урок: зафиксируйте обе версии GNU make и запустите версию, которая поставляется вместе с вашим проектом.

Или, если вы работаете в месте, где все остальное совершенно неконтролируемо, у вас возникают разговоры типа: «Эй, новый парень начинается сегодня, где CD для компилятора?» «Не знаю, не видел их с тех пор, как Джек ушел, он был хранителем компакт-дисков». "Э-э, разве не до того, как мы поднялись со 2-го этажа?" «Может быть, они в коробке или что-то в этом роде». И поскольку инструментам уже три года, нет надежды получить этот старый CD у продавца.

Все ваши сценарии сборки принадлежат системе контроля версий. Все! Все вплоть до переменных среды. Ваша сборочная машина должна иметь возможность запускать сборку любого из ваших проектов, выполняя один скрипт в корневом каталоге проекта. ( ./buildявляется разумным стандартом; ./configure; makeпочти так же хорош.) Скрипт должен настроить среду как требуется, а затем запустить любой инструмент, который собирает продукт (make, ant и т. д.).

Если вы думаете, что это слишком много работы, это не так. Это на самом деле экономит массу работы. Вы фиксируете файлы один раз в начале времени, а затем при каждом обновлении. Ни один одинокий волк не может обновить свою машину и зафиксировать кучу исходного кода, который зависит от последней версии какого-либо инструмента, нарушая сборку для всех остальных. Когда вы нанимаете новых разработчиков, вы можете сказать им, чтобы проверить проект и запустить ./build. Когда версия 1.8 имеет много настроек производительности, и вы настраиваете код, флаги компилятора и переменные среды, вы хотите убедиться, что новые флаги компилятора не будут случайно применены к сборкам патчей версии 1.7, потому что им действительно нужен код изменения, которые сопровождают их, или вы видите некоторые волосатые расы.

Лучше всего , это когда-нибудь спасет вашу задницу: представьте, что вы отправите версию 3.0.2 вашего продукта в понедельник. Ура, празднуем. Во вторник утром VIP-клиент звонит на горячую линию поддержки, жалуясь на эту сверхкритическую, срочную ошибку в версии 2.2.6, которую вы отправили 18 месяцев назад. И вам по-прежнему приходится поддерживать его по контракту, и они отказываются обновляться, пока вы не сможете точно подтвердить, что ошибка исправлена ​​в новом коде, и они достаточно велики, чтобы заставить вас танцевать. Есть две параллельные вселенные:

  • Во вселенной, где у вас нет библиотек, наборов инструментов и сценариев сборки в управлении исходным кодом, и у вас нет надежной системы CM ... Вы можете проверить правильную версию кода, но она дает Вы все виды ошибок, когда вы пытаетесь построить. Посмотрим, обновили ли мы инструменты в мае? Нет, это были библиотеки. Хорошо, вернитесь к старым библиотекам - подождите, были ли два обновления? Ах да, это выглядит немного лучше. Но теперь эта странная ошибка компоновщика выглядит знакомой. О, это потому, что старые библиотеки не работали с новым набором инструментов, поэтому нам пришлось обновляться, верно? (Я избавлю вас от агонии остальных усилий. Это займет две недели, и никто не доволен в конце этого, ни вы, ни руководство, ни клиент.)

  • Во вселенной, где все находится под контролем исходного кода, вы проверяете тег 2.2.6, готовите отладочную сборку примерно через час, тратите день или два на воссоздание «VIP ошибки», отследите причину, устраните ее текущий выпуск, и убедить клиента обновить. Напряженный, но не такой ужасный, как в другой вселенной, где ваша волосная линия на 3 см выше.

С учетом сказанного, вы можете зайти слишком далеко:

  • У вас должна быть установлена ​​стандартная ОС, у вас есть «золотая копия». Документируйте это, вероятно, в README, который находится в системе контроля версий, чтобы будущие поколения знали, что версия 2.2.6 и более ранние версии построены только на RHEL 5.3 и 2.3.0, а позднее - только на Ubuntu 11.04. Если вам легче управлять цепочкой инструментов таким образом, сделайте это, просто убедитесь, что это надежная система.
  • Проектная документация громоздка в системе контроля версий. Документы по проектам всегда опережают сам код, и нередко приходится работать с документацией для следующей версии, работая над кодом для текущей версии. Особенно, если все ваши проектные документы являются бинарными документами, которые вы не можете изменить или объединить.
  • Если у вас есть система, которая контролирует версии всего, что используется в сборке, используйте ее ! Просто убедитесь, что синхронизировать всю команду легко, чтобы все (включая сборочную машину) использовали один и тот же набор инструментов. (Я имею в виду такие системы, как pbuilder в Debian и ответственное использование python's virtualenv.)
bstpierre
источник
Не забудьте проверить любое трудно заменяемое оборудование. Одна компания потеряла сборку, потому что у них больше не было процессора (HPPA? 68040?), На котором работали инструменты сборки.
hotpaw2
1
Что означает «система CM»?
Бодо
1
В большинстве случаев я бы предпочел документировать двоичные файлы и версии, а не фиксировать сами двоичные файлы. Да, в вашем случае получить двоичные файлы было сложно, и у вас не было другого хорошего способа их спрятать. Но я чувствую , как правило , документирование всех зависимостей, а также как установить вещи (как разработчик VM) до работ в качестве более легкого веса эквивалента. Написание сценария улучшает воспроизведение, но в конце концов мы все должны отправить.
Ииридайн
Понижение рейтинга из-за советов о том, чтобы поместить набор инструментов и собрать артефакты в систему контроля версий. Да, если у вас есть плохие управленческие решения для них, иногда это может быть необходимо, но это никогда не желательно. И популярные OSS-инструменты, такие как PHP, всегда будут доступны (потому что нет ни одного издателя, который мог бы исчезнуть), поэтому в данном вопросе это определенно не нужно.
Марнен Лайбоу-Козер
13

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

Томас Оуэнс
источник
7

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

Другими словами, все, кроме ОС, приложений и инструментов, должно быть в VCS и во встроенных системах, где может существовать зависимость от конкретной двоичной версии инструмента, я также видел инструменты, хранящиеся в VCS!

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

Ларри Обриен
источник
1
Это также означает, что работа на нескольких машинах безболезненна. Просто потяните репо, и вы готовы к работе.
Спенсер Рэтбун
+1 за метеор, который хорошо подводит итоги.
Маффиниста
Может ли кто-то указать на пример (например) Java-проекта с полным набором инструментов под управлением rev, чтобы его можно было извлечь и использовать простым способом?
Андерсой
@andersoj Проверьте boxen.github.com
Ларри OBrien
6

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

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

Брайан Оукли
источник
2

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

Карл Билефельдт
источник
1

Все должно быть под контролем источников, кроме:

  • Файлы конфигурации, если они включают параметры конфигурации, которые различны для каждого разработчика и / или каждой среды (разработка, тестирование, производство)
  • Кэшируйте файлы, если вы используете кеширование файловой системы
  • Файлы журналов, если вы входите в текстовые файлы
  • Все, что, например, файлы кэша и файлы журнала, генерируется контентом.
  • (Очень) Большие двоичные файлы, которые вряд ли изменятся (некоторые системы контроля версий не любят их, но если вы используете hg или git, они не возражают против)

Подумайте об этом так: каждый новый член команды должен иметь возможность получить рабочую копию проекта (без элементов конфигурации).

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


@maple_shaft поднимает важную проблему с моим первым утверждением о файлах конфигурации среды в комментариях. Я хотел бы уточнить, что мой ответ заключается в специфике вопроса, который касается Drupal или общих проектов CMS. В таких сценариях у вас обычно есть локальная и производственная база данных, и один из параметров конфигурации среды - это учетные данные для этих баз данных (и аналогичные учетные данные). Желательно, чтобы они НЕ находились под контролем источников, так как это могло бы создать несколько проблем безопасности.

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

Яннис Ризос
источник
3
-1 Сильно не согласен с вашим утверждением о том, что файлы конфигурации не входят в систему контроля версий. Возможно, файлы конфигурации, специфичные для разработчика, да, однако файлы конфигурации, специфичные для среды, необходимы, если вам нужна возможность пошагового построения и развертывания любой среды.
maple_shaft
2
@maple_shaft В контексте вопроса (проект drupal или веб-проект gereric CMS) «одностадийная сборка и развертывание любой среды» - крайне маловероятный сценарий (будете ли вы вводить учетные данные рабочей базы данных вместе со всем?). Я отвечаю на вопрос, не предоставляя общих указаний о том, что следует поставить под контроль версий. - Но ваш downwote приветствуется :)
Яннис
Я могу видеть в ситуациях, когда хранилище исходного кода является общедоступным, как, например, в открытом исходном коде, или когда безопасность представляет собой серьезную проблему, как, например, в финансовых учреждениях, когда учетные данные базы данных не принадлежат контролю исходного кода. Помимо этого, система контроля версий должна быть защищена паролем и ограничена определенным набором пользователей, поэтому учетные данные базы данных в системе контроля версий не должны быть главной проблемой в этом сценарии. То, что вы указали, что для меня понижательное голосование кажется грубым, если вы отредактируете свой ответ, я смогу удалить его.
maple_shaft
@maple_shaft Не беспокойтесь о понижении (я редактировал вопрос, но вы можете оставить его, если хотите). Что касается контроля версий, защищенного паролем: нам недавно пришлось столкнуться с ситуацией, когда у члена нашей команды менеджеров был украден ноутбук, в котором содержался пароль к нашей системе контроля версий (в то время у нас были учетные данные S3). С его стороны это был большой снафу (ноутбук не был защищен паролем и некоторые другие детали, которые я не могу раскрыть), но все же это может случиться со всеми. Основываясь на этом опыте, мы переместили все из VCS.
Яннис
@maple_shaft и, хотя может показаться, что я защищаю паранойю, мы сейчас делаем все возможное, чтобы защитить что-либо, связанное с полномочиями, от подобного snafus.
Яннис
1

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

Например, следующее не входит в систему контроля версий:

  • сгенерированный код
  • сгенерированные двоичные файлы
  • все, что создано вашей сборкой
  • все, что создано во время выполнения вашим сервисом, процессом, веб-приложением

Что входит в систему контроля версий:

  • любое действие человек создает
  • все, что создано другим человеком или группой (например, сторонняя внутренняя библиотека, в которой распространяется управление исходным кодом, или двоичные файлы проекта с открытым исходным кодом).
  • сценарии и другие источники, которые создают такие вещи, как база данных (то есть, как бы вы воссоздали БД, если бы все АБД выходили из-под контроля).

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

Комплект
источник
1

Все, что вам нужно для работы и может измениться, должно так или иначе быть версионным. Но редко нужно, чтобы две независимые системы отслеживали это.

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

Журналы сборки и другие вещи, которые, вероятно, никого не интересуют (но вы никогда не знаете наверняка), обычно лучше всего отслеживаются теми, кто их генерирует: Дженкинс и т. Д.

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

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

ptyx
источник
0

Мой ответ довольно прост: не двоичные файлы. Подразумевается почти все остальное.

(Определенно, это не резервные копии базы данных, не миграция схем и не пользовательские данные.)

Нафтули Кей
источник
Миграции схемы абсолютно идут в систему контроля версий. Таким образом, вы знаете, какую схему БД ожидает код.
Марнен Лайбоу-Козер
0

Контроль версий - это механизм отслеживания изменений. Используйте его, когда хотите знать, кто что изменил и когда.

Контроль версий не является бесплатным. Это усложняет ваш рабочий процесс и требует обучения новых коллег. Взвесьте преимущества против стоимости.

Например, может быть сложно контролировать базы данных. У нас была система, в которой вам приходилось вручную сохранять определения в текстовом файле, а затем добавлять их в систему контроля версий. Это заняло много времени и было ненадежным. Поскольку это было ненадежно, вы не могли использовать его для создания новой базы данных или для проверки, в какое время было внесено изменение. Но мы держали это годами, тратя бесчисленные часы, потому что наш менеджер думал, что «все должно быть под контролем исходного кода».

Контроль источника не волшебство. Попробуйте, но откажитесь от него, если он не добавляет достаточной стоимости, чтобы компенсировать стоимость.

Andomar
источник
2
Ты серьезно? Контроль исходного кода плох, потому что он требует обучения новых коллег? Вы на самом деле говорите, что предпочитаете работать в течение длительного времени с людьми, которые не знают, как использовать систему контроля версий и не хотят учиться? Лично я бы лучше перевернул бургеры.
Зак
Хе-хе, я не спорю с контролем версий, просто против слепого использования контроля источников для всего. Если управление исходным кодом имеет очень сложный рабочий процесс, и это не добавляет ценности, я бы предпочел не использовать его.
Андомар
2
Моя точка зрения, даже если вы только использовать его для некоторых вещей ( кашель исходного кода кашель ), ваши коллеги уже должны знать , как использовать его, поэтому их обучение не следует увеличивать накладные расходы при использовании его для чего - то другого.
Зак
0

Вещи я бы не поставил в систему контроля версий:

  • Секретные ключи и пароли
  • SDK, хотя это тот же каталог, и если я сделаю патч для SDK, то a должен сделать его другим проектом, так как он будет для каждой платформы, а не для приложения.
  • Сторонние библиотеки, такие как. Остатки от миграции, резервные копии, скомпилированный код, код под другой лицензией (возможно)

Так что я не делаю, hg addremoveнапример, так как время от времени при обновлении SDK создаю новый клон. Это также заставляет меня делать полное резервное копирование каждый раз, когда обновляется SDK, и проверять, что новая версия, клонированная из хранилища, исправна.

Никлас Розенкранц
источник
0

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

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

Я не согласен с одной частью принятого ответа, предоставленного @FrustratedWithFormsDesigner меньше, потому что он выступает за то, чтобы не включать в систему контроля версий инструменты, необходимые для создания проекта. Где-то в управлении исходным кодом (рядом со строящимся кодом) должны быть сценарии сборки для сборки проекта и сценарии сборки, которые запускаются только из командной строки. Если под инструментами, которые он имеет в виду, IDE и редакторами, от них вообще не требуется создавать проект. Они хороши для активной / быстрой разработки для разработчиков, и настройка среды этого типа может быть также написана по сценарию или загружена из другого раздела SCM или с некоторого типа двоичного сервера управления, и настройка таких IDE должна быть максимально автоматизированной.

Я также не согласен с тем, что @Yannis Rizos заявляет о размещении конфигураций для сред в системе контроля версий . Причина в том, что вы должны иметь возможность реконструировать любую среду по своему усмотрению, используя только сценарии, и это невозможно сделать, не имея параметров конфигурации в системе контроля версий. Также нет истории развития конфигураций для различных сред без помещения этой информации в систему контроля версий. Теперь параметры производственной среды могут быть конфиденциальными, или компании могут не захотеть помещать их в систему управления версиями, поэтому второй вариант - по-прежнему помещать их в систему управления версиями, чтобы они имели историю, и предоставить этому хранилищу ограниченный доступ.

Lo-Tan
источник
-1

Храните весь код в системе контроля версий, а также все настройки и пользовательские данные. Чтобы быть специфичным для drupal, вам нужно поместить все в контроль версий, кроме файлов и settings.php

shahinam
источник