Starshine Wiki - Вклад [ru]

Git для разработчика SS14

2023-09-27T21:36:01Z

Ser11y: /* Словарь: Внутренние операции Git */

== Предисловие ==
В тексте будет часто упоминаться GitLab - аналог GitHub, которым также пользуется Workbench Team. Принципиальной разницы нет, все шаги возможны и на GitHub, но лично мне удобнее работать с GitLab.
Если Вам не ясны какие-либо термины из текста ниже, обратитесь к разделу [[Git_для_разработчика_SS14#Словарь:_Внутренние_операции_Git|Словарь: Внутренние операции Git]].

== Установка Git ==
Для работы с Git для SS14 Вам понадобятся:
* [https://git-scm.com/downloads Git]
** Если Вы хотите использовать Git только в консоли, поставьте галочку при установке:
[[Файл:GitBash.png|мини|центр]]
* [https://www.python.org/downloads/ Python 3.7+]

Если Вы работаете в Linux, то, скорее всего, будете использовать Git через терминал или выбранную Вами IDE, и, возможно, он у Вас уже установлен.

Некоторые IDE имеют в себе интеграцию Git, но этом руководстве будет информация '''только''' об использовании ''приложений'' [[Git для разработчика SS14#Git_Bash|Git Bash]] и [[Git для разработчика SS14#Fork|Fork]].

=== Fork ===
[https://git-fork.com/ Fork] — быстрый и удобный Git-клиент, позволяющий делать всё, что можно в консоли, но удобнее.

== Налаживание репозиториев Git ==
Репозиторий - это просто база кода. Репозитории содержат branch'и, а эти branch'и содержат различные commit'ы. Возможно, Вы слышали об этих двух понятиях - подробнее о них будет рассказано позже.

Удаленный репозиторий - это просто репозиторий на GitLab. Локальный репозиторий - это тот, который находится на Вашем компьютере.
=== Создание Вашего remote репозитория ===
Сперва давайте создадим собственный Fork удаленного репозитория Space Station 14. Для этого, конечно же, потребуется учетная запись GitLab. Forking означает, что Вы копируете всю историю и изменения репозитория в свой собственный удаленный репозиторий, чтобы иметь возможность свободно работать с кодом.

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

Перейдите в наш репозиторий Space Station 14([https://github.com/Workbench-Team/space-station-14 GitHub], [https://git.arumoon.ru/Workbench-Team/space-station-14 GitLab]) и нажмите здесь:
[[Файл:ForksButton.png|мини|центр]]
Затем Вас спросят как назвать Fork - просто назовите его как угодно! Но если Вы хотите просто помочь в разработке, я бы выбрал space-station-14.
=== Создание Вашего локального репозитория ===
Теперь нам нужно загрузить наш удаленный репозиторий на компьютер (клонировать), чтобы мы могли внести в него некоторые изменения. Технически, Вы можете изменять репозиторий удалённо (на GitLab есть неплохие инструменты), но наличие его на Вашем компьютере означает, что Вы используете IDE, такие как Visual Studio или Rider, для сборки игры и запуска тестов, а также легко работаете с Git.

Для каждого шага будут приведены скриншоты и инструкции для Git Bash и Fork для Windows.
===== GitBash: =====
Перейдите в то место на Вашем компьютере, где Вы хотите разместить локальный репозиторий, и:
[[Файл:GitBashHere.png|мини|центр]]
Выберите какой репозиторий клонировать:
[[Файл:GitBashCloneCommand.png|мини|центр]]
Проделайте команду <code>git remote add upstream</code> с <code>https://git.arumoon.ru/Workbench-Team/space-station-14</code>, чтобы у Вас была возможность обновлять свои branch'и новыми обновлениями upstream'а.
===== Fork: =====
Нажмите <code>Ctrl + N</code> в программе, или File => Clone..., а затем введите адрес репозитория с припиской <code>.git</code> в конце.
[[Файл:ForkCloneRepositoryButton.png|мини|центр]]

Добавьте удалённый репозиторий, нажав следующую кнопку:
[[Файл:ForkAddRemoteButton.png|центр]]
Введите <code>https://git.arumoon.ru/Workbench-Team/space-station-14.git</code>, чтобы у Вас была возможность обновлять свои branch'и новыми обновлениями upstream'а.
[[Файл:ForkCreateBranchMenuText.png|центр]]

=== Подмодули ===
Обратите на это внимание! Если этого не сделать, то при попытке сборки игры вы получите множество странных ошибок о недоступности тех или иных модулей.

В Space Station 14 есть много подмодулей - в первую очередь, движок RobustToolbox. Подмодули - это просто репозитории внутри репозитория, и их нужно обновлять вручную. А нужно ли?

У нас есть автоматическая программа обновления подмодулей, так что Вам не нужно постоянно выполнять <code>git submodule update --init --recursive</code> (команда для ручного обновления подмодулей).

Запустите <code>RUN_THIS.py</code> внутри репозитория, который Вы скачали, с помощью Python. Желательно, из терминала (<code>python RUN_THIS.py</code> или <code>python3 RUN_THIS.py</code>). Это должно занять несколько секунд, так что если все мгновенно прекратится, то, вероятно, Вы не используете [https://www.python.org/downloads/ Python 3.7+] или что-то в этом роде.

Если Вы работаете в Windows и при попытке выполнить приведенную выше команду Вас перенаправляет в Microsoft Store или Вы получаете сообщение в терминале о том, что Python не установлен, необходимо отключить shortcut Microsoft, который может вызывать эту проблему. Это можно сделать, найдя в поиске Windows команду <code>Manage App Execution Aliases</code>, а затем отключив две точки привязки Python.

Если Вы все же хотите модифицировать движок напрямую или обновлять подмодуль вручную (автоматическое обновление иногда доставляет неудобства), создайте файл <code>DISABLE_SUBMODULE_AUTOUPDATE</code> в каталоге <code>BuildChecker/.</code>.

Если по каким-либо причинам, Вам понадобится вручную обновить RobustToolbox, Вы можете использовать <code>cd RobustToolbox; git checkout v0.4.87</code> (замените <code>v0.4.87</code> на последнюю версию RobustToolbox), затем Вы можете использовать <code>cd..\</code>, чтобы вернуться в репозиторий SS14. Это также пример использования cd для навигации по файлам, не выходя из командной строки.
== Branching & Commits (Ветки и коммиты) ==

=== Что такое branch? ===
Branch'и очень и очень важны. По сути, они представляют собой лист изменений в коде (commit'ов). По умолчанию используется branch <code>master</code>.

При работе с кодом Вы всегда находитесь в branch'е, и Вы можете легко менять branch, в котором работаете.

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

Branch'ей можно создавать сколько угодно. Когда Вы создаете branch, он ответвляется от текущего branch'а и становится самостоятельным объектом, в который можно добавлять commit'ы.
[[Файл:BranchDiagram.png|мини|центр|Каждый маленький узел - это отдельный commit, а каждый цвет - отдельный branch.]]
==== Зачем это нужно? ====
Технически, конечно, можно просто делать всю работу в одном branch'е и отправлять Merge Request'ы оттуда. Но создание различных branch'ей позволяет легко понять, где Вы находитесь, сколько изменений внесли, и дает возможность работать над несколькими особенностями(новым содержимым) одновременно.
==== Создание и работа с branch'ами ====
Создавать branch'и довольно просто. Давайте создадим новый branch под названием <code>funny-feature</code>:
===== Git Bash =====
[[Файл:GitBashNewBranchCommand.png|мини|центр]]
Параметр <code>-b</code> в <code>git checkout</code> здесь означает "проверь этот branch, и создай его, если он не существует".
===== Fork =====
Ctrl + Shift + B или кнопка сверху откроет меню создания branch'а:
[[Файл:ForkCreateBranchButton.png|мини|центр|Кнопка создания branch'а]]
[[Файл:ForkCreateBranchMenu.png|мини|центр|Меню создания branch'а]]
Создайте branch с именем funny-feature.

Переключаться между branch'ами довольно просто: это называется проверкой branch'а. При этом локальные файлы и папки будут изменены в соответствии с веткой, поэтому Git будет кричать на Вас, если у Вас есть локальные изменения, а Вы пытаетесь выполнить проверку.

===== Git Bash =====
[[Файл:GitBashCheckoutBranchCommand.png|мини|центр]]
===== Fork =====
Два раза нажмите на имя branch'а слева.
[[Файл:ForkCheckoutBranchButton.png|центр]]

Ну а затем внесите любые локальные изменения! Это не имеет значения. Создайте новый файл, удалите всё, измените одну строку в файле и т.д. Это не повлияет на Ваш главный branch, потому что теперь это территория <code>funny-feature</code>!
==== Совмещение branch'ей ====
Branche'и важны, поскольку их можно объединять. Так происходит интеграция функций в основную ветку. Merge означает "взять особые commit'ы из этого branch'а и применить их к другому branch'у". Вы можете объединить любые два branch'а.

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

GitLab Merge Request - это, по сути, "запрос на объединение": Вы говорите, что хотите объединить commit'ы своего branch'а с другим branch'ом, обычно главным. Подробнее об этом позже.

Merge Request'ы очень хорошо отображают всю эту информацию:
[[Файл:MergeRequestExampleImage.png|мини|центр]]
[[Файл:MergeRequestExampleCommitsImage.png|мини|центр]]

=== Что такое commit? ===
Commit'ы - это просто упакованные изменения в коде. Как разработчик, Вы выбираете, какие изменения войдут в commit и когда их вносить в branch. Commiting - это создание commit'а, который, по сути, является точкой сохранения, к которой можно вернуться в любое время.

Commit'ы имеют автора, временную метку, сообщение и некоторые изменения кода, прикрепленные к ним. Они также имеют очень длинный "commit hash" - уникальный идентификатор, используемый для ссылки на различные коммиты.

Благодаря commit'ам строится история - Вы можете просмотреть историю каждого коммита, сделанного в репозитории SS14 с самого начала, что очень здорово.
==== Отправка commit'ов в branch'и ====
Один важный момент: прежде чем отправлять изменения в commit, необходимо добавить их в область staging'а. Это означает, что Вы указываете, какие файлы хотите добавить в commit. Это полезно, поскольку Вы почти никогда не захотите commit'ить изменения подмодулей, так что Вы просто не добавляете их в область staging'а.

Commit'ы всегда сопровождаются сообщением, которое представляет собой краткое, содержательное описание того, что было сделано в данном commit'е. Или Вы можете быть "Чадом"(страна) и называть каждый коммит "меняет всякое" - на Ваше усмотрение.

Если Вы хотите посмотреть, что Вы изменили в данный момент, а что находится в области staging'а, то это довольно просто:
===== Git Bash =====
[[Файл:GitBashCheckStatusCommand.png|мини|центр]]

===== Fork =====
Откройте меню локальных изменений, нажав на кнопку сверху слева:
[[Файл:ForkCheckStatusCommand.png|центр]]

Теперь, когда Вы убедились, что все эти изменения выглядят хорошо, мы добавим их в область staging'а и сделаем commit с ними:
===== Git Bash =====
[[Файл:GitBashStashAndCommitCommand.png|мини|центр]]

===== Fork =====
Добавляйте и убирайте изменения(выделите их) с помощью двух кнопок.
[[Файл:ForkStashAndCommitMenu.png|мини|центр]]
Напишите название и описание commit'а, а затем подтвердите отправку:
[[Файл:ForkCommitMenu.png|центр]]

Теперь, когда изменения были добавлены в commit и отправлены в branch, они навсегда (вроде как) остаются в истории branch'а. Теперь мы можем сделать многое: объединить(merge) нашу <code>funny-feature</code> с нашим локальным мастер-branch'ем (если захотим, по какой-то причине), загрузить (push) наш branch <code>funny-feature</code> в наш удалённый репозиторий, или полностью удалить ветку. Мы выберем push и сделаем Merge Request.

== Pushing и создание Merge Request'ов ==
Merge Request означает, что Вы хотите, чтобы кодовая база объединила Ваши изменения в одного из Ваших branch'ей в один из их branch'ей. Прежде чем мы сможем это сделать, наш удаленный репозиторий GitLab (upstream) должен знать о красивых branch'ах и commit'ах, которые мы создали локально, поэтому мы push'им эти изменения на удаленный репозиторий.
=== Проталкивание commit'ов ===
Имейте в виду, что при использовании этих команд Git, скорее всего, запросит Ваши учетные данные GitLab, чтобы убедиться в том, что Вы имеете право выполнять push на этот удаленный репозиторий.

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

Push'им наш branch в удалённый репозиторий (upstream):
===== Git Bash =====
[[Файл:GitBashPushCommand.png|мини|центр]]

===== Fork =====
[[Файл:ForkPushCommandButton.png|центр]]

=== Создание Merge Request'ов ===
Весёлая часть. Отправляемся на GitLab и создаём наш Merge Request:
[[Файл:GitLabFunnyFeatureMergeRequestButton.png|мини|центр]]
Добавьте описание, красивое название, несколько скриншотов, и, надеюсь, оно будет merge'нуто.

== Обновление репозитория ==
Возможно, прошло уже много времени, неделя или две, с момента Вашего последнего Merge Request'а, и Вы хотите сделать еще один. Прежде чем что-либо делать, необходимо загрузить (pull) изменения кода из основного репозитория SS14 в свой локальный репозиторий. В противном случае Вы получите устаревший код, а Ваши локальные изменения могут не соответствовать тому, как игра будет работать на самом деле - Вы даже можете получить конфликты слияния при попытке MR.

Существует два способа обновления репозитория. Оба способа предполагают, что Вы правильно настроили доступ к удалённому репозиторию - если это не так, вернитесь к предыдущему пункту руководства.

Первый способ, fetch+merge, дает больше возможностей для контроля, но может быть запутанным. Второй метод, pull, прост и удобен, но не дает большого контроля. Однако, как правило, pull - это все, что вам нужно.
=== Метод pull ===
Pulling означает получение (fetching) новых веток и commit'ов из удаленного репозитория, а затем их слияние с branch'ем. Pulling часто проще, поскольку Git имеет хорошую систему автоматического определения того, из какого удаленного репозитория Вы хотите получить изменения (но она не всегда работает корректно).

Мы будем pull'ить с нашего удалённого репозитория <code>upstream</code> и попросим его объединиться с нашим локальным branch'ем.

Сначала, Вам надо сделать checkout Вашего branch'а. Об этом мы рассказывали ранее. Затем:
===== Git Bash =====
[[Файл:GitBashPullUpstreamCommand.png|мини|центр]]
Делайте это регулярно и всегда до начала работы над новым branch'ем.

===== Fork =====
[[Файл:ForkPullUpstreamCommandButton.png|центр]]

== Приложения ==
=== Что следует помнить ===
Вы более или менее изучили рабочий процесс разработки функций для SS14 с точки зрения Git, но вот некоторые вещи, которые я хотел бы вбить Вам в голову:

* При создании новой функциональности всегда создавайте новый branch от главного, прежде чем commit'ить что-либо. Если Вы случайно за-commit'ите изменения физики в branch с велосипедным клаксоном, Вам не поздоровится, но это поправимо.
* Никогда, никогда не фиксируйте RobustToolbox или подмодули типа Lidgren.Network, если Вы не знаете, что делаете. В локальном репозитории верхнего уровня эти подмодули считаются "файлами", поэтому их легко случайно отправить на staging и сделать commit с ними. Не делайте этого. О том, как исправить свои ошибки, если это произошло, см. ниже.

== Словарь: Внутренние операции Git ==
В качестве справочного материала здесь приведен небольшой глоссарий понятий и терминов Git, объясняющий их более подробно и в одном месте.

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

'''Репозитории''' - это папки, в которых с помощью Git можно вносить изменения и отслеживать их. Локальные репозитории - это репозитории, которые находятся у Вас на компьютере, а удаленные репозитории - это репозитории, расположенные на таких сайтах, как GitLab Репозитории состоят из множества веток.

'''Remotes''' - это названия и ссылки на удаленные репозитории, которые может использовать Ваш локальный репозиторий.

'''Подмодули''' - это репозитории, которые находятся внутри другого репозитория.

'''Forks''' - это репозитории, основанные на другом репозитории. Если Вы собираетесь сделать Merge Request для SS14, Вам необходимо сначала сделать Fork.

'''The working tree''' - это все файлы, папки и т.п., находящиеся в репозитории.

'''Staging''' означает добавление (с помощью git add) изменений в 'staging area', где с ними могут быть выполнены некоторые действия.

'''Commits''' - это изменения рабочего дерева репозитория в определенный момент времени. По сути, это точка сохранения. Commit - это просто список файлов, которые были изменены с момента последнего коммита, а изменения, которые были commit'нуты, - это изменения, которые Вы отправили в staging area.

'''Checking out''' - это переключение на другой branch, чтобы работать с ним или просматривать его изменения локально.

'''Merging''' - это интеграция изменений из одного branch'а в другой.

'''Конфликты merge'а''' возникают, когда интеграция изменений из одного branch'а в другой не может быть выполнена автоматически, поскольку они оба изменяют одну и ту же область в файле, или их изменения взаимоисключают друг друга каким-либо другим способом.

'''Fetching''' означает получение branch'ей и commit'ов удаленного репозитория, но на самом деле... еще ничего с ними не делая. Они будут просто обновлены, если вы захотите проверить или объединить их позже.

'''Pulling''' - это акт интеграции изменений из branch'а удаленного репозитория в Ваш локальный branch.

'''Merge Requests''' - это действие, позволяющее запросить слияние Вашего локального branch'а и всех его изменений с branch'а другого репозитория.

'''Pushing''' - это действие по интеграции локальных изменений в удаленный репозиторий.

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

Одно замечание, поскольку оно часто встречается здесь: HEAD - это модное название commit'а, на котором Вы сейчас находитесь.
=== Разрешение конфликтов при merge ===
Вредный маленький maintainer сказал вам "разрешить конфликты", иначе ваш MR "не будет merge'нут". Вот ведь сволочь! К счастью, это не так уж сложно.

Сначала нужно обновить главный локальный branch. Как это сделать, см. выше.

Когда Вы выполните команду <code>git merge master [локальный branch]</code>, она либо сделает это без ошибок ("ура"), либо сообщит Вам, что необходимо разрешить конфликты (ужас).

Для разрешения конфликтов вручную достаточно зайти в конфликтующие файлы, удалить всю ерунду типа <code>>>>>HEAD</code> и <code>===== <<<<master</code> (просто указывает, откуда произошли изменения), а затем отредактировать файл так, чтобы он правильно объединял оба набора изменений. Иногда это легко, иногда трудно. Если это сложно, то Вы, вероятно, знаете, что делаете. После этого просто выполните команду <code>git commit</code>.

У Atlassian есть [https://www.atlassian.com/git/tutorials/using-branches/merge-conflicts очень хорошее руководство] по этому вопросу.
=== Проверка истории ===
<code>git log --oneline</code> - это Ваш друг. Он показывает короткие hashe'и commit'ов (уникальные идентификаторы), их сообщения, а также их branch'и и tag'и.

В Fork эта функция встроена в UI:
[[Файл:ForkCommitHistory.png|мини|центр]]
=== Очистка локальных изменений ===
Возможно, Вы случайно внесли ненужные изменения, и Вам не хочется возиться с созданием совершенно новой ветки или еще чего-нибудь, но Вы еще не сделали commit с ними.

<code>git reset --hard HEAD</code>
Это означает "изменить working tree на текущий commit, до внесения любых локальных изменений. Вы не сможете восстановить локальные изменения, если сделаете это, так что будьте осторожны.
=== Откат сделанного Вами commit'а ===
Вот черт, Ваша эротика про ксеноморфа попала в commit или Вы случайно commit'нули подмодуль! Что теперь? Есть решения:

<code>git revert HEAD</code>
Это создаст новый commit, отменяющий текущий commit, и затем commit'нет его. Хе-хе, commit.

Git для разработчика SS14

2023-09-27T21:34:38Z

Ser11y: Добавлена информация для Fork

== Предисловие ==
В тексте будет часто упоминаться GitLab - аналог GitHub, которым также пользуется Workbench Team. Принципиальной разницы нет, все шаги возможны и на GitHub, но лично мне удобнее работать с GitLab.
Если Вам не ясны какие-либо термины из текста ниже, обратитесь к разделу [[Git_для_разработчика_SS14#Словарь:_Внутренние_операции_Git|Словарь: Внутренние операции Git]].

== Установка Git ==
Для работы с Git для SS14 Вам понадобятся:
* [https://git-scm.com/downloads Git]
** Если Вы хотите использовать Git только в консоли, поставьте галочку при установке:
[[Файл:GitBash.png|мини|центр]]
* [https://www.python.org/downloads/ Python 3.7+]

Если Вы работаете в Linux, то, скорее всего, будете использовать Git через терминал или выбранную Вами IDE, и, возможно, он у Вас уже установлен.

Некоторые IDE имеют в себе интеграцию Git, но этом руководстве будет информация '''только''' об использовании ''приложений'' [[Git для разработчика SS14#Git_Bash|Git Bash]] и [[Git для разработчика SS14#Fork|Fork]].

=== Fork ===
[https://git-fork.com/ Fork] — быстрый и удобный Git-клиент, позволяющий делать всё, что можно в консоли, но удобнее.

== Налаживание репозиториев Git ==
Репозиторий - это просто база кода. Репозитории содержат branch'и, а эти branch'и содержат различные commit'ы. Возможно, Вы слышали об этих двух понятиях - подробнее о них будет рассказано позже.

Удаленный репозиторий - это просто репозиторий на GitLab. Локальный репозиторий - это тот, который находится на Вашем компьютере.
=== Создание Вашего remote репозитория ===
Сперва давайте создадим собственный Fork удаленного репозитория Space Station 14. Для этого, конечно же, потребуется учетная запись GitLab. Forking означает, что Вы копируете всю историю и изменения репозитория в свой собственный удаленный репозиторий, чтобы иметь возможность свободно работать с кодом.

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

Перейдите в наш репозиторий Space Station 14([https://github.com/Workbench-Team/space-station-14 GitHub], [https://git.arumoon.ru/Workbench-Team/space-station-14 GitLab]) и нажмите здесь:
[[Файл:ForksButton.png|мини|центр]]
Затем Вас спросят как назвать Fork - просто назовите его как угодно! Но если Вы хотите просто помочь в разработке, я бы выбрал space-station-14.
=== Создание Вашего локального репозитория ===
Теперь нам нужно загрузить наш удаленный репозиторий на компьютер (клонировать), чтобы мы могли внести в него некоторые изменения. Технически, Вы можете изменять репозиторий удалённо (на GitLab есть неплохие инструменты), но наличие его на Вашем компьютере означает, что Вы используете IDE, такие как Visual Studio или Rider, для сборки игры и запуска тестов, а также легко работаете с Git.

Для каждого шага будут приведены скриншоты и инструкции для Git Bash и Fork для Windows.
===== GitBash: =====
Перейдите в то место на Вашем компьютере, где Вы хотите разместить локальный репозиторий, и:
[[Файл:GitBashHere.png|мини|центр]]
Выберите какой репозиторий клонировать:
[[Файл:GitBashCloneCommand.png|мини|центр]]
Проделайте команду <code>git remote add upstream</code> с <code>https://git.arumoon.ru/Workbench-Team/space-station-14</code>, чтобы у Вас была возможность обновлять свои branch'и новыми обновлениями upstream'а.
===== Fork: =====
Нажмите <code>Ctrl + N</code> в программе, или File => Clone..., а затем введите адрес репозитория с припиской <code>.git</code> в конце.
[[Файл:ForkCloneRepositoryButton.png|мини|центр]]

Добавьте удалённый репозиторий, нажав следующую кнопку:
[[Файл:ForkAddRemoteButton.png|центр]]
Введите <code>https://git.arumoon.ru/Workbench-Team/space-station-14.git</code>, чтобы у Вас была возможность обновлять свои branch'и новыми обновлениями upstream'а.
[[Файл:ForkCreateBranchMenuText.png|центр]]

=== Подмодули ===
Обратите на это внимание! Если этого не сделать, то при попытке сборки игры вы получите множество странных ошибок о недоступности тех или иных модулей.

В Space Station 14 есть много подмодулей - в первую очередь, движок RobustToolbox. Подмодули - это просто репозитории внутри репозитория, и их нужно обновлять вручную. А нужно ли?

У нас есть автоматическая программа обновления подмодулей, так что Вам не нужно постоянно выполнять <code>git submodule update --init --recursive</code> (команда для ручного обновления подмодулей).

Запустите <code>RUN_THIS.py</code> внутри репозитория, который Вы скачали, с помощью Python. Желательно, из терминала (<code>python RUN_THIS.py</code> или <code>python3 RUN_THIS.py</code>). Это должно занять несколько секунд, так что если все мгновенно прекратится, то, вероятно, Вы не используете [https://www.python.org/downloads/ Python 3.7+] или что-то в этом роде.

Если Вы работаете в Windows и при попытке выполнить приведенную выше команду Вас перенаправляет в Microsoft Store или Вы получаете сообщение в терминале о том, что Python не установлен, необходимо отключить shortcut Microsoft, который может вызывать эту проблему. Это можно сделать, найдя в поиске Windows команду <code>Manage App Execution Aliases</code>, а затем отключив две точки привязки Python.

Если Вы все же хотите модифицировать движок напрямую или обновлять подмодуль вручную (автоматическое обновление иногда доставляет неудобства), создайте файл <code>DISABLE_SUBMODULE_AUTOUPDATE</code> в каталоге <code>BuildChecker/.</code>.

Если по каким-либо причинам, Вам понадобится вручную обновить RobustToolbox, Вы можете использовать <code>cd RobustToolbox; git checkout v0.4.87</code> (замените <code>v0.4.87</code> на последнюю версию RobustToolbox), затем Вы можете использовать <code>cd..\</code>, чтобы вернуться в репозиторий SS14. Это также пример использования cd для навигации по файлам, не выходя из командной строки.
== Branching & Commits (Ветки и коммиты) ==

=== Что такое branch? ===
Branch'и очень и очень важны. По сути, они представляют собой лист изменений в коде (commit'ов). По умолчанию используется branch <code>master</code>.

При работе с кодом Вы всегда находитесь в branch'е, и Вы можете легко менять branch, в котором работаете.

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

Branch'ей можно создавать сколько угодно. Когда Вы создаете branch, он ответвляется от текущего branch'а и становится самостоятельным объектом, в который можно добавлять commit'ы.
[[Файл:BranchDiagram.png|мини|центр|Каждый маленький узел - это отдельный commit, а каждый цвет - отдельный branch.]]
==== Зачем это нужно? ====
Технически, конечно, можно просто делать всю работу в одном branch'е и отправлять Merge Request'ы оттуда. Но создание различных branch'ей позволяет легко понять, где Вы находитесь, сколько изменений внесли, и дает возможность работать над несколькими особенностями(новым содержимым) одновременно.
==== Создание и работа с branch'ами ====
Создавать branch'и довольно просто. Давайте создадим новый branch под названием <code>funny-feature</code>:
===== Git Bash =====
[[Файл:GitBashNewBranchCommand.png|мини|центр]]
Параметр <code>-b</code> в <code>git checkout</code> здесь означает "проверь этот branch, и создай его, если он не существует".
===== Fork =====
Ctrl + Shift + B или кнопка сверху откроет меню создания branch'а:
[[Файл:ForkCreateBranchButton.png|мини|центр|Кнопка создания branch'а]]
[[Файл:ForkCreateBranchMenu.png|мини|центр|Меню создания branch'а]]
Создайте branch с именем funny-feature.

Переключаться между branch'ами довольно просто: это называется проверкой branch'а. При этом локальные файлы и папки будут изменены в соответствии с веткой, поэтому Git будет кричать на Вас, если у Вас есть локальные изменения, а Вы пытаетесь выполнить проверку.

===== Git Bash =====
[[Файл:GitBashCheckoutBranchCommand.png|мини|центр]]
===== Fork =====
Два раза нажмите на имя branch'а слева.
[[Файл:ForkCheckoutBranchButton.png|центр]]

Ну а затем внесите любые локальные изменения! Это не имеет значения. Создайте новый файл, удалите всё, измените одну строку в файле и т.д. Это не повлияет на Ваш главный branch, потому что теперь это территория <code>funny-feature</code>!
==== Совмещение branch'ей ====
Branche'и важны, поскольку их можно объединять. Так происходит интеграция функций в основную ветку. Merge означает "взять особые commit'ы из этого branch'а и применить их к другому branch'у". Вы можете объединить любые два branch'а.

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

GitLab Merge Request - это, по сути, "запрос на объединение": Вы говорите, что хотите объединить commit'ы своего branch'а с другим branch'ом, обычно главным. Подробнее об этом позже.

Merge Request'ы очень хорошо отображают всю эту информацию:
[[Файл:MergeRequestExampleImage.png|мини|центр]]
[[Файл:MergeRequestExampleCommitsImage.png|мини|центр]]

=== Что такое commit? ===
Commit'ы - это просто упакованные изменения в коде. Как разработчик, Вы выбираете, какие изменения войдут в commit и когда их вносить в branch. Commiting - это создание commit'а, который, по сути, является точкой сохранения, к которой можно вернуться в любое время.

Commit'ы имеют автора, временную метку, сообщение и некоторые изменения кода, прикрепленные к ним. Они также имеют очень длинный "commit hash" - уникальный идентификатор, используемый для ссылки на различные коммиты.

Благодаря commit'ам строится история - Вы можете просмотреть историю каждого коммита, сделанного в репозитории SS14 с самого начала, что очень здорово.
==== Отправка commit'ов в branch'и ====
Один важный момент: прежде чем отправлять изменения в commit, необходимо добавить их в область staging'а. Это означает, что Вы указываете, какие файлы хотите добавить в commit. Это полезно, поскольку Вы почти никогда не захотите commit'ить изменения подмодулей, так что Вы просто не добавляете их в область staging'а.

Commit'ы всегда сопровождаются сообщением, которое представляет собой краткое, содержательное описание того, что было сделано в данном commit'е. Или Вы можете быть "Чадом"(страна) и называть каждый коммит "меняет всякое" - на Ваше усмотрение.

Если Вы хотите посмотреть, что Вы изменили в данный момент, а что находится в области staging'а, то это довольно просто:
===== Git Bash =====
[[Файл:GitBashCheckStatusCommand.png|мини|центр]]

===== Fork =====
Откройте меню локальных изменений, нажав на кнопку сверху слева:
[[Файл:ForkCheckStatusCommand.png|центр]]

Теперь, когда Вы убедились, что все эти изменения выглядят хорошо, мы добавим их в область staging'а и сделаем commit с ними:
===== Git Bash =====
[[Файл:GitBashStashAndCommitCommand.png|мини|центр]]

===== Fork =====
Добавляйте и убирайте изменения(выделите их) с помощью двух кнопок.
[[Файл:ForkStashAndCommitMenu.png|мини|центр]]
Напишите название и описание commit'а, а затем подтвердите отправку:
[[Файл:ForkCommitMenu.png|центр]]

Теперь, когда изменения были добавлены в commit и отправлены в branch, они навсегда (вроде как) остаются в истории branch'а. Теперь мы можем сделать многое: объединить(merge) нашу <code>funny-feature</code> с нашим локальным мастер-branch'ем (если захотим, по какой-то причине), загрузить (push) наш branch <code>funny-feature</code> в наш удалённый репозиторий, или полностью удалить ветку. Мы выберем push и сделаем Merge Request.

== Pushing и создание Merge Request'ов ==
Merge Request означает, что Вы хотите, чтобы кодовая база объединила Ваши изменения в одного из Ваших branch'ей в один из их branch'ей. Прежде чем мы сможем это сделать, наш удаленный репозиторий GitLab (upstream) должен знать о красивых branch'ах и commit'ах, которые мы создали локально, поэтому мы push'им эти изменения на удаленный репозиторий.
=== Проталкивание commit'ов ===
Имейте в виду, что при использовании этих команд Git, скорее всего, запросит Ваши учетные данные GitLab, чтобы убедиться в том, что Вы имеете право выполнять push на этот удаленный репозиторий.

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

Push'им наш branch в удалённый репозиторий (upstream):
===== Git Bash =====
[[Файл:GitBashPushCommand.png|мини|центр]]

===== Fork =====
[[Файл:ForkPushCommandButton.png|центр]]

=== Создание Merge Request'ов ===
Весёлая часть. Отправляемся на GitLab и создаём наш Merge Request:
[[Файл:GitLabFunnyFeatureMergeRequestButton.png|мини|центр]]
Добавьте описание, красивое название, несколько скриншотов, и, надеюсь, оно будет merge'нуто.

== Обновление репозитория ==
Возможно, прошло уже много времени, неделя или две, с момента Вашего последнего Merge Request'а, и Вы хотите сделать еще один. Прежде чем что-либо делать, необходимо загрузить (pull) изменения кода из основного репозитория SS14 в свой локальный репозиторий. В противном случае Вы получите устаревший код, а Ваши локальные изменения могут не соответствовать тому, как игра будет работать на самом деле - Вы даже можете получить конфликты слияния при попытке MR.

Существует два способа обновления репозитория. Оба способа предполагают, что Вы правильно настроили доступ к удалённому репозиторию - если это не так, вернитесь к предыдущему пункту руководства.

Первый способ, fetch+merge, дает больше возможностей для контроля, но может быть запутанным. Второй метод, pull, прост и удобен, но не дает большого контроля. Однако, как правило, pull - это все, что вам нужно.
=== Метод pull ===
Pulling означает получение (fetching) новых веток и commit'ов из удаленного репозитория, а затем их слияние с branch'ем. Pulling часто проще, поскольку Git имеет хорошую систему автоматического определения того, из какого удаленного репозитория Вы хотите получить изменения (но она не всегда работает корректно).

Мы будем pull'ить с нашего удалённого репозитория <code>upstream</code> и попросим его объединиться с нашим локальным branch'ем.

Сначала, Вам надо сделать checkout Вашего branch'а. Об этом мы рассказывали ранее. Затем:
===== Git Bash =====
[[Файл:GitBashPullUpstreamCommand.png|мини|центр]]
Делайте это регулярно и всегда до начала работы над новым branch'ем.

===== Fork =====
[[Файл:ForkPullUpstreamCommandButton.png|центр]]

== Приложения ==
=== Что следует помнить ===
Вы более или менее изучили рабочий процесс разработки функций для SS14 с точки зрения Git, но вот некоторые вещи, которые я хотел бы вбить Вам в голову:

* При создании новой функциональности всегда создавайте новый branch от главного, прежде чем commit'ить что-либо. Если Вы случайно за-commit'ите изменения физики в branch с велосипедным клаксоном, Вам не поздоровится, но это поправимо.
* Никогда, никогда не фиксируйте RobustToolbox или подмодули типа Lidgren.Network, если Вы не знаете, что делаете. В локальном репозитории верхнего уровня эти подмодули считаются "файлами", поэтому их легко случайно отправить на staging и сделать commit с ними. Не делайте этого. О том, как исправить свои ошибки, если это произошло, см. ниже.

== Словарь: Внутренние операции Git ==
В качестве справочного материала здесь приведен небольшой глоссарий понятий и терминов Git, объясняющий их более подробно и в одном месте.

'''Branches''' - это автономные версии кодовой базы, в которые можно добавлять коммиты. По умолчанию используется ветка master, но их можно создавать сколько угодно.
'''Репозитории''' - это папки, в которых с помощью Git можно вносить изменения и отслеживать их. Локальные репозитории - это репозитории, которые находятся у Вас на компьютере, а удаленные репозитории - это репозитории, расположенные на таких сайтах, как GitLab Репозитории состоят из множества веток.
'''Remotes''' - это названия и ссылки на удаленные репозитории, которые может использовать Ваш локальный репозиторий.
'''Подмодули''' - это репозитории, которые находятся внутри другого репозитория.
'''Forks''' - это репозитории, основанные на другом репозитории. Если Вы собираетесь сделать Merge Request для SS14, Вам необходимо сначала сделать Fork.
'''The working tree''' - это все файлы, папки и т.п., находящиеся в репозитории.
'''Staging''' означает добавление (с помощью git add) изменений в 'staging area', где с ними могут быть выполнены некоторые действия
'''Commits''' - это изменения рабочего дерева репозитория в определенный момент времени. По сути, это точка сохранения. Commit - это просто список файлов, которые были изменены с момента последнего коммита, а изменения, которые были commit'нуты, - это изменения, которые Вы отправили в staging area.
'''Checking out''' - это переключение на другой branch, чтобы работать с ним или просматривать его изменения локально.
'''Merging''' - это интеграция изменений из одного branch'а в другой.
Конфликты merge'а" возникают, когда интеграция изменений из одного branch'а в другой не может быть выполнена автоматически, поскольку они оба изменяют одну и ту же область в файле, или их изменения взаимоисключают друг друга каким-либо другим способом.
'''Fetching''' означает получение branch'ей и commit'ов удаленного репозитория, но на самом деле... еще ничего с ними не делая. Они будут просто обновлены, если вы захотите проверить или объединить их позже.
'''Pulling''' - это акт интеграции изменений из branch'а удаленного репозитория в Ваш локальный branch.
Merge Requests" - это действие, позволяющее запросить слияние Вашего локального branch'а и всех его изменений с branch'а другого репозитория.
'''Pushing''' - это действие по интеграции локальных изменений в удаленный репозиторий.

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

Одно замечание, поскольку оно часто встречается здесь: HEAD - это модное название commit'а, на котором Вы сейчас находитесь.
=== Разрешение конфликтов при merge ===
Вредный маленький maintainer сказал вам "разрешить конфликты", иначе ваш MR "не будет merge'нут". Вот ведь сволочь! К счастью, это не так уж сложно.

Сначала нужно обновить главный локальный branch. Как это сделать, см. выше.

Когда Вы выполните команду <code>git merge master [локальный branch]</code>, она либо сделает это без ошибок ("ура"), либо сообщит Вам, что необходимо разрешить конфликты (ужас).

Для разрешения конфликтов вручную достаточно зайти в конфликтующие файлы, удалить всю ерунду типа <code>>>>>HEAD</code> и <code>===== <<<<master</code> (просто указывает, откуда произошли изменения), а затем отредактировать файл так, чтобы он правильно объединял оба набора изменений. Иногда это легко, иногда трудно. Если это сложно, то Вы, вероятно, знаете, что делаете. После этого просто выполните команду <code>git commit</code>.

У Atlassian есть [https://www.atlassian.com/git/tutorials/using-branches/merge-conflicts очень хорошее руководство] по этому вопросу.
=== Проверка истории ===
<code>git log --oneline</code> - это Ваш друг. Он показывает короткие hashe'и commit'ов (уникальные идентификаторы), их сообщения, а также их branch'и и tag'и.

В Fork эта функция встроена в UI:
[[Файл:ForkCommitHistory.png|мини|центр]]
=== Очистка локальных изменений ===
Возможно, Вы случайно внесли ненужные изменения, и Вам не хочется возиться с созданием совершенно новой ветки или еще чего-нибудь, но Вы еще не сделали commit с ними.

<code>git reset --hard HEAD</code>
Это означает "изменить working tree на текущий commit, до внесения любых локальных изменений. Вы не сможете восстановить локальные изменения, если сделаете это, так что будьте осторожны.
=== Откат сделанного Вами commit'а ===
Вот черт, Ваша эротика про ксеноморфа попала в commit или Вы случайно commit'нули подмодуль! Что теперь? Есть решения:

<code>git revert HEAD</code>
Это создаст новый commit, отменяющий текущий commit, и затем commit'нет его. Хе-хе, commit.

Файл:ForkCreateBranchMenuText.png

2023-09-27T21:31:14Z

Ser11y:

ForkCreateBranchMenu

Файл:ForkAddRemoteButton.png

2023-09-27T21:29:04Z

Ser11y:

ForkAddRemoteButton

Файл:ForkCommitHistory.png

2023-09-27T21:25:35Z

Ser11y:

ForkCommitHistory

Файл:ForkPullUpstreamCommandButton.png

2023-09-27T21:24:05Z

Ser11y:

ForkPullUpstreamCommandButton

Файл:ForkPushCommandButton.png

2023-09-27T21:22:58Z

Ser11y:

ForkPushCommandButton

Файл:ForkCommitMenu.png

2023-09-27T21:20:46Z

Ser11y:

ForkCommitMenu

Файл:ForkStashAndCommitMenu.png

2023-09-27T21:17:51Z

Ser11y:

ForkStashAndCommitMenu

Файл:ForkCheckStatusCommand.png

2023-09-27T21:13:18Z

Ser11y:

ForkCheckStatusCommand

Файл:ForkCheckoutBranchButton.png

2023-09-27T21:10:37Z

Ser11y:

ForkCheckoutBranchButton

Файл:ForkCreateBranchMenu.png

2023-09-27T21:06:17Z

Ser11y:

ForkCreateBranchMenu

Файл:ForkCreateBranchButton.png

2023-09-27T21:05:26Z

Ser11y:

ForkCreateBranchButton

Файл:ForkCloneRepositoryButton.png

2023-09-27T21:03:22Z

Ser11y:

ForkCloneRepositoryButton

Git для разработчика SS14

2023-09-27T20:56:16Z

Ser11y: /* Что такое branch? */

== Предисловие ==
В тексте будет часто упоминаться GitLab - аналог GitHub, которым также пользуется Workbench Team. Принципиальной разницы нет, все шаги возможны и на GitHub, но лично мне удобнее работать с GitLab.
Если Вам не ясны какие-либо термины из текста ниже, обратитесь к разделу [[Git_для_разработчика_SS14#Словарь:_Внутренние_операции_Git|Словарь: Внутренние операции Git]].

== Установка Git ==
Для работы с Git для SS14 Вам понадобятся:
* [https://git-scm.com/downloads Git]
** Если Вы хотите использовать Git только в консоли, поставьте галочку при установке:
[[Файл:GitBash.png|мини|центр]]
* [https://www.python.org/downloads/ Python 3.7+]

Если Вы работаете в Linux, то, скорее всего, будете использовать Git через терминал или выбранную Вами IDE, и, возможно, он у Вас уже установлен.

Некоторые IDE имеют в себе интеграцию Git, но этом руководстве будет информация '''только''' об использовании ''приложений'' [[Git для разработчика SS14#Git_Bash|Git Bash]] и [[Git для разработчика SS14#Fork|Fork]].

=== Fork ===
[https://git-fork.com/ Fork] — быстрый и удобный Git-клиент, позволяющий делать всё, что можно в консоли, но удобнее.

== Налаживание репозиториев Git ==
Репозиторий - это просто база кода. Репозитории содержат branch'и, а эти branch'и содержат различные commit'ы. Возможно, Вы слышали об этих двух понятиях - подробнее о них будет рассказано позже.

Удаленный репозиторий - это просто репозиторий на GitLab. Локальный репозиторий - это тот, который находится на Вашем компьютере.
=== Создание Вашего remote репозитория ===
Сперва давайте создадим собственный Fork удаленного репозитория Space Station 14. Для этого, конечно же, потребуется учетная запись GitLab. Forking означает, что Вы копируете всю историю и изменения репозитория в свой собственный удаленный репозиторий, чтобы иметь возможность свободно работать с кодом.

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

Перейдите в наш репозиторий Space Station 14([https://github.com/Workbench-Team/space-station-14 GitHub], [https://git.arumoon.ru/Workbench-Team/space-station-14 GitLab]) и нажмите здесь:
[[Файл:ForksButton.png|мини|центр]]
Затем Вас спросят как назвать Fork - просто назовите его как угодно! Но если Вы хотите просто помочь в разработке, я бы выбрал space-station-14.
=== Создание Вашего локального репозитория ===
Теперь нам нужно загрузить наш удаленный репозиторий на компьютер (клонировать), чтобы мы могли внести в него некоторые изменения. Технически, Вы можете изменять репозиторий удалённо (на GitLab есть неплохие инструменты), но наличие его на Вашем компьютере означает, что Вы используете IDE, такие как Visual Studio или Rider, для сборки игры и запуска тестов, а также легко работаете с Git.

Для каждого шага будут приведены скриншоты и инструкции для Git Bash и Fork для Windows.
===== GitBash: =====
Перейдите в то место на Вашем компьютере, где Вы хотите разместить локальный репозиторий, и:
[[Файл:GitBashHere.png|мини|центр]]
Выберите какой репозиторий клонировать:
[[Файл:GitBashCloneCommand.png|мини|центр]]
Проделайте команду <code>git remote add upstream</code> с <code>https://git.arumoon.ru/Workbench-Team/space-station-14</code>, чтобы у Вас была возможность обновлять свои branch'и новыми обновлениями upstream'а.

=== Подмодули ===
Обратите на это внимание! Если этого не сделать, то при попытке сборки игры вы получите множество странных ошибок о недоступности тех или иных модулей.

В Space Station 14 есть много подмодулей - в первую очередь, движок RobustToolbox. Подмодули - это просто репозитории внутри репозитория, и их нужно обновлять вручную. А нужно ли?

У нас есть автоматическая программа обновления подмодулей, так что Вам не нужно постоянно выполнять <code>git submodule update --init --recursive</code> (команда для ручного обновления подмодулей).

Запустите <code>RUN_THIS.py</code> внутри репозитория, который Вы скачали, с помощью Python. Желательно, из терминала (<code>python RUN_THIS.py</code> или <code>python3 RUN_THIS.py</code>). Это должно занять несколько секунд, так что если все мгновенно прекратится, то, вероятно, Вы не используете [https://www.python.org/downloads/ Python 3.7+] или что-то в этом роде.

Если Вы работаете в Windows и при попытке выполнить приведенную выше команду Вас перенаправляет в Microsoft Store или Вы получаете сообщение в терминале о том, что Python не установлен, необходимо отключить shortcut Microsoft, который может вызывать эту проблему. Это можно сделать, найдя в поиске Windows команду <code>Manage App Execution Aliases</code>, а затем отключив две точки привязки Python.

Если Вы все же хотите модифицировать движок напрямую или обновлять подмодуль вручную (автоматическое обновление иногда доставляет неудобства), создайте файл <code>DISABLE_SUBMODULE_AUTOUPDATE</code> в каталоге <code>BuildChecker/.</code>.

Если по каким-либо причинам, Вам понадобится вручную обновить RobustToolbox, Вы можете использовать <code>cd RobustToolbox; git checkout v0.4.87</code> (замените <code>v0.4.87</code> на последнюю версию RobustToolbox), затем Вы можете использовать <code>cd..\</code>, чтобы вернуться в репозиторий SS14. Это также пример использования cd для навигации по файлам, не выходя из командной строки.
== Branching & Commits (Ветки и коммиты) ==

=== Что такое branch? ===
Branch'и очень и очень важны. По сути, они представляют собой лист изменений в коде (commit'ов). По умолчанию используется branch <code>master</code>.

При работе с кодом Вы всегда находитесь в branch'е, и Вы можете легко менять branch, в котором работаете.

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

Branch'ей можно создавать сколько угодно. Когда Вы создаете branch, он ответвляется от текущего branch'а и становится самостоятельным объектом, в который можно добавлять commit'ы.
[[Файл:BranchDiagram.png|мини|центр|Каждый маленький узел - это отдельный commit, а каждый цвет - отдельный branch.]]
==== Зачем это нужно? ====
Технически, конечно, можно просто делать всю работу в одном branch'е и отправлять Merge Request'ы оттуда. Но создание различных branch'ей позволяет легко понять, где Вы находитесь, сколько изменений внесли, и дает возможность работать над несколькими особенностями(новым содержимым) одновременно.
==== Создание и работа с branch'ами ====
Создавать branch'и довольно просто. Давайте создадим новый branch под названием <code>funny-feature</code>:
===== Git Bash =====
[[Файл:GitBashNewBranchCommand.png|мини|центр]]
Параметр <code>-b</code> в <code>git checkout</code> здесь означает "проверь этот branch, и создай его, если он не существует".

Переключаться между branch'ами довольно просто: это называется проверкой branch'а. При этом локальные файлы и папки будут изменены в соответствии с веткой, поэтому Git будет кричать на Вас, если у Вас есть локальные изменения, а Вы пытаетесь выполнить проверку.

===== Git Bash =====
[[Файл:GitBashCheckoutBranchCommand.png|мини|центр]]
Ну а затем внесите любые локальные изменения! Это не имеет значения. Создайте новый файл, удалите всё, измените одну строку в файле и т.д. Это не повлияет на Ваш главный branch, потому что теперь это территория <code>funny-feature</code>!
==== Совмещение branch'ей ====
Branche'и важны, поскольку их можно объединять. Так происходит интеграция функций в основную ветку. Merge означает "взять особые commit'ы из этого branch'а и применить их к другому branch'у". Вы можете объединить любые два branch'а.

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

GitLab Merge Request - это, по сути, "запрос на объединение": Вы говорите, что хотите объединить commit'ы своего branch'а с другим branch'ом, обычно главным. Подробнее об этом позже.

Merge Request'ы очень хорошо отображают всю эту информацию:
[[Файл:MergeRequestExampleImage.png|мини|центр]]
[[Файл:MergeRequestExampleCommitsImage.png|мини|центр]]

=== Что такое commit? ===
Commit'ы - это просто упакованные изменения в коде. Как разработчик, Вы выбираете, какие изменения войдут в commit и когда их вносить в branch. Commiting - это создание commit'а, который, по сути, является точкой сохранения, к которой можно вернуться в любое время.

Commit'ы имеют автора, временную метку, сообщение и некоторые изменения кода, прикрепленные к ним. Они также имеют очень длинный "commit hash" - уникальный идентификатор, используемый для ссылки на различные коммиты.

Благодаря commit'ам строится история - Вы можете просмотреть историю каждого коммита, сделанного в репозитории SS14 с самого начала, что очень здорово.
==== Отправка commit'ов в branch'и ====
Один важный момент: прежде чем отправлять изменения в commit, необходимо добавить их в область staging'а. Это означает, что Вы указываете, какие файлы хотите добавить в commit. Это полезно, поскольку Вы почти никогда не захотите commit'ить изменения подмодулей, так что Вы просто не добавляете их в область staging'а.

Commit'ы всегда сопровождаются сообщением, которое представляет собой краткое, содержательное описание того, что было сделано в данном commit'е. Или Вы можете быть "Чадом"(страна) и называть каждый коммит "меняет всякое" - на Ваше усмотрение.

Если Вы хотите посмотреть, что Вы изменили в данный момент, а что находится в области staging'а, то это довольно просто:
===== Git Bash =====
[[Файл:GitBashCheckStatusCommand.png|мини|центр]]
Теперь, когда Вы убедились, что все эти изменения выглядят хорошо, мы добавим их в область staging'а и сделаем commit с ними:
[[Файл:GitBashStashAndCommitCommand.png|мини|центр]]

Теперь, когда изменения были добавлены в commit и отправлены в branch, они навсегда (вроде как) остаются в истории branch'а. Теперь мы можем сделать многое: объединить(merge) нашу <code>funny-feature</code> с нашим локальным мастер-branch'ем (если захотим, по какой-то причине), загрузить (push) наш branch <code>funny-feature</code> в наш удалённый репозиторий, или полностью удалить ветку. Мы выберем push и сделаем Merge Request.
== Pushing и создание Merge Request'ов ==
Merge Request означает, что Вы хотите, чтобы кодовая база объединила Ваши изменения в одного из Ваших branch'ей в один из их branch'ей. Прежде чем мы сможем это сделать, наш удаленный репозиторий GitLab (origin) должен знать о красивых branch'ах и commit'ах, которые мы создали локально, поэтому мы push'им эти изменения на удаленный репозиторий.
=== Проталкивание commit'ов ===
Имейте в виду, что при использовании этих команд Git, скорее всего, запросит Ваши учетные данные GitLab, чтобы убедиться в том, что Вы имеете право выполнять push на этот удаленный репозиторий.

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

Push'им наш branch в удалённый репозиторий (origin):
===== Git Bash =====
[[Файл:GitBashPushCommand.png|мини|центр]]
=== Создание Merge Request'ов ===
Весёлая часть. Отправляемся на GitLab и создаём наш Merge Request:
[[Файл:GitLabFunnyFeatureMergeRequestButton.png|мини|центр]]
Добавьте описание, красивое название, несколько скриншотов, и, надеюсь, оно будет merge'нуто.

== Обновление репозитория ==
Возможно, прошло уже много времени, неделя или две, с момента Вашего последнего Merge Request'а, и Вы хотите сделать еще один. Прежде чем что-либо делать, необходимо загрузить (pull) изменения кода из основного репозитория SS14 в свой локальный репозиторий. В противном случае Вы получите устаревший код, а Ваши локальные изменения могут не соответствовать тому, как игра будет работать на самом деле - Вы даже можете получить конфликты слияния при попытке MR.

Существует два способа обновления репозитория. Оба способа предполагают, что Вы правильно настроили доступ к удалённому репозиторию - если это не так, вернитесь к предыдущему пункту руководства.

Первый способ, fetch+merge, дает больше возможностей для контроля, но может быть запутанным. Второй метод, pull, прост и удобен, но не дает большого контроля. Однако, как правило, pull - это все, что вам нужно.
=== Метод pull ===
Pulling означает получение (fetching) новых веток и commit'ов из удаленного репозитория, а затем их слияние с branch'ем. Pulling часто проще, поскольку Git имеет хорошую систему автоматического определения того, из какого удаленного репозитория Вы хотите получить изменения (но она не всегда работает корректно).

Мы будем pull'ить с нашего удалённого репозитория <code>upstream</code> и попросим его объединиться с нашим локальным branch'ем.

Сначала, Вам надо сделать checkout Вашего branch'а. Об этом мы рассказывали ранее. Затем:
===== Git Bash =====
[[Файл:GitBashPullUpstreamCommand.png|мини|центр]]
Делайте это регулярно и всегда до начала работы над новым branch'ем.

== Приложения ==
=== Что следует помнить ===
Вы более или менее изучили рабочий процесс разработки функций для SS14 с точки зрения Git, но вот некоторые вещи, которые я хотел бы вбить Вам в голову:

* При создании новой функциональности всегда создавайте новый branch от главного, прежде чем commit'ить что-либо. Если Вы случайно за-commit'ите изменения физики в branch с велосипедным клаксоном, Вам не поздоровится, но это поправимо.
* Никогда, никогда не фиксируйте RobustToolbox или подмодули типа Lidgren.Network, если Вы не знаете, что делаете. В локальном репозитории верхнего уровня эти подмодули считаются "файлами", поэтому их легко случайно отправить на staging и сделать commit с ними. Не делайте этого. О том, как исправить свои ошибки, если это произошло, см. ниже.

== Словарь: Внутренние операции Git ==
В качестве справочного материала здесь приведен небольшой глоссарий понятий и терминов Git, объясняющий их более подробно и в одном месте.

'''Branches''' - это автономные версии кодовой базы, в которые можно добавлять коммиты. По умолчанию используется ветка master, но их можно создавать сколько угодно.
'''Репозитории''' - это папки, в которых с помощью Git можно вносить изменения и отслеживать их. Локальные репозитории - это репозитории, которые находятся у Вас на компьютере, а удаленные репозитории - это репозитории, расположенные на таких сайтах, как GitLab Репозитории состоят из множества веток.
'''Remotes''' - это названия и ссылки на удаленные репозитории, которые может использовать Ваш локальный репозиторий.
'''Подмодули''' - это репозитории, которые находятся внутри другого репозитория.
'''Forks''' - это репозитории, основанные на другом репозитории. Если Вы собираетесь сделать Merge Request для SS14, Вам необходимо сначала сделать Fork.
'''The working tree''' - это все файлы, папки и т.п., находящиеся в репозитории.
'''Staging''' означает добавление (с помощью git add) изменений в 'staging area', где с ними могут быть выполнены некоторые действия
'''Commits''' - это изменения рабочего дерева репозитория в определенный момент времени. По сути, это точка сохранения. Commit - это просто список файлов, которые были изменены с момента последнего коммита, а изменения, которые были commit'нуты, - это изменения, которые Вы отправили в staging area.
'''Checking out''' - это переключение на другой branch, чтобы работать с ним или просматривать его изменения локально.
'''Merging''' - это интеграция изменений из одного branch'а в другой.
Конфликты merge'а" возникают, когда интеграция изменений из одного branch'а в другой не может быть выполнена автоматически, поскольку они оба изменяют одну и ту же область в файле, или их изменения взаимоисключают друг друга каким-либо другим способом.
'''Fetching''' означает получение branch'ей и commit'ов удаленного репозитория, но на самом деле... еще ничего с ними не делая. Они будут просто обновлены, если вы захотите проверить или объединить их позже.
'''Pulling''' - это акт интеграции изменений из branch'а удаленного репозитория в Ваш локальный branch.
Merge Requests" - это действие, позволяющее запросить слияние Вашего локального branch'а и всех его изменений с branch'а другого репозитория.
'''Pushing''' - это действие по интеграции локальных изменений в удаленный репозиторий.

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

Одно замечание, поскольку оно часто встречается здесь: HEAD - это модное название commit'а, на котором Вы сейчас находитесь.
=== Разрешение конфликтов при merge ===
Вредный маленький maintainer сказал вам "разрешить конфликты", иначе ваш MR "не будет merge'нут". Вот ведь сволочь! К счастью, это не так уж сложно.

Сначала нужно обновить главный локальный branch. Как это сделать, см. выше.

Когда Вы выполните команду <code>git merge master [локальный branch]</code>, она либо сделает это без ошибок ("ура"), либо сообщит Вам, что необходимо разрешить конфликты (ужас).

Для разрешения конфликтов вручную достаточно зайти в конфликтующие файлы, удалить всю ерунду типа <code>>>>>HEAD</code> и <code>===== <<<<master</code> (просто указывает, откуда произошли изменения), а затем отредактировать файл так, чтобы он правильно объединял оба набора изменений. Иногда это легко, иногда трудно. Если это сложно, то Вы, вероятно, знаете, что делаете. После этого просто выполните команду <code>git commit</code>.

У Atlassian есть [https://www.atlassian.com/git/tutorials/using-branches/merge-conflicts очень хорошее руководство] по этому вопросу.
=== Проверка истории ===
<code>git log --oneline</code> - это Ваш друг. Он показывает короткие hashe'и commit'ов (уникальные идентификаторы), их сообщения, а также их branch'и и tag'и.
=== Очистка локальных изменений ===
Возможно, Вы случайно внесли ненужные изменения, и Вам не хочется возиться с созданием совершенно новой ветки или еще чего-нибудь, но Вы еще не сделали commit с ними.

<code>git reset --hard HEAD</code>
Это означает "изменить working tree на текущий commit, до внесения любых локальных изменений. Вы не сможете восстановить локальные изменения, если сделаете это, так что будьте осторожны.
=== Откат сделанного Вами commit'а ===
Вот черт, Ваша эротика про ксеноморфа попала в commit или Вы случайно commit'нули подмодуль! Что теперь? Есть решения:

<code>git revert HEAD</code>
Это создаст новый commit, отменяющий текущий commit, и затем commit'нет его. Хе-хе, commit.

Git для разработчика SS14

2023-09-27T20:56:01Z

Ser11y: /* Что такое branch? */

== Предисловие ==
В тексте будет часто упоминаться GitLab - аналог GitHub, которым также пользуется Workbench Team. Принципиальной разницы нет, все шаги возможны и на GitHub, но лично мне удобнее работать с GitLab.
Если Вам не ясны какие-либо термины из текста ниже, обратитесь к разделу [[Git_для_разработчика_SS14#Словарь:_Внутренние_операции_Git|Словарь: Внутренние операции Git]].

== Установка Git ==
Для работы с Git для SS14 Вам понадобятся:
* [https://git-scm.com/downloads Git]
** Если Вы хотите использовать Git только в консоли, поставьте галочку при установке:
[[Файл:GitBash.png|мини|центр]]
* [https://www.python.org/downloads/ Python 3.7+]

Если Вы работаете в Linux, то, скорее всего, будете использовать Git через терминал или выбранную Вами IDE, и, возможно, он у Вас уже установлен.

Некоторые IDE имеют в себе интеграцию Git, но этом руководстве будет информация '''только''' об использовании ''приложений'' [[Git для разработчика SS14#Git_Bash|Git Bash]] и [[Git для разработчика SS14#Fork|Fork]].

=== Fork ===
[https://git-fork.com/ Fork] — быстрый и удобный Git-клиент, позволяющий делать всё, что можно в консоли, но удобнее.

== Налаживание репозиториев Git ==
Репозиторий - это просто база кода. Репозитории содержат branch'и, а эти branch'и содержат различные commit'ы. Возможно, Вы слышали об этих двух понятиях - подробнее о них будет рассказано позже.

Удаленный репозиторий - это просто репозиторий на GitLab. Локальный репозиторий - это тот, который находится на Вашем компьютере.
=== Создание Вашего remote репозитория ===
Сперва давайте создадим собственный Fork удаленного репозитория Space Station 14. Для этого, конечно же, потребуется учетная запись GitLab. Forking означает, что Вы копируете всю историю и изменения репозитория в свой собственный удаленный репозиторий, чтобы иметь возможность свободно работать с кодом.

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

Перейдите в наш репозиторий Space Station 14([https://github.com/Workbench-Team/space-station-14 GitHub], [https://git.arumoon.ru/Workbench-Team/space-station-14 GitLab]) и нажмите здесь:
[[Файл:ForksButton.png|мини|центр]]
Затем Вас спросят как назвать Fork - просто назовите его как угодно! Но если Вы хотите просто помочь в разработке, я бы выбрал space-station-14.
=== Создание Вашего локального репозитория ===
Теперь нам нужно загрузить наш удаленный репозиторий на компьютер (клонировать), чтобы мы могли внести в него некоторые изменения. Технически, Вы можете изменять репозиторий удалённо (на GitLab есть неплохие инструменты), но наличие его на Вашем компьютере означает, что Вы используете IDE, такие как Visual Studio или Rider, для сборки игры и запуска тестов, а также легко работаете с Git.

Для каждого шага будут приведены скриншоты и инструкции для Git Bash и Fork для Windows.
===== GitBash: =====
Перейдите в то место на Вашем компьютере, где Вы хотите разместить локальный репозиторий, и:
[[Файл:GitBashHere.png|мини|центр]]
Выберите какой репозиторий клонировать:
[[Файл:GitBashCloneCommand.png|мини|центр]]
Проделайте команду <code>git remote add upstream</code> с <code>https://git.arumoon.ru/Workbench-Team/space-station-14</code>, чтобы у Вас была возможность обновлять свои branch'и новыми обновлениями upstream'а.

=== Подмодули ===
Обратите на это внимание! Если этого не сделать, то при попытке сборки игры вы получите множество странных ошибок о недоступности тех или иных модулей.

В Space Station 14 есть много подмодулей - в первую очередь, движок RobustToolbox. Подмодули - это просто репозитории внутри репозитория, и их нужно обновлять вручную. А нужно ли?

У нас есть автоматическая программа обновления подмодулей, так что Вам не нужно постоянно выполнять <code>git submodule update --init --recursive</code> (команда для ручного обновления подмодулей).

Запустите <code>RUN_THIS.py</code> внутри репозитория, который Вы скачали, с помощью Python. Желательно, из терминала (<code>python RUN_THIS.py</code> или <code>python3 RUN_THIS.py</code>). Это должно занять несколько секунд, так что если все мгновенно прекратится, то, вероятно, Вы не используете [https://www.python.org/downloads/ Python 3.7+] или что-то в этом роде.

Если Вы работаете в Windows и при попытке выполнить приведенную выше команду Вас перенаправляет в Microsoft Store или Вы получаете сообщение в терминале о том, что Python не установлен, необходимо отключить shortcut Microsoft, который может вызывать эту проблему. Это можно сделать, найдя в поиске Windows команду <code>Manage App Execution Aliases</code>, а затем отключив две точки привязки Python.

Если Вы все же хотите модифицировать движок напрямую или обновлять подмодуль вручную (автоматическое обновление иногда доставляет неудобства), создайте файл <code>DISABLE_SUBMODULE_AUTOUPDATE</code> в каталоге <code>BuildChecker/.</code>.

Если по каким-либо причинам, Вам понадобится вручную обновить RobustToolbox, Вы можете использовать <code>cd RobustToolbox; git checkout v0.4.87</code> (замените <code>v0.4.87</code> на последнюю версию RobustToolbox), затем Вы можете использовать <code>cd..\</code>, чтобы вернуться в репозиторий SS14. Это также пример использования cd для навигации по файлам, не выходя из командной строки.
== Branching & Commits (Ветки и коммиты) ==

=== Что такое branch? ===
Branch'и очень и очень важны. По сути, они представляют собой лист изменений в коде (commit'ов). По умолчанию используется branch <code>master</code>.

При работе с кодом Вы всегда находитесь в branch'е, и Вы можете легко менять branch, в котором работаете.

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

Branch'ей можно создавать сколько угодно. Когда Вы создаете branch, он ответвляется от текущего branch'а и становится самостоятельным объектом, в который можно добавлять commit'ы.
[[Файл:BranchDiagram.png|центр|Каждый маленький узел - это отдельный commit, а каждый цвет - отдельный branch.]]
==== Зачем это нужно? ====
Технически, конечно, можно просто делать всю работу в одном branch'е и отправлять Merge Request'ы оттуда. Но создание различных branch'ей позволяет легко понять, где Вы находитесь, сколько изменений внесли, и дает возможность работать над несколькими особенностями(новым содержимым) одновременно.
==== Создание и работа с branch'ами ====
Создавать branch'и довольно просто. Давайте создадим новый branch под названием <code>funny-feature</code>:
===== Git Bash =====
[[Файл:GitBashNewBranchCommand.png|мини|центр]]
Параметр <code>-b</code> в <code>git checkout</code> здесь означает "проверь этот branch, и создай его, если он не существует".

Переключаться между branch'ами довольно просто: это называется проверкой branch'а. При этом локальные файлы и папки будут изменены в соответствии с веткой, поэтому Git будет кричать на Вас, если у Вас есть локальные изменения, а Вы пытаетесь выполнить проверку.

===== Git Bash =====
[[Файл:GitBashCheckoutBranchCommand.png|мини|центр]]
Ну а затем внесите любые локальные изменения! Это не имеет значения. Создайте новый файл, удалите всё, измените одну строку в файле и т.д. Это не повлияет на Ваш главный branch, потому что теперь это территория <code>funny-feature</code>!
==== Совмещение branch'ей ====
Branche'и важны, поскольку их можно объединять. Так происходит интеграция функций в основную ветку. Merge означает "взять особые commit'ы из этого branch'а и применить их к другому branch'у". Вы можете объединить любые два branch'а.

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

GitLab Merge Request - это, по сути, "запрос на объединение": Вы говорите, что хотите объединить commit'ы своего branch'а с другим branch'ом, обычно главным. Подробнее об этом позже.

Merge Request'ы очень хорошо отображают всю эту информацию:
[[Файл:MergeRequestExampleImage.png|мини|центр]]
[[Файл:MergeRequestExampleCommitsImage.png|мини|центр]]

=== Что такое commit? ===
Commit'ы - это просто упакованные изменения в коде. Как разработчик, Вы выбираете, какие изменения войдут в commit и когда их вносить в branch. Commiting - это создание commit'а, который, по сути, является точкой сохранения, к которой можно вернуться в любое время.

Commit'ы имеют автора, временную метку, сообщение и некоторые изменения кода, прикрепленные к ним. Они также имеют очень длинный "commit hash" - уникальный идентификатор, используемый для ссылки на различные коммиты.

Благодаря commit'ам строится история - Вы можете просмотреть историю каждого коммита, сделанного в репозитории SS14 с самого начала, что очень здорово.
==== Отправка commit'ов в branch'и ====
Один важный момент: прежде чем отправлять изменения в commit, необходимо добавить их в область staging'а. Это означает, что Вы указываете, какие файлы хотите добавить в commit. Это полезно, поскольку Вы почти никогда не захотите commit'ить изменения подмодулей, так что Вы просто не добавляете их в область staging'а.

Commit'ы всегда сопровождаются сообщением, которое представляет собой краткое, содержательное описание того, что было сделано в данном commit'е. Или Вы можете быть "Чадом"(страна) и называть каждый коммит "меняет всякое" - на Ваше усмотрение.

Если Вы хотите посмотреть, что Вы изменили в данный момент, а что находится в области staging'а, то это довольно просто:
===== Git Bash =====
[[Файл:GitBashCheckStatusCommand.png|мини|центр]]
Теперь, когда Вы убедились, что все эти изменения выглядят хорошо, мы добавим их в область staging'а и сделаем commit с ними:
[[Файл:GitBashStashAndCommitCommand.png|мини|центр]]

Теперь, когда изменения были добавлены в commit и отправлены в branch, они навсегда (вроде как) остаются в истории branch'а. Теперь мы можем сделать многое: объединить(merge) нашу <code>funny-feature</code> с нашим локальным мастер-branch'ем (если захотим, по какой-то причине), загрузить (push) наш branch <code>funny-feature</code> в наш удалённый репозиторий, или полностью удалить ветку. Мы выберем push и сделаем Merge Request.
== Pushing и создание Merge Request'ов ==
Merge Request означает, что Вы хотите, чтобы кодовая база объединила Ваши изменения в одного из Ваших branch'ей в один из их branch'ей. Прежде чем мы сможем это сделать, наш удаленный репозиторий GitLab (origin) должен знать о красивых branch'ах и commit'ах, которые мы создали локально, поэтому мы push'им эти изменения на удаленный репозиторий.
=== Проталкивание commit'ов ===
Имейте в виду, что при использовании этих команд Git, скорее всего, запросит Ваши учетные данные GitLab, чтобы убедиться в том, что Вы имеете право выполнять push на этот удаленный репозиторий.

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

Push'им наш branch в удалённый репозиторий (origin):
===== Git Bash =====
[[Файл:GitBashPushCommand.png|мини|центр]]
=== Создание Merge Request'ов ===
Весёлая часть. Отправляемся на GitLab и создаём наш Merge Request:
[[Файл:GitLabFunnyFeatureMergeRequestButton.png|мини|центр]]
Добавьте описание, красивое название, несколько скриншотов, и, надеюсь, оно будет merge'нуто.

== Обновление репозитория ==
Возможно, прошло уже много времени, неделя или две, с момента Вашего последнего Merge Request'а, и Вы хотите сделать еще один. Прежде чем что-либо делать, необходимо загрузить (pull) изменения кода из основного репозитория SS14 в свой локальный репозиторий. В противном случае Вы получите устаревший код, а Ваши локальные изменения могут не соответствовать тому, как игра будет работать на самом деле - Вы даже можете получить конфликты слияния при попытке MR.

Существует два способа обновления репозитория. Оба способа предполагают, что Вы правильно настроили доступ к удалённому репозиторию - если это не так, вернитесь к предыдущему пункту руководства.

Первый способ, fetch+merge, дает больше возможностей для контроля, но может быть запутанным. Второй метод, pull, прост и удобен, но не дает большого контроля. Однако, как правило, pull - это все, что вам нужно.
=== Метод pull ===
Pulling означает получение (fetching) новых веток и commit'ов из удаленного репозитория, а затем их слияние с branch'ем. Pulling часто проще, поскольку Git имеет хорошую систему автоматического определения того, из какого удаленного репозитория Вы хотите получить изменения (но она не всегда работает корректно).

Мы будем pull'ить с нашего удалённого репозитория <code>upstream</code> и попросим его объединиться с нашим локальным branch'ем.

Сначала, Вам надо сделать checkout Вашего branch'а. Об этом мы рассказывали ранее. Затем:
===== Git Bash =====
[[Файл:GitBashPullUpstreamCommand.png|мини|центр]]
Делайте это регулярно и всегда до начала работы над новым branch'ем.

== Приложения ==
=== Что следует помнить ===
Вы более или менее изучили рабочий процесс разработки функций для SS14 с точки зрения Git, но вот некоторые вещи, которые я хотел бы вбить Вам в голову:

* При создании новой функциональности всегда создавайте новый branch от главного, прежде чем commit'ить что-либо. Если Вы случайно за-commit'ите изменения физики в branch с велосипедным клаксоном, Вам не поздоровится, но это поправимо.
* Никогда, никогда не фиксируйте RobustToolbox или подмодули типа Lidgren.Network, если Вы не знаете, что делаете. В локальном репозитории верхнего уровня эти подмодули считаются "файлами", поэтому их легко случайно отправить на staging и сделать commit с ними. Не делайте этого. О том, как исправить свои ошибки, если это произошло, см. ниже.

== Словарь: Внутренние операции Git ==
В качестве справочного материала здесь приведен небольшой глоссарий понятий и терминов Git, объясняющий их более подробно и в одном месте.

'''Branches''' - это автономные версии кодовой базы, в которые можно добавлять коммиты. По умолчанию используется ветка master, но их можно создавать сколько угодно.
'''Репозитории''' - это папки, в которых с помощью Git можно вносить изменения и отслеживать их. Локальные репозитории - это репозитории, которые находятся у Вас на компьютере, а удаленные репозитории - это репозитории, расположенные на таких сайтах, как GitLab Репозитории состоят из множества веток.
'''Remotes''' - это названия и ссылки на удаленные репозитории, которые может использовать Ваш локальный репозиторий.
'''Подмодули''' - это репозитории, которые находятся внутри другого репозитория.
'''Forks''' - это репозитории, основанные на другом репозитории. Если Вы собираетесь сделать Merge Request для SS14, Вам необходимо сначала сделать Fork.
'''The working tree''' - это все файлы, папки и т.п., находящиеся в репозитории.
'''Staging''' означает добавление (с помощью git add) изменений в 'staging area', где с ними могут быть выполнены некоторые действия
'''Commits''' - это изменения рабочего дерева репозитория в определенный момент времени. По сути, это точка сохранения. Commit - это просто список файлов, которые были изменены с момента последнего коммита, а изменения, которые были commit'нуты, - это изменения, которые Вы отправили в staging area.
'''Checking out''' - это переключение на другой branch, чтобы работать с ним или просматривать его изменения локально.
'''Merging''' - это интеграция изменений из одного branch'а в другой.
Конфликты merge'а" возникают, когда интеграция изменений из одного branch'а в другой не может быть выполнена автоматически, поскольку они оба изменяют одну и ту же область в файле, или их изменения взаимоисключают друг друга каким-либо другим способом.
'''Fetching''' означает получение branch'ей и commit'ов удаленного репозитория, но на самом деле... еще ничего с ними не делая. Они будут просто обновлены, если вы захотите проверить или объединить их позже.
'''Pulling''' - это акт интеграции изменений из branch'а удаленного репозитория в Ваш локальный branch.
Merge Requests" - это действие, позволяющее запросить слияние Вашего локального branch'а и всех его изменений с branch'а другого репозитория.
'''Pushing''' - это действие по интеграции локальных изменений в удаленный репозиторий.

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

Одно замечание, поскольку оно часто встречается здесь: HEAD - это модное название commit'а, на котором Вы сейчас находитесь.
=== Разрешение конфликтов при merge ===
Вредный маленький maintainer сказал вам "разрешить конфликты", иначе ваш MR "не будет merge'нут". Вот ведь сволочь! К счастью, это не так уж сложно.

Сначала нужно обновить главный локальный branch. Как это сделать, см. выше.

Когда Вы выполните команду <code>git merge master [локальный branch]</code>, она либо сделает это без ошибок ("ура"), либо сообщит Вам, что необходимо разрешить конфликты (ужас).

Для разрешения конфликтов вручную достаточно зайти в конфликтующие файлы, удалить всю ерунду типа <code>>>>>HEAD</code> и <code>===== <<<<master</code> (просто указывает, откуда произошли изменения), а затем отредактировать файл так, чтобы он правильно объединял оба набора изменений. Иногда это легко, иногда трудно. Если это сложно, то Вы, вероятно, знаете, что делаете. После этого просто выполните команду <code>git commit</code>.

У Atlassian есть [https://www.atlassian.com/git/tutorials/using-branches/merge-conflicts очень хорошее руководство] по этому вопросу.
=== Проверка истории ===
<code>git log --oneline</code> - это Ваш друг. Он показывает короткие hashe'и commit'ов (уникальные идентификаторы), их сообщения, а также их branch'и и tag'и.
=== Очистка локальных изменений ===
Возможно, Вы случайно внесли ненужные изменения, и Вам не хочется возиться с созданием совершенно новой ветки или еще чего-нибудь, но Вы еще не сделали commit с ними.

<code>git reset --hard HEAD</code>
Это означает "изменить working tree на текущий commit, до внесения любых локальных изменений. Вы не сможете восстановить локальные изменения, если сделаете это, так что будьте осторожны.
=== Откат сделанного Вами commit'а ===
Вот черт, Ваша эротика про ксеноморфа попала в commit или Вы случайно commit'нули подмодуль! Что теперь? Есть решения:

<code>git revert HEAD</code>
Это создаст новый commit, отменяющий текущий commit, и затем commit'нет его. Хе-хе, commit.

Git для разработчика SS14

2023-09-27T20:55:35Z

Ser11y: /* Что такое branch? */

== Предисловие ==
В тексте будет часто упоминаться GitLab - аналог GitHub, которым также пользуется Workbench Team. Принципиальной разницы нет, все шаги возможны и на GitHub, но лично мне удобнее работать с GitLab.
Если Вам не ясны какие-либо термины из текста ниже, обратитесь к разделу [[Git_для_разработчика_SS14#Словарь:_Внутренние_операции_Git|Словарь: Внутренние операции Git]].

== Установка Git ==
Для работы с Git для SS14 Вам понадобятся:
* [https://git-scm.com/downloads Git]
** Если Вы хотите использовать Git только в консоли, поставьте галочку при установке:
[[Файл:GitBash.png|мини|центр]]
* [https://www.python.org/downloads/ Python 3.7+]

Если Вы работаете в Linux, то, скорее всего, будете использовать Git через терминал или выбранную Вами IDE, и, возможно, он у Вас уже установлен.

Некоторые IDE имеют в себе интеграцию Git, но этом руководстве будет информация '''только''' об использовании ''приложений'' [[Git для разработчика SS14#Git_Bash|Git Bash]] и [[Git для разработчика SS14#Fork|Fork]].

=== Fork ===
[https://git-fork.com/ Fork] — быстрый и удобный Git-клиент, позволяющий делать всё, что можно в консоли, но удобнее.

== Налаживание репозиториев Git ==
Репозиторий - это просто база кода. Репозитории содержат branch'и, а эти branch'и содержат различные commit'ы. Возможно, Вы слышали об этих двух понятиях - подробнее о них будет рассказано позже.

Удаленный репозиторий - это просто репозиторий на GitLab. Локальный репозиторий - это тот, который находится на Вашем компьютере.
=== Создание Вашего remote репозитория ===
Сперва давайте создадим собственный Fork удаленного репозитория Space Station 14. Для этого, конечно же, потребуется учетная запись GitLab. Forking означает, что Вы копируете всю историю и изменения репозитория в свой собственный удаленный репозиторий, чтобы иметь возможность свободно работать с кодом.

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

Перейдите в наш репозиторий Space Station 14([https://github.com/Workbench-Team/space-station-14 GitHub], [https://git.arumoon.ru/Workbench-Team/space-station-14 GitLab]) и нажмите здесь:
[[Файл:ForksButton.png|мини|центр]]
Затем Вас спросят как назвать Fork - просто назовите его как угодно! Но если Вы хотите просто помочь в разработке, я бы выбрал space-station-14.
=== Создание Вашего локального репозитория ===
Теперь нам нужно загрузить наш удаленный репозиторий на компьютер (клонировать), чтобы мы могли внести в него некоторые изменения. Технически, Вы можете изменять репозиторий удалённо (на GitLab есть неплохие инструменты), но наличие его на Вашем компьютере означает, что Вы используете IDE, такие как Visual Studio или Rider, для сборки игры и запуска тестов, а также легко работаете с Git.

Для каждого шага будут приведены скриншоты и инструкции для Git Bash и Fork для Windows.
===== GitBash: =====
Перейдите в то место на Вашем компьютере, где Вы хотите разместить локальный репозиторий, и:
[[Файл:GitBashHere.png|мини|центр]]
Выберите какой репозиторий клонировать:
[[Файл:GitBashCloneCommand.png|мини|центр]]
Проделайте команду <code>git remote add upstream</code> с <code>https://git.arumoon.ru/Workbench-Team/space-station-14</code>, чтобы у Вас была возможность обновлять свои branch'и новыми обновлениями upstream'а.

=== Подмодули ===
Обратите на это внимание! Если этого не сделать, то при попытке сборки игры вы получите множество странных ошибок о недоступности тех или иных модулей.

В Space Station 14 есть много подмодулей - в первую очередь, движок RobustToolbox. Подмодули - это просто репозитории внутри репозитория, и их нужно обновлять вручную. А нужно ли?

У нас есть автоматическая программа обновления подмодулей, так что Вам не нужно постоянно выполнять <code>git submodule update --init --recursive</code> (команда для ручного обновления подмодулей).

Запустите <code>RUN_THIS.py</code> внутри репозитория, который Вы скачали, с помощью Python. Желательно, из терминала (<code>python RUN_THIS.py</code> или <code>python3 RUN_THIS.py</code>). Это должно занять несколько секунд, так что если все мгновенно прекратится, то, вероятно, Вы не используете [https://www.python.org/downloads/ Python 3.7+] или что-то в этом роде.

Если Вы работаете в Windows и при попытке выполнить приведенную выше команду Вас перенаправляет в Microsoft Store или Вы получаете сообщение в терминале о том, что Python не установлен, необходимо отключить shortcut Microsoft, который может вызывать эту проблему. Это можно сделать, найдя в поиске Windows команду <code>Manage App Execution Aliases</code>, а затем отключив две точки привязки Python.

Если Вы все же хотите модифицировать движок напрямую или обновлять подмодуль вручную (автоматическое обновление иногда доставляет неудобства), создайте файл <code>DISABLE_SUBMODULE_AUTOUPDATE</code> в каталоге <code>BuildChecker/.</code>.

Если по каким-либо причинам, Вам понадобится вручную обновить RobustToolbox, Вы можете использовать <code>cd RobustToolbox; git checkout v0.4.87</code> (замените <code>v0.4.87</code> на последнюю версию RobustToolbox), затем Вы можете использовать <code>cd..\</code>, чтобы вернуться в репозиторий SS14. Это также пример использования cd для навигации по файлам, не выходя из командной строки.
== Branching & Commits (Ветки и коммиты) ==

=== Что такое branch? ===
Branch'и очень и очень важны. По сути, они представляют собой лист изменений в коде (commit'ов). По умолчанию используется branch <code>master</code>.

При работе с кодом Вы всегда находитесь в branch'е, и Вы можете легко менять branch, в котором работаете.

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

Branch'ей можно создавать сколько угодно. Когда Вы создаете branch, он ответвляется от текущего branch'а и становится самостоятельным объектом, в который можно добавлять commit'ы.
[[Файл:BranchDiagram.png|мини|центр|Каждый маленький узел - это отдельный commit, а каждый цвет - отдельный branch.]]
==== Зачем это нужно? ====
Технически, конечно, можно просто делать всю работу в одном branch'е и отправлять Merge Request'ы оттуда. Но создание различных branch'ей позволяет легко понять, где Вы находитесь, сколько изменений внесли, и дает возможность работать над несколькими особенностями(новым содержимым) одновременно.
==== Создание и работа с branch'ами ====
Создавать branch'и довольно просто. Давайте создадим новый branch под названием <code>funny-feature</code>:
===== Git Bash =====
[[Файл:GitBashNewBranchCommand.png|мини|центр]]
Параметр <code>-b</code> в <code>git checkout</code> здесь означает "проверь этот branch, и создай его, если он не существует".

Переключаться между branch'ами довольно просто: это называется проверкой branch'а. При этом локальные файлы и папки будут изменены в соответствии с веткой, поэтому Git будет кричать на Вас, если у Вас есть локальные изменения, а Вы пытаетесь выполнить проверку.

===== Git Bash =====
[[Файл:GitBashCheckoutBranchCommand.png|мини|центр]]
Ну а затем внесите любые локальные изменения! Это не имеет значения. Создайте новый файл, удалите всё, измените одну строку в файле и т.д. Это не повлияет на Ваш главный branch, потому что теперь это территория <code>funny-feature</code>!
==== Совмещение branch'ей ====
Branche'и важны, поскольку их можно объединять. Так происходит интеграция функций в основную ветку. Merge означает "взять особые commit'ы из этого branch'а и применить их к другому branch'у". Вы можете объединить любые два branch'а.

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

GitLab Merge Request - это, по сути, "запрос на объединение": Вы говорите, что хотите объединить commit'ы своего branch'а с другим branch'ом, обычно главным. Подробнее об этом позже.

Merge Request'ы очень хорошо отображают всю эту информацию:
[[Файл:MergeRequestExampleImage.png|мини|центр]]
[[Файл:MergeRequestExampleCommitsImage.png|мини|центр]]

=== Что такое commit? ===
Commit'ы - это просто упакованные изменения в коде. Как разработчик, Вы выбираете, какие изменения войдут в commit и когда их вносить в branch. Commiting - это создание commit'а, который, по сути, является точкой сохранения, к которой можно вернуться в любое время.

Commit'ы имеют автора, временную метку, сообщение и некоторые изменения кода, прикрепленные к ним. Они также имеют очень длинный "commit hash" - уникальный идентификатор, используемый для ссылки на различные коммиты.

Благодаря commit'ам строится история - Вы можете просмотреть историю каждого коммита, сделанного в репозитории SS14 с самого начала, что очень здорово.
==== Отправка commit'ов в branch'и ====
Один важный момент: прежде чем отправлять изменения в commit, необходимо добавить их в область staging'а. Это означает, что Вы указываете, какие файлы хотите добавить в commit. Это полезно, поскольку Вы почти никогда не захотите commit'ить изменения подмодулей, так что Вы просто не добавляете их в область staging'а.

Commit'ы всегда сопровождаются сообщением, которое представляет собой краткое, содержательное описание того, что было сделано в данном commit'е. Или Вы можете быть "Чадом"(страна) и называть каждый коммит "меняет всякое" - на Ваше усмотрение.

Если Вы хотите посмотреть, что Вы изменили в данный момент, а что находится в области staging'а, то это довольно просто:
===== Git Bash =====
[[Файл:GitBashCheckStatusCommand.png|мини|центр]]
Теперь, когда Вы убедились, что все эти изменения выглядят хорошо, мы добавим их в область staging'а и сделаем commit с ними:
[[Файл:GitBashStashAndCommitCommand.png|мини|центр]]

Теперь, когда изменения были добавлены в commit и отправлены в branch, они навсегда (вроде как) остаются в истории branch'а. Теперь мы можем сделать многое: объединить(merge) нашу <code>funny-feature</code> с нашим локальным мастер-branch'ем (если захотим, по какой-то причине), загрузить (push) наш branch <code>funny-feature</code> в наш удалённый репозиторий, или полностью удалить ветку. Мы выберем push и сделаем Merge Request.
== Pushing и создание Merge Request'ов ==
Merge Request означает, что Вы хотите, чтобы кодовая база объединила Ваши изменения в одного из Ваших branch'ей в один из их branch'ей. Прежде чем мы сможем это сделать, наш удаленный репозиторий GitLab (origin) должен знать о красивых branch'ах и commit'ах, которые мы создали локально, поэтому мы push'им эти изменения на удаленный репозиторий.
=== Проталкивание commit'ов ===
Имейте в виду, что при использовании этих команд Git, скорее всего, запросит Ваши учетные данные GitLab, чтобы убедиться в том, что Вы имеете право выполнять push на этот удаленный репозиторий.

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

Push'им наш branch в удалённый репозиторий (origin):
===== Git Bash =====
[[Файл:GitBashPushCommand.png|мини|центр]]
=== Создание Merge Request'ов ===
Весёлая часть. Отправляемся на GitLab и создаём наш Merge Request:
[[Файл:GitLabFunnyFeatureMergeRequestButton.png|мини|центр]]
Добавьте описание, красивое название, несколько скриншотов, и, надеюсь, оно будет merge'нуто.

== Обновление репозитория ==
Возможно, прошло уже много времени, неделя или две, с момента Вашего последнего Merge Request'а, и Вы хотите сделать еще один. Прежде чем что-либо делать, необходимо загрузить (pull) изменения кода из основного репозитория SS14 в свой локальный репозиторий. В противном случае Вы получите устаревший код, а Ваши локальные изменения могут не соответствовать тому, как игра будет работать на самом деле - Вы даже можете получить конфликты слияния при попытке MR.

Существует два способа обновления репозитория. Оба способа предполагают, что Вы правильно настроили доступ к удалённому репозиторию - если это не так, вернитесь к предыдущему пункту руководства.

Первый способ, fetch+merge, дает больше возможностей для контроля, но может быть запутанным. Второй метод, pull, прост и удобен, но не дает большого контроля. Однако, как правило, pull - это все, что вам нужно.
=== Метод pull ===
Pulling означает получение (fetching) новых веток и commit'ов из удаленного репозитория, а затем их слияние с branch'ем. Pulling часто проще, поскольку Git имеет хорошую систему автоматического определения того, из какого удаленного репозитория Вы хотите получить изменения (но она не всегда работает корректно).

Мы будем pull'ить с нашего удалённого репозитория <code>upstream</code> и попросим его объединиться с нашим локальным branch'ем.

Сначала, Вам надо сделать checkout Вашего branch'а. Об этом мы рассказывали ранее. Затем:
===== Git Bash =====
[[Файл:GitBashPullUpstreamCommand.png|мини|центр]]
Делайте это регулярно и всегда до начала работы над новым branch'ем.

== Приложения ==
=== Что следует помнить ===
Вы более или менее изучили рабочий процесс разработки функций для SS14 с точки зрения Git, но вот некоторые вещи, которые я хотел бы вбить Вам в голову:

* При создании новой функциональности всегда создавайте новый branch от главного, прежде чем commit'ить что-либо. Если Вы случайно за-commit'ите изменения физики в branch с велосипедным клаксоном, Вам не поздоровится, но это поправимо.
* Никогда, никогда не фиксируйте RobustToolbox или подмодули типа Lidgren.Network, если Вы не знаете, что делаете. В локальном репозитории верхнего уровня эти подмодули считаются "файлами", поэтому их легко случайно отправить на staging и сделать commit с ними. Не делайте этого. О том, как исправить свои ошибки, если это произошло, см. ниже.

== Словарь: Внутренние операции Git ==
В качестве справочного материала здесь приведен небольшой глоссарий понятий и терминов Git, объясняющий их более подробно и в одном месте.

'''Branches''' - это автономные версии кодовой базы, в которые можно добавлять коммиты. По умолчанию используется ветка master, но их можно создавать сколько угодно.
'''Репозитории''' - это папки, в которых с помощью Git можно вносить изменения и отслеживать их. Локальные репозитории - это репозитории, которые находятся у Вас на компьютере, а удаленные репозитории - это репозитории, расположенные на таких сайтах, как GitLab Репозитории состоят из множества веток.
'''Remotes''' - это названия и ссылки на удаленные репозитории, которые может использовать Ваш локальный репозиторий.
'''Подмодули''' - это репозитории, которые находятся внутри другого репозитория.
'''Forks''' - это репозитории, основанные на другом репозитории. Если Вы собираетесь сделать Merge Request для SS14, Вам необходимо сначала сделать Fork.
'''The working tree''' - это все файлы, папки и т.п., находящиеся в репозитории.
'''Staging''' означает добавление (с помощью git add) изменений в 'staging area', где с ними могут быть выполнены некоторые действия
'''Commits''' - это изменения рабочего дерева репозитория в определенный момент времени. По сути, это точка сохранения. Commit - это просто список файлов, которые были изменены с момента последнего коммита, а изменения, которые были commit'нуты, - это изменения, которые Вы отправили в staging area.
'''Checking out''' - это переключение на другой branch, чтобы работать с ним или просматривать его изменения локально.
'''Merging''' - это интеграция изменений из одного branch'а в другой.
Конфликты merge'а" возникают, когда интеграция изменений из одного branch'а в другой не может быть выполнена автоматически, поскольку они оба изменяют одну и ту же область в файле, или их изменения взаимоисключают друг друга каким-либо другим способом.
'''Fetching''' означает получение branch'ей и commit'ов удаленного репозитория, но на самом деле... еще ничего с ними не делая. Они будут просто обновлены, если вы захотите проверить или объединить их позже.
'''Pulling''' - это акт интеграции изменений из branch'а удаленного репозитория в Ваш локальный branch.
Merge Requests" - это действие, позволяющее запросить слияние Вашего локального branch'а и всех его изменений с branch'а другого репозитория.
'''Pushing''' - это действие по интеграции локальных изменений в удаленный репозиторий.

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

Одно замечание, поскольку оно часто встречается здесь: HEAD - это модное название commit'а, на котором Вы сейчас находитесь.
=== Разрешение конфликтов при merge ===
Вредный маленький maintainer сказал вам "разрешить конфликты", иначе ваш MR "не будет merge'нут". Вот ведь сволочь! К счастью, это не так уж сложно.

Сначала нужно обновить главный локальный branch. Как это сделать, см. выше.

Когда Вы выполните команду <code>git merge master [локальный branch]</code>, она либо сделает это без ошибок ("ура"), либо сообщит Вам, что необходимо разрешить конфликты (ужас).

Для разрешения конфликтов вручную достаточно зайти в конфликтующие файлы, удалить всю ерунду типа <code>>>>>HEAD</code> и <code>===== <<<<master</code> (просто указывает, откуда произошли изменения), а затем отредактировать файл так, чтобы он правильно объединял оба набора изменений. Иногда это легко, иногда трудно. Если это сложно, то Вы, вероятно, знаете, что делаете. После этого просто выполните команду <code>git commit</code>.

У Atlassian есть [https://www.atlassian.com/git/tutorials/using-branches/merge-conflicts очень хорошее руководство] по этому вопросу.
=== Проверка истории ===
<code>git log --oneline</code> - это Ваш друг. Он показывает короткие hashe'и commit'ов (уникальные идентификаторы), их сообщения, а также их branch'и и tag'и.
=== Очистка локальных изменений ===
Возможно, Вы случайно внесли ненужные изменения, и Вам не хочется возиться с созданием совершенно новой ветки или еще чего-нибудь, но Вы еще не сделали commit с ними.

<code>git reset --hard HEAD</code>
Это означает "изменить working tree на текущий commit, до внесения любых локальных изменений. Вы не сможете восстановить локальные изменения, если сделаете это, так что будьте осторожны.
=== Откат сделанного Вами commit'а ===
Вот черт, Ваша эротика про ксеноморфа попала в commit или Вы случайно commit'нули подмодуль! Что теперь? Есть решения:

<code>git revert HEAD</code>
Это создаст новый commit, отменяющий текущий commit, и затем commit'нет его. Хе-хе, commit.

Git для разработчика SS14

2023-09-27T20:53:58Z

Ser11y: Дописано руководство, не включая Fork(GUI)

== Предисловие ==
В тексте будет часто упоминаться GitLab - аналог GitHub, которым также пользуется Workbench Team. Принципиальной разницы нет, все шаги возможны и на GitHub, но лично мне удобнее работать с GitLab.
Если Вам не ясны какие-либо термины из текста ниже, обратитесь к разделу [[Git_для_разработчика_SS14#Словарь:_Внутренние_операции_Git|Словарь: Внутренние операции Git]].

== Установка Git ==
Для работы с Git для SS14 Вам понадобятся:
* [https://git-scm.com/downloads Git]
** Если Вы хотите использовать Git только в консоли, поставьте галочку при установке:
[[Файл:GitBash.png|мини|центр]]
* [https://www.python.org/downloads/ Python 3.7+]

Если Вы работаете в Linux, то, скорее всего, будете использовать Git через терминал или выбранную Вами IDE, и, возможно, он у Вас уже установлен.

Некоторые IDE имеют в себе интеграцию Git, но этом руководстве будет информация '''только''' об использовании ''приложений'' [[Git для разработчика SS14#Git_Bash|Git Bash]] и [[Git для разработчика SS14#Fork|Fork]].

=== Fork ===
[https://git-fork.com/ Fork] — быстрый и удобный Git-клиент, позволяющий делать всё, что можно в консоли, но удобнее.

== Налаживание репозиториев Git ==
Репозиторий - это просто база кода. Репозитории содержат branch'и, а эти branch'и содержат различные commit'ы. Возможно, Вы слышали об этих двух понятиях - подробнее о них будет рассказано позже.

Удаленный репозиторий - это просто репозиторий на GitLab. Локальный репозиторий - это тот, который находится на Вашем компьютере.
=== Создание Вашего remote репозитория ===
Сперва давайте создадим собственный Fork удаленного репозитория Space Station 14. Для этого, конечно же, потребуется учетная запись GitLab. Forking означает, что Вы копируете всю историю и изменения репозитория в свой собственный удаленный репозиторий, чтобы иметь возможность свободно работать с кодом.

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

Перейдите в наш репозиторий Space Station 14([https://github.com/Workbench-Team/space-station-14 GitHub], [https://git.arumoon.ru/Workbench-Team/space-station-14 GitLab]) и нажмите здесь:
[[Файл:ForksButton.png|мини|центр]]
Затем Вас спросят как назвать Fork - просто назовите его как угодно! Но если Вы хотите просто помочь в разработке, я бы выбрал space-station-14.
=== Создание Вашего локального репозитория ===
Теперь нам нужно загрузить наш удаленный репозиторий на компьютер (клонировать), чтобы мы могли внести в него некоторые изменения. Технически, Вы можете изменять репозиторий удалённо (на GitLab есть неплохие инструменты), но наличие его на Вашем компьютере означает, что Вы используете IDE, такие как Visual Studio или Rider, для сборки игры и запуска тестов, а также легко работаете с Git.

Для каждого шага будут приведены скриншоты и инструкции для Git Bash и Fork для Windows.
===== GitBash: =====
Перейдите в то место на Вашем компьютере, где Вы хотите разместить локальный репозиторий, и:
[[Файл:GitBashHere.png|мини|центр]]
Выберите какой репозиторий клонировать:
[[Файл:GitBashCloneCommand.png|мини|центр]]
Проделайте команду <code>git remote add upstream</code> с <code>https://git.arumoon.ru/Workbench-Team/space-station-14</code>, чтобы у Вас была возможность обновлять свои branch'и новыми обновлениями upstream'а.

=== Подмодули ===
Обратите на это внимание! Если этого не сделать, то при попытке сборки игры вы получите множество странных ошибок о недоступности тех или иных модулей.

В Space Station 14 есть много подмодулей - в первую очередь, движок RobustToolbox. Подмодули - это просто репозитории внутри репозитория, и их нужно обновлять вручную. А нужно ли?

У нас есть автоматическая программа обновления подмодулей, так что Вам не нужно постоянно выполнять <code>git submodule update --init --recursive</code> (команда для ручного обновления подмодулей).

Запустите <code>RUN_THIS.py</code> внутри репозитория, который Вы скачали, с помощью Python. Желательно, из терминала (<code>python RUN_THIS.py</code> или <code>python3 RUN_THIS.py</code>). Это должно занять несколько секунд, так что если все мгновенно прекратится, то, вероятно, Вы не используете [https://www.python.org/downloads/ Python 3.7+] или что-то в этом роде.

Если Вы работаете в Windows и при попытке выполнить приведенную выше команду Вас перенаправляет в Microsoft Store или Вы получаете сообщение в терминале о том, что Python не установлен, необходимо отключить shortcut Microsoft, который может вызывать эту проблему. Это можно сделать, найдя в поиске Windows команду <code>Manage App Execution Aliases</code>, а затем отключив две точки привязки Python.

Если Вы все же хотите модифицировать движок напрямую или обновлять подмодуль вручную (автоматическое обновление иногда доставляет неудобства), создайте файл <code>DISABLE_SUBMODULE_AUTOUPDATE</code> в каталоге <code>BuildChecker/.</code>.

Если по каким-либо причинам, Вам понадобится вручную обновить RobustToolbox, Вы можете использовать <code>cd RobustToolbox; git checkout v0.4.87</code> (замените <code>v0.4.87</code> на последнюю версию RobustToolbox), затем Вы можете использовать <code>cd..\</code>, чтобы вернуться в репозиторий SS14. Это также пример использования cd для навигации по файлам, не выходя из командной строки.
== Branching & Commits (Ветки и коммиты) ==

=== Что такое branch? ===
Branch'и очень и очень важны. По сути, они представляют собой лист изменений в коде (commit'ов). По умолчанию используется branch <code>master</code>.

При работе с кодом Вы всегда находитесь в branch'е, и Вы можете легко менять branch, в котором работаете.

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

Branch'ей можно создавать сколько угодно. Когда Вы создаете branch, он ответвляется от текущего branch'а и становится самостоятельным объектом, в который можно добавлять commit'ы.
[[Файл:BranchDiagram|мини|центр|Каждый маленький узел - это отдельный commit, а каждый цвет - отдельный branch.]]
==== Зачем это нужно? ====
Технически, конечно, можно просто делать всю работу в одном branch'е и отправлять Merge Request'ы оттуда. Но создание различных branch'ей позволяет легко понять, где Вы находитесь, сколько изменений внесли, и дает возможность работать над несколькими особенностями(новым содержимым) одновременно.
==== Создание и работа с branch'ами ====
Создавать branch'и довольно просто. Давайте создадим новый branch под названием <code>funny-feature</code>:
===== Git Bash =====
[[Файл:GitBashNewBranchCommand.png|мини|центр]]
Параметр <code>-b</code> в <code>git checkout</code> здесь означает "проверь этот branch, и создай его, если он не существует".

Переключаться между branch'ами довольно просто: это называется проверкой branch'а. При этом локальные файлы и папки будут изменены в соответствии с веткой, поэтому Git будет кричать на Вас, если у Вас есть локальные изменения, а Вы пытаетесь выполнить проверку.

===== Git Bash =====
[[Файл:GitBashCheckoutBranchCommand.png|мини|центр]]
Ну а затем внесите любые локальные изменения! Это не имеет значения. Создайте новый файл, удалите всё, измените одну строку в файле и т.д. Это не повлияет на Ваш главный branch, потому что теперь это территория <code>funny-feature</code>!
==== Совмещение branch'ей ====
Branche'и важны, поскольку их можно объединять. Так происходит интеграция функций в основную ветку. Merge означает "взять особые commit'ы из этого branch'а и применить их к другому branch'у". Вы можете объединить любые два branch'а.

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

GitLab Merge Request - это, по сути, "запрос на объединение": Вы говорите, что хотите объединить commit'ы своего branch'а с другим branch'ом, обычно главным. Подробнее об этом позже.

Merge Request'ы очень хорошо отображают всю эту информацию:
[[Файл:MergeRequestExampleImage.png|мини|центр]]
[[Файл:MergeRequestExampleCommitsImage.png|мини|центр]]
=== Что такое commit? ===
Commit'ы - это просто упакованные изменения в коде. Как разработчик, Вы выбираете, какие изменения войдут в commit и когда их вносить в branch. Commiting - это создание commit'а, который, по сути, является точкой сохранения, к которой можно вернуться в любое время.

Commit'ы имеют автора, временную метку, сообщение и некоторые изменения кода, прикрепленные к ним. Они также имеют очень длинный "commit hash" - уникальный идентификатор, используемый для ссылки на различные коммиты.

Благодаря commit'ам строится история - Вы можете просмотреть историю каждого коммита, сделанного в репозитории SS14 с самого начала, что очень здорово.
==== Отправка commit'ов в branch'и ====
Один важный момент: прежде чем отправлять изменения в commit, необходимо добавить их в область staging'а. Это означает, что Вы указываете, какие файлы хотите добавить в commit. Это полезно, поскольку Вы почти никогда не захотите commit'ить изменения подмодулей, так что Вы просто не добавляете их в область staging'а.

Commit'ы всегда сопровождаются сообщением, которое представляет собой краткое, содержательное описание того, что было сделано в данном commit'е. Или Вы можете быть "Чадом"(страна) и называть каждый коммит "меняет всякое" - на Ваше усмотрение.

Если Вы хотите посмотреть, что Вы изменили в данный момент, а что находится в области staging'а, то это довольно просто:
===== Git Bash =====
[[Файл:GitBashCheckStatusCommand.png|мини|центр]]
Теперь, когда Вы убедились, что все эти изменения выглядят хорошо, мы добавим их в область staging'а и сделаем commit с ними:
[[Файл:GitBashStashAndCommitCommand.png|мини|центр]]

Теперь, когда изменения были добавлены в commit и отправлены в branch, они навсегда (вроде как) остаются в истории branch'а. Теперь мы можем сделать многое: объединить(merge) нашу <code>funny-feature</code> с нашим локальным мастер-branch'ем (если захотим, по какой-то причине), загрузить (push) наш branch <code>funny-feature</code> в наш удалённый репозиторий, или полностью удалить ветку. Мы выберем push и сделаем Merge Request.
== Pushing и создание Merge Request'ов ==
Merge Request означает, что Вы хотите, чтобы кодовая база объединила Ваши изменения в одного из Ваших branch'ей в один из их branch'ей. Прежде чем мы сможем это сделать, наш удаленный репозиторий GitLab (origin) должен знать о красивых branch'ах и commit'ах, которые мы создали локально, поэтому мы push'им эти изменения на удаленный репозиторий.
=== Проталкивание commit'ов ===
Имейте в виду, что при использовании этих команд Git, скорее всего, запросит Ваши учетные данные GitLab, чтобы убедиться в том, что Вы имеете право выполнять push на этот удаленный репозиторий.

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

Push'им наш branch в удалённый репозиторий (origin):
===== Git Bash =====
[[Файл:GitBashPushCommand.png|мини|центр]]
=== Создание Merge Request'ов ===
Весёлая часть. Отправляемся на GitLab и создаём наш Merge Request:
[[Файл:GitLabFunnyFeatureMergeRequestButton.png|мини|центр]]
Добавьте описание, красивое название, несколько скриншотов, и, надеюсь, оно будет merge'нуто.

== Обновление репозитория ==
Возможно, прошло уже много времени, неделя или две, с момента Вашего последнего Merge Request'а, и Вы хотите сделать еще один. Прежде чем что-либо делать, необходимо загрузить (pull) изменения кода из основного репозитория SS14 в свой локальный репозиторий. В противном случае Вы получите устаревший код, а Ваши локальные изменения могут не соответствовать тому, как игра будет работать на самом деле - Вы даже можете получить конфликты слияния при попытке MR.

Существует два способа обновления репозитория. Оба способа предполагают, что Вы правильно настроили доступ к удалённому репозиторию - если это не так, вернитесь к предыдущему пункту руководства.

Первый способ, fetch+merge, дает больше возможностей для контроля, но может быть запутанным. Второй метод, pull, прост и удобен, но не дает большого контроля. Однако, как правило, pull - это все, что вам нужно.
=== Метод pull ===
Pulling означает получение (fetching) новых веток и commit'ов из удаленного репозитория, а затем их слияние с branch'ем. Pulling часто проще, поскольку Git имеет хорошую систему автоматического определения того, из какого удаленного репозитория Вы хотите получить изменения (но она не всегда работает корректно).

Мы будем pull'ить с нашего удалённого репозитория <code>upstream</code> и попросим его объединиться с нашим локальным branch'ем.

Сначала, Вам надо сделать checkout Вашего branch'а. Об этом мы рассказывали ранее. Затем:
===== Git Bash =====
[[Файл:GitBashPullUpstreamCommand.png|мини|центр]]
Делайте это регулярно и всегда до начала работы над новым branch'ем.

== Приложения ==
=== Что следует помнить ===
Вы более или менее изучили рабочий процесс разработки функций для SS14 с точки зрения Git, но вот некоторые вещи, которые я хотел бы вбить Вам в голову:

* При создании новой функциональности всегда создавайте новый branch от главного, прежде чем commit'ить что-либо. Если Вы случайно за-commit'ите изменения физики в branch с велосипедным клаксоном, Вам не поздоровится, но это поправимо.
* Никогда, никогда не фиксируйте RobustToolbox или подмодули типа Lidgren.Network, если Вы не знаете, что делаете. В локальном репозитории верхнего уровня эти подмодули считаются "файлами", поэтому их легко случайно отправить на staging и сделать commit с ними. Не делайте этого. О том, как исправить свои ошибки, если это произошло, см. ниже.

== Словарь: Внутренние операции Git ==
В качестве справочного материала здесь приведен небольшой глоссарий понятий и терминов Git, объясняющий их более подробно и в одном месте.

'''Branches''' - это автономные версии кодовой базы, в которые можно добавлять коммиты. По умолчанию используется ветка master, но их можно создавать сколько угодно.
'''Репозитории''' - это папки, в которых с помощью Git можно вносить изменения и отслеживать их. Локальные репозитории - это репозитории, которые находятся у Вас на компьютере, а удаленные репозитории - это репозитории, расположенные на таких сайтах, как GitLab Репозитории состоят из множества веток.
'''Remotes''' - это названия и ссылки на удаленные репозитории, которые может использовать Ваш локальный репозиторий.
'''Подмодули''' - это репозитории, которые находятся внутри другого репозитория.
'''Forks''' - это репозитории, основанные на другом репозитории. Если Вы собираетесь сделать Merge Request для SS14, Вам необходимо сначала сделать Fork.
'''The working tree''' - это все файлы, папки и т.п., находящиеся в репозитории.
'''Staging''' означает добавление (с помощью git add) изменений в 'staging area', где с ними могут быть выполнены некоторые действия
'''Commits''' - это изменения рабочего дерева репозитория в определенный момент времени. По сути, это точка сохранения. Commit - это просто список файлов, которые были изменены с момента последнего коммита, а изменения, которые были commit'нуты, - это изменения, которые Вы отправили в staging area.
'''Checking out''' - это переключение на другой branch, чтобы работать с ним или просматривать его изменения локально.
'''Merging''' - это интеграция изменений из одного branch'а в другой.
Конфликты merge'а" возникают, когда интеграция изменений из одного branch'а в другой не может быть выполнена автоматически, поскольку они оба изменяют одну и ту же область в файле, или их изменения взаимоисключают друг друга каким-либо другим способом.
'''Fetching''' означает получение branch'ей и commit'ов удаленного репозитория, но на самом деле... еще ничего с ними не делая. Они будут просто обновлены, если вы захотите проверить или объединить их позже.
'''Pulling''' - это акт интеграции изменений из branch'а удаленного репозитория в Ваш локальный branch.
Merge Requests" - это действие, позволяющее запросить слияние Вашего локального branch'а и всех его изменений с branch'а другого репозитория.
'''Pushing''' - это действие по интеграции локальных изменений в удаленный репозиторий.

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

Одно замечание, поскольку оно часто встречается здесь: HEAD - это модное название commit'а, на котором Вы сейчас находитесь.
=== Разрешение конфликтов при merge ===
Вредный маленький maintainer сказал вам "разрешить конфликты", иначе ваш MR "не будет merge'нут". Вот ведь сволочь! К счастью, это не так уж сложно.

Сначала нужно обновить главный локальный branch. Как это сделать, см. выше.

Когда Вы выполните команду <code>git merge master [локальный branch]</code>, она либо сделает это без ошибок ("ура"), либо сообщит Вам, что необходимо разрешить конфликты (ужас).

Для разрешения конфликтов вручную достаточно зайти в конфликтующие файлы, удалить всю ерунду типа <code>>>>>HEAD</code> и <code>===== <<<<master</code> (просто указывает, откуда произошли изменения), а затем отредактировать файл так, чтобы он правильно объединял оба набора изменений. Иногда это легко, иногда трудно. Если это сложно, то Вы, вероятно, знаете, что делаете. После этого просто выполните команду <code>git commit</code>.

У Atlassian есть [https://www.atlassian.com/git/tutorials/using-branches/merge-conflicts очень хорошее руководство] по этому вопросу.
=== Проверка истории ===
<code>git log --oneline</code> - это Ваш друг. Он показывает короткие hashe'и commit'ов (уникальные идентификаторы), их сообщения, а также их branch'и и tag'и.
=== Очистка локальных изменений ===
Возможно, Вы случайно внесли ненужные изменения, и Вам не хочется возиться с созданием совершенно новой ветки или еще чего-нибудь, но Вы еще не сделали commit с ними.

<code>git reset --hard HEAD</code>
Это означает "изменить working tree на текущий commit, до внесения любых локальных изменений. Вы не сможете восстановить локальные изменения, если сделаете это, так что будьте осторожны.
=== Откат сделанного Вами commit'а ===
Вот черт, Ваша эротика про ксеноморфа попала в commit или Вы случайно commit'нули подмодуль! Что теперь? Есть решения:

<code>git revert HEAD</code>
Это создаст новый commit, отменяющий текущий commit, и затем commit'нет его. Хе-хе, commit.

Файл:MergeRequestExampleCommitsImage.png

2023-09-27T20:52:51Z

Ser11y:

MergeRequestExampleCommitsImage

Файл:MergeRequestExampleImage.png

2023-09-27T20:52:25Z

Ser11y:

MergeRequestExampleImage

Файл:GitBashPullUpstreamCommand.png

2023-09-27T20:19:25Z

Ser11y:

GitBashPullUpstreamCommand

Файл:GitLabFunnyFeatureMergeRequestButton.png

2023-09-27T20:04:11Z

Ser11y:

GitLabFunnyFeatureMergeRequestButton

Файл:GitBashPushCommand.png

2023-09-27T19:56:33Z

Ser11y:

Git Bash Push Command

Файл:GitBashStashAndCommitCommand.png

2023-09-27T19:46:23Z

Ser11y:

Git Bash Stash And Commit Command

Файл:GitBashCheckStatusCommand.png

2023-09-27T19:44:09Z

Ser11y:

Git Bash Check Status Command

Файл:GitBashCheckoutBranchCommand.png

2023-09-27T19:37:32Z

Ser11y:

Git Bash Checkout Branch Command

Файл:GitBashNewBranchCommand.png

2023-09-27T19:32:53Z

Ser11y:

Git Bash New Branch Command

Файл:BranchDiagram.png

2023-09-27T19:25:34Z

Ser11y:

Диаграмма.

Git для разработчика SS14

2023-09-27T15:20:28Z

Ser11y:

Git для разработчика SS14

2023-09-27T15:15:52Z

Ser11y: Перевод до Branching & Commits

Файл:GitBashCloneCommand.png

2023-09-27T15:13:49Z

Ser11y: Ser11y загрузил новую версию Файл:GitBashCloneCommand.png

Git Bash Clone Command

Файл:GitBashCloneCommand.png

2023-09-27T15:08:28Z

Ser11y:

Git Bash Clone Command

Файл:GitBashHere.png

2023-09-27T14:55:29Z

Ser11y:

Git Bash Here Button

Файл:ForksButton.png

2023-09-27T14:46:46Z

Ser11y:

Файл:GitBash.png

2023-09-27T14:22:09Z

Ser11y:

Git для разработчика SS14

2023-09-27T14:11:27Z

Ser11y:

== Предисловие ==
Если Вам не ясны какие-либо термины из текста ниже, обратитесь к разделу Словарь: [[Git_для_разработчика_SS14#Словарь:_Внутренние_операции_Git|Словарь: Внутренние операции Git]].

== Установка Git ==
=== Fork ===
=== Git Bash ===

== Налаживание репозиториев Git ==

=== Создание Вашего remote репозитория ===
=== Создание Вашего локального репозитория ===
=== Подмодули ===

== Branching & Commits (Ветки и коммиты) ==

=== Что такое branch? ===
==== Зачем это нужно? ====
==== Создание и работа с branch'ами ====
==== Совмещение branch'ей ====

=== Что такое commit? ===
==== Отправка commit'ов в branch'и ====

== Pushing и создание Merge Request'ов ==
=== Проталкивание commit'ов ===
=== Создание Merge Request'ов ===

== Обновление репозитория ==
=== Метод fetch + merge ===
=== Метод pull ===

== Приложения ==
=== Что следует помнить ===
=== Краткий пример рабочего процесса ===

== Словарь: Внутренние операции Git ==

== Примечание: Полезные советы и рекомендации ==
=== Разрешение конфликтов при merge ===
=== Проверка истории ===
=== Очистка локальных изменений ===
=== Откат сделанного Вами commit'а ===

Git для разработчика SS14

2023-09-27T14:09:38Z

Ser11y: Добавлены заголовки

== Предисловие ==

== Установка Git ==
=== Fork ===
=== Git Bash ===

== Налаживание репозиториев Git ==

=== Создание Вашего remote репозитория ===
=== Создание Вашего локального репозитория ===
=== Подмодули ===

== Branching & Commits (Ветки и коммиты) ==

=== Что такое branch? ===
==== Зачем это нужно? ====
==== Создание и работа с branch'ами ====
==== Совмещение branch'ей ====

=== Что такое commit? ===
==== Отправка commit'ов в branch'и ====

== Pushing и создание Merge Request'ов ==
=== Проталкивание commit'ов ===
=== Создание Merge Request'ов ===

== Обновление репозитория ==
=== Метод fetch + merge ===
=== Метод pull ===

== Приложения ==
=== Что следует помнить ===
=== Краткий пример рабочего процесса ===

== Словарь: Внутренние операции Git ==

== Примечание: Полезные советы и рекомендации ==
=== Разрешение конфликтов при merge ===
=== Проверка истории ===
=== Очистка локальных изменений ===
=== Откат сделанного Вами commit'а ===

Управление

2023-05-11T14:31:29Z

Ser11y: Ну, эм, вот:

== Управление ==
Вот клавиши, которые могут пригодиться Вам в игре. Остальные, как и эти, Вы можете найти в настройках.
{| class="wikitable sortable mw-collapsible"
|+Основные клавиши
!Клавиша
!Описание
|-
|ЛКМ
|Базовое взаимодействие. Используется для атаки, поднятия предмета с пола, использования чего-либо в руке(надо нажать на этот предмет) или активации чего-либо.
|-
|Alt+ЛКМ
|Альтернативное взаимодействие, например, достать ID-Карту из КПК или закрыть ящик на электронный замок.
|-
|ПКМ
|Открывает контекстное меню, где, обычно, можно увидеть все доступные взаимодействия с предметом.
|-
|E
|Взаимодействовать с предметом, например, открыть рюкзак или ящик. В остальном не отличается от ЛКМ.
|-
|Q
|Положить предмет.
|-
|Ctrl+Q
|Бросить предмет.
|-
|Z
|Использовать предмет в активной руке, будь то кружка, из которой надо выпить кофе<s>, или пожарный топор, который надо взять в две руки</s>.
|-
|Shift+Q и Shift+E
|Убрать/достать предмет в/из рюкзака или пояса соответственно. Очень полезно, когда лень тащить мышку.
|-
|Ctrl+ЛКМ
|Потащить что-либо за собой.
|-
|Ctrl+ПКМ
|Перетащить то, что тащишь на место курсора.
|-
|Shift+СКМ
|Указать на что-либо.
|-
|Кнопки 1-0
|Использование панели действий слева.
|-
|K
|Настройка панели действий.
|-
|I
|Посмотреть надетые на Вас вещи.
|}
Но не думайте, что это - всё! Вот парочка советов:

* Если хотите обыскать кого-то, перетащите его на себя.
* Если хотите залезть или сесть на что-то, перетащите себя или нажмите <code>Alt+ЛКМ</code> на это.
* Если Вы - [[Предатель]], нажмите <code>C</code>⁣, чтобы увидеть свои задачи и кодовые слова с рингтоном для КПК.<br />

Гайд на строительство

2023-05-10T18:58:39Z

Ser11y:

== Основы ==
Строительство - неотъемлемая часть работы инженерного и не только отделов. Застраивать дыры в корпусе станции, строить компьютеры и машины - всё к строительству.

Меню строительства на <code>G</code> уже говорит само за себя. Вы вводите название предмета в поиск, нажимаете <code>Создать</code> или <code>Разместить призрак конструкции</code> и собираете его. Но не так всё просто, как кажется на первый взгляд!

=== Машины и компьютеры ===
При сборке компьютера или машины, например, протолата у Вас может возникнуть вопрос "А что дальше-то?". А всё легко! Осмотрите только что собранный Вами корпус с помощью <code>Shift+ЛКМ</code> и следуйте указанным там инструкциям! Не забывайте брать с собой инструменты, они всегда понадобятся при сборке чего-то сложнее стены!

Иногда, для строительства Вам могут понадобиться детали, которые просто так в технических помещениях не валяются(почти), например, манипулятор. Его и многие другие детали Вы можете <s>украсть</s> заказать в отделе Науки! Любезные учёные никогда Вам не откажут!

Гайд на строительство

2023-05-10T18:57:52Z

Ser11y: Добавлена страница! С текстом!

== Основы ==
Строительство - неотъемлемая часть работы инженерного и не только отделов. Застраивать дыры в корпусе станции, строить компьютеры и машины - всё к строительству.

Меню строительства на <code>G</code> уже говорит само за себя. Вы вводите название предмета в поиск, нажимаете <code>Создать</code> или <code>Разместить призрак конструкции</code> и собираете его. Но не так всё просто, как кажется на первый взгляд!

=== Машины и компьютеры ===
При сборке компьютера или машины, например, протолата у Вас может возникнуть вопрос "А что дальше-то?". А всё легко! Осмотрите только что собранный Вами корпус с помощью <code>Shift+ЛКМ</code> и следуйте указанным там инструкциям! Не забывайте брать с собой инструменты, они всегда понадобятся при сборке чего-то сложнее стены!

Иногда, для строительства Вам могут понадобиться детали, просто так в технических помещениях не валяются(почти), например, манипулятор. Его и многие другие детали Вы можете у<s>красть</s> заказать в отделе Науки! Любезные учёные никогда Вам не откажут!

Руководство новичкам

2023-05-10T18:37:51Z

Ser11y: Обновил страницу. Во многом.

<small>''«Space Station 14 - кооперативная игра в жанрах ролевые игры, экшены, симуляторы»''</small>

Игра совсем не лёгкая. Для того чтобы её освоить полностью потребуются десятки, а то и сотни часов.

Цель этой страницы - ответить на популярные(в особенности у новичков) вопросы по игре. Если вы потерялись и задаёте себе вопрос "А что вообще делать?" - эта страница Вам поможет, наверное.

== Настройка персонажа ==
При входе на сервер, а также в начале каждого раунда вы попадаете в лобби.
[[Файл:Персонализация.png|обрамить|справа]]
Для того чтобы настроить внешность и приоритеты профессий Вашего персонажа нажмите кнопку <code>Персонализация</code>, когда сделаете это не забудьте сохранить его. Нажмите <code>Готов</code> - эта кнопка запустит Вас в раунд по его началу, если Вы этого не сделаете, Вам придётся выбирать из оставшихся профессий.
[[Файл:Присоединиться.png|обрамить|справа|альт=Присоединиться|Присоединиться]]

== Управление ==
В игре есть много способов взаимодействия, но рука, которую Вы используете для взаимодействия всегда должна быть пуста, если, конечно, Вы не засовываете что-то куда-то.
{| class="wikitable sortable mw-collapsible"
|+Основные клавиши
!Клавиша
!Описание
|-
|ЛКМ
|Базовое взаимодействие. Используется для атаки, поднятия предмета с пола, использования чего-либо в руке(надо нажать на этот предмет) или активации чего-либо.
|-
|Alt+ЛКМ
|Альтернативное взаимодействие, например, достать ID-Карту из КПК или закрыть ящик на электронный замок.
|-
|ПКМ
|Открывает контекстное меню, где, обычно, можно увидеть все доступные взаимодействия с предметом.
|-
|E
|Взаимодействовать с предметом, например, открыть рюкзак или ящик. В остальном не отличается от ЛКМ.
|-
|Q
|Положить предмет.
|-
|Ctrl+Q
|Бросить предмет.
|-
|Z
|Использовать предмет в активной руке, будь то кружка, из которой надо выпить кофе<s>, или пожарный топор, который надо взять в две руки</s>.
|-
|Shift+Q и Shift+E
|Убрать/достать предмет в/из рюкзака или пояса соответственно. Очень полезно, когда лень тащить мышку.
|-
|Ctrl+ЛКМ
|Потащить что-либо за собой.
|-
|Ctrl+ПКМ
|Перетащить то, что тащишь на место курсора.
|-
|Shift+СКМ
|Указать на что-либо.
|-
|Кнопки 1-0
|Использование панели действий слева.
|-
|K
|Настройка панели действий.
|-
|I
|Посмотреть надетые на Вас вещи.
|}
Но не думайте, что это - всё! Вот парочка советов:

* Если хотите обыскать кого-то, перетащите его на себя.
* Если хотите залезть или сесть на что-то, перетащите себя или нажмите <code>Alt+ЛКМ</code> на это.
* Если Вы - [[Предатель]], нажмите <code>C</code>⁣, чтобы увидеть свои задачи и кодовые слова с рингтоном для КПК.<br />
== Игровой процесс ==
Вы прибыли на Научную Космическую Станцию 14, принадлежащую мега-корпорации NanoTrasen. Помимо Вас, здесь находятся ещё ~75 человек, у каждого из них свои особенности в виде расы и роли и других параметров. Существует несколько режимов игры: в некоторых станцию будут кошмарить [[Ядерный оперативник|Ядерные Оперативники]] Синдиката, в другом, его [[Предатель|Агенты]], но это ещё далеко не всё!

Наконец, не забывайте, что все другие игроки - тоже люди. Соблюдайте [[Правила Космической станции|правила сервера]] и [[Космический Закон]].

== Рации и каналы ==
[[Файл:Channels.png|мини|200x200пкс|Каналы для гарнитуры уборщика.]]
В игре существует множество каналов и чатов, например, общая, медицинская и другие рации. Переключение между основными происходит клавишей <code>Tab</code>, в то время, как в другие надо писать вручную.

Ваша гарнитура хранит в себе ключи шифрования, которые позволяют Вам писать в определённые каналы, по типу медицинского или командного. Чтобы узнать, какие каналы Вам доступны осмотрите свою гарнитуру с помощью клавиш <code>Shift+ЛКМ</code> по ней. Там будет написано, как писать в канал и за что он отвечает.

Не забывайте, что каналы в игре делятся на IC(Рация, Рядом и т.д.) и OOC, т.е. Игровые и Неигровые. Так же, как в OOC нельзя писать информацию, которую Вы получили в игре, так же нельзя писать в IC то, что Вы получили, например, из Discord.

== Ориентирование на станции ==
Простой способ ориентирования на станции - таблички. Если Вам не понятно, о чём она сообщает, просто осмотрите её, нажав <code>Shift+ЛКМ</code> по ней. Обычно, таблички висят на перекрёстках.

== Роли для новичков ==
Лучше всего для новичков подойдет роль [[Ассистент|Ассистента]], поскольку от него ничего не требуется. Можете свободно изучать управление, игру и станцию.
Как освоитесь - можете попробовать роли из [[Роли Космической станции#Сервис|Сервисного отдела]], например [[Ботаник|Ботаника]], [[Клоун|Клоуна]] или [[Бармен|Бармена]].

{| class="wikitable sortable"
|+ '''Список ролей по их сложности для новичка''':
|-
! Сложность !! Роль !! Объяснение
|-
| Легчайше! || Ассистент, Животные || Изучайте игру в свое удовольствие.
|-
| Легко || Любые сервисные роли(Бармен и Шеф-повар немного сложнее остальных), Грузчик, Психолог || С этим можно быстро разобраться, в интернете полно гайдов, а коллеги рады Вам помочь и все показать. Ответственность за станцию Вы не несете.
|-
| Средне || Кадет СБ, Интерн, Ученый, Утилизатор, Технический ассистент, Антагонисты || От вас многого не ждут, если что, у Вас всегда есть старшие коллеги, но если Вы не разбираетесь в своих обязанностях, будете обузой.
|-
| Сложно|| Офицер СБ, Детектив, Инженер, Врач, Химик, ОБР || У Вас тяжелая работа. Если Вы не умеете её выполнять - подведете станцию, вызовите людские жертвы, закончите в тюрьме.
|-
| Невозможно! || Весь отдел Командования, Командир Ядерных Оперативников, ПЦК, Смотритель, Атмосферный Техник || Вы несёте прямую ответственность за станцию. Если Вы не справитесь - игра закончится трагично.
|}

== Смерть еще не конец ==
Если Вы умерли(Счётчик пульса справа показывает надпись "DEAD"), это ещё не значит, что Вам надо выходить из игры! Вылетите из тела(<code>WASD</code>) и нажмите кнопку "<code>Роли призраков</code>" снизу: Вашему взору покажется список существ, в которых Вы можете вселиться! Просто нажмите "<code>Запросить</code>"!

Файл:Channels.png

2023-05-10T18:31:51Z

Ser11y:

Каналы радио.

Уборщик

2023-05-09T19:39:59Z

Ser11y: Категория

{{JobHeader|color1=#79b347|color2=#6f9e47|textcolor=white|department=Сервис|jobname=Ассистент|img=[[File:Janitor.png|128px]]|access=Технический, Уборщик|difficulty=Лёгкая|duties=Убирайте мусор и кровь. Заменяйте разбитые лампочки. Заставьте каждого члена экипажа упасть хоть раз.|supervisors=[[Глава персонала]]|quote="Мне 30 и я работаю уборщиком на продвинутой научной станции, наконец моя мама может мной гордиться!"}}

==Что мне делать?==

===Задачи===
Ваша работа - самая сложная и самая недооценённая на станции, Вы собираете <s>органы от трупов ассистентов</s> мусор от еды, заменяете лампы, разбитые космическими клещами и вымываете бесконечную космическую смазку с пола. Не забывайте кричать на людей, когда они кидают мусор на пол!

===Снаряжение===
{| class="wikitable mw-collapsible mw-collapsed"
|+Снаряжение
!Изображение
!Имя
!Описание
|-
|[[Файл:Galoshes.png|32px|мини|слева]]
|Галоши
|Резиновые ботинки. Защищают от подскальзывания.
|-
|[[Файл:Mop.png|32px|мини|слева]]
|Швабра
|Ваш главный инструмент. Хранит в себе жидкости.
|-
|[[Файл:Trash_Bag.png|16px|мини|слева]]
|Мешок для мусора
|Складывайте в него мусор<s>, высыпайте его ГП на стойку</s>.
|-
|[[Файл:Bio Suit.png|32px|мини|слева]]
|Биозащитный костюм
|Защищает Вас от заражения. Не очень сильно.
|-
|[[Файл:Janitorial trolley.png|32px|мини|слева]]
|Тележка уборщика
|Тележка. Содержит в себе встроенное ведро, на неё могут быть повешены приспособления уборщика.
|}
Однако, это не всё доступное уборщику снаряжение: с продвинутой технологией уборки Научный отдел может создавать для Вас следующие предметы:
{| class="wikitable mw-collapsible mw-collapsed"
|+Продвинутое снаряжение
!Изображение
!Имя
!Описание
|-
|[[Файл:Adv Mop.png|32px|мини|слева]]
|Продвинутая швабра
|Улучшенная швабра, заполняющаяся водой автоматически.
|-
|[[Файл:Mega Spray Bottle.png|16px|мини|слева]]
|Мега бутылка с распылителем
|Распылитель с увеличенным объёмом.
|}

===Советы===

*Используйте ботов-уборщиков, они помогут Вам в уборке.
*Если Вы потеряли что-то из своего снаряжения Вы можете заказать его в Поставках.

[[Category:Роли]]

Уборщик

2023-05-09T19:38:46Z

Ser11y: Добавлена страница! С текстом и картинками!!!

Файл:Mega Spray Bottle.png

2023-05-09T19:32:11Z

Ser11y:

Файл:Adv Mop.png

2023-05-09T19:31:29Z

Ser11y:

Файл:Janitorial trolley.png

2023-05-09T19:08:16Z

Ser11y:

Файл:Bio Suit.png

2023-05-09T19:08:00Z

Ser11y:

Файл:Trash Bag.png

2023-05-09T19:07:40Z

Ser11y:

Файл:Mop.png

2023-05-09T19:07:16Z

Ser11y: