Git для настройки игрового сервера? - PullRequest
1 голос
/ 03 октября 2009

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

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

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

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

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

Любая помощь или мысль приветствуются.

Ответы [ 4 ]

2 голосов
/ 04 октября 2009

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

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

0 голосов
/ 09 ноября 2011

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

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

0 голосов
/ 03 октября 2009

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

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

0 голосов
/ 03 октября 2009

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

Могу ли я предложить более простое решение, например, вместо этого использовать Subversion. С Subversion у вас есть 1 центральное хранилище, и все ваши разработчики скопируют код оттуда и объединятся, когда закончат редактирование файлов.

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

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

...