Git для настройки игрового сервера?

Question

Мне было интересно, подходит ли git для этого. Итак, вот сценарий:

Мы думаем о размещении игрового сервера. Однако это не тот случай, когда вы просто загружаете файлы и запускаете сервер. Его необходимо тщательно настроить и поддерживать. Он также имеет возможности сценариев. Кроме того, будет немало «разработчиков», которые собираются внести свой вклад в этот проект и хотели бы, чтобы все серверные файлы синхронизировались на локальной машине для тестирования. Поэтому я думаю, что git будет отличным инструментом здесь.

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

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

Теперь проблема заключается в том, что эти две ветки должны быть доступны на жестком диске как в одно и то же время. И я немного запутался. Должны ли быть два отдельных хранилища? Один для стабильного запуска сервера и другого для тестирования? И тогда всякий раз, когда тестирование хранилища кажется достаточно стабильным, я должен подтолкнуть эти изменения к стабильному репо?

Любая помощь или мы принимаем.

Answer 1

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

Могу я предложить более простое решение, например, вместо использования подрывной работы. с subversion у вас есть 1 центральный репозиторий, и все ваши разработчики будут копировать код оттуда и объединиться, когда будут сделаны файлы редактирования.

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

Преждевременное разделение исходного хранилища на ветви обычно затрудняет согласование позже.

Answer 2

Я согласен, что подрывная деятельность намного легче понять, если это будет первый раз, когда вы работали с системой управления версиями. Есть множество сайтов, на которых размещается ваш проект бесплатно, sourceforge и codeplex - примеры, или если вы хотите разместить сервер самостоятельно, я могу рекомендовать сервер VisualSVN, мы используем его на работе, его легко настроить и поддерживать, и это бесплатно, поскольку лицензия VisualSVN оплачивается только для лицензий Visual Studio. Я также соглашаюсь на ветвление, старайтесь не переусердствовать, когда вы начинаете, вам понадобится только один репозиторий, внутри которого вы должны создать свой проект со всеми папками и файлами под ним. Вы должны согласиться со всеми членами команды, при каких обстоятельствах будут внесены изменения в проект. Это будет зависеть от того, какое состояние вам нужно, чтобы сохранить проект. Например, если вам нужно в любое время перейти в репозиторий для извлечения файлов и настройки игрового сервера, тогда правила должны отражать это. Если вы еще не сделали этого, вы должны получить хороший инструмент для операций diff/merge. Мы используем Winmerge, который является бесплатным и выполняет большинство базовых задач, и там есть коммерческие инструменты, которые поддерживают более продвинутые функции, такие как Beyond Compare и Araxis merge. Я использовал оба, и они хороши. Я также предлагаю вам проверить TortoiseSVN, это клиент, который помогает вам фиксировать изменения и получать обновления с сервера SVN.

Что касается ветвления, если в какой-то момент вы решили добавить большой набор изменений в течение длительного периода времени, тогда вы должны рассмотреть вопрос о ветвлении проекта. Не принимайте это решение легко, так как это может быть большая работа, чтобы объединить ветку обратно в багажник. Как только вы освоитесь с SVN и будете довольны концепциями, легко перейти на GIT, если вы почувствуете, что дополнительные функции, которые он предлагает, будут полезны команде.

Answer 3

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

Однако остерегайтесь, если вы также для хранения больших двоичных файлов в репозитории, а также. Git отслеживает историю ВСЕХ файлов, которые когда-либо были в репозитории (даже если они были удалены). Так что это не особенно экономично с двоичными данными - текст лучше (например, файлы конфигурации)

Answer 4

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

github.com tutorials - отличное место для начала.