Git/Git-console

Этот раздел или статья в стадии разработки. Информация на этой странице может оказаться неполной или не соответствовать реальности. В данный момент её редактированием никто не занят.

Общее небольшое руководство по github-у и консольному git.
Часть про установку рассчитана на Windows, часть про работу с Github будет актуальна и для пользователей гуи-интерфейсов.

Есть много различных GUI-клиентов, например TortoiseGit (на вики tg-станции есть подробный обновляемый гайд), SourceTree.
Мы же в данной статье остановимся по большей части на консольном клиенте git:

1. Сам Git - изначально консольный инструмент. И удобный!
2. Консоль дает больше возможностей, чем GUI-клиенты.
3. В GUI-клиентах есть возможность запустить консоль, если понадобится. Так что это универсальная инструкция.
4. С консолью, вы словно хакер!

В любом случае, какой-бы клиент вы не выбрали, в интернете всегда найдется документация и куча различных инструкций.

Github

Гитхаб - наиболее популярный в сообществе станции хостинг репозиториев. Некоторые основные репозитории:

• https://github.com/Baystation12/Baystation12 билд Baystation12
• https://github.com/tgstation/-tg-station билд TG
• https://github.com/TauCetiStation страничка с репозиториями Таукиты
• https://github.com/animusdev страничка с репозиториями Анимуса

Регистрируемся по адресу https://github.com/join, подтверждаем email, всё стандартно.

Важно: email, который вы укажете при регистрации, в дальнейшем будет указан под каждым вашим коммитом на гитхабе. Если не хотите светить - зарегистрируйте отдельный.

Git клиент, настройка

Пример Posh-Git на Windows 8.

Самый простой способ - поставить Github for windows все с того же гитхаба: https://desktop.github.com/
Да, это графический клиент, и если работа с консолью не понравится, можете попробовать использовать его. На деле же нам потребуется запустить его только раз для настройки.
Но что нас интересует больше - это идущие в комплекте Git (сам клиент) и Posh-Git (расширение для Windows Powershell, не обязательно но крайне полезно - автодополнение по TAB и подсветка), самостоятельная установка и настройка которых может вызвать сложности (кому не хватает приключений - в интернете можно найти инструкции).

Итак, запускаем с рабочего стола GitHub, логинимся под своим зарегестрированным ранее аккаунтом, пропускаем шаг с локальными репозиториями.
Осталось только зайти в Options, и выбрать место для хранения репозиториев.
Всё, можете закрыть и забыть про гуи, и с рабочего стола запустить Git Shell.

Краткий курс

Гитхаб - инструмент для совместной работы. За исключением некотрых случаев, процесс работы выглядит примерно следующим образом:
Есть центральный репозиторий, с которым все синхронизируются, и в который через PR (пулл-запросы) кидаются изменения. Каждый участвующий разработчик делает свой собственный форк (ответвление от основного репозитория, по сути собственная удаленная копия репозитория), клонирует свой форк на локальную машину для работы, делает вещи.
Когда что-то готово, изменения сначала коммитятся (фиксируются) в свой форк, после с форка создается пулл-запрос на принятие изменений в основной репозиторий. PR проходит ревью у мэйнтейнеров проекта (сопровождающих разработчиков), по необходимости вносятся изменения/исправления, и далее, либо принимается, либо отклоняется.

Остановимся подробнее на каждом из этапов, здесь и дальше алгоритм приводится на примере текущего основного репозитория Тау Киты, TauCetiClassic.

Делаем форк

Достаточно на странице репозитория https://github.com/TauCetiStation/TauCetiClassic в правом верхнем углу нажать Fork.
В течении пары минут гитхаб подготовит ваш собственный репозиторий по адресу вида https://github.com/%аккаунт%/TauCetiClassic
Кстати, нет никакой необходимости поддерживать актуальность вашего форка, не нужно специально его обновлять или пересоздавать. Ниже будет описанно, как обновляться напрямую с репозитория Тау Киты, а форк нам пригодится только для создания ПуллРеквестов.

Создаем локальную рабочую копию

Со страницы вашего репозитория среди кнопок находим и копируем https адрес

https://github.com/%аккаунт%/TauCetiClassic.git

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

git clone https://github.com/%аккаунт%/TauCetiClassic.git tauceticlassic

По окончанию клонирования у вас будет актуальный билд в папке tauceticlassic/, с которым можно уже работать в DreamMaker-е. Прежде всего, для продолжения работы в консоли, вам необходимо сделать вход в папку, написав в ней cd %имя папки%
Важно: после клонирования билда Тау Киты, стоит выполнить команду:

git update-index --assume-unchanged taucetistation.int

Подключаем удаленный репозиторий

Время от времени необходимо обновлять свой репозиторий с центрального. Это нужно делать, например, в случае возникновения конфликтов (если, пока вы пилили фичу, кто-то успел в аналогичных файлах внести свои изменения), и просто для профилактики.
Традиционно центральный репозиторий именуется как upstream (или апстрим), но никто не мешает подобрать своё имя, к тому же никто не мешает иметь подключенными сразу несколько удаленных репозиториев. Кстати, после git clone ... у вас уже есть 1 подключенный удаленный репозиторий под названием origin, ссылающийся на репозиторий, который вы клонировали (ваш форк на гитхабе).
Подключим центральный репозиторий Тау Киты:

git remote add upstream https://github.com/TauCetiStation/TauCetiClassic.git

Пока мы только создали ссылку на репозиторий, нужно еще обновить изменения:

git fetch upstream

Можете посмотреть список своих удаленных репозиториев по команде git remote -v

Создаем ветку, переключаем ветки

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

git checkout -b some-awesome-feature

Создаст ответвление от вашей текущей ветки с названием some-awesome-feature, и переключится на неё.
Важно: по умолчанию создается ответвление от текущей ветки, что может быть неудобно в случае работы сразу над несколькими ветками. В качестве параметра можно указать необходимую ветку для ответвления git checkout -b some-awesome-feature master

Список своих веток можно посмотреть по команде git branch -v. На каждую из них можно переключится по команде git checkout %branchname%, например

git checkout master

Вернет вас на основную ветку. Имя текущей ветки можно посмотреть в git status, в большинстве случаев оно будет так же сразу отображено в консоли.

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

• Если это случайные, не нужные изменения, можно их сбросить командой git checkout .
• Спрятать изменения через git stash
• Если это часть работы (например, работали над фичей и возникла необходимость переключиться на другую ветку), то возможно лучшим способом будет их просто закомментить.

Обновляем ветку

Пока мы работали с локальным репозиторием, в центральном репозитории могло уже что-то изменится. Обновим нашу ветку с апстрим мастером:

git pull upstream master

Если было что обновлять, то откроется тектовый редактор и предложит отредактировать название для merge-коммита. Можно оставить дефолтный, так что сохраняем/закрываем.
Желательно это так же делать в дальнейшем перед самым ПР-ом, и аналогично придется делать в случае возникновения конфликтов в ПР-е (придется мержить).

Фиксируем изменения

Данный гайд не затрагивает DreamMaker, так что предположим вы уже закодили и протестировали свою фичу. Пора коммитить!
Проверяем изменения через

git status

Мы увидим список всех измененных/добавленных файлов. Можно посмотреть изменения построчно с git diff, или воспользоваться какой-нибудь утилитой вроде gitk (скорее всего у вас он уже есть, так что достаточно просто ввести в консоли).

Перед коммитом нужно отметить необходимые для коммита файлы через git add (добавить в "индекс"). Добавлять файлы по одному (для удобства можно пользоваться автодополнением по TAB-у, он здорово помогает):

git add path/to/file/file.dm

Либо же отметить сразу все изменения:

git add .

Через git status мы увидим список добавленных файлов, и если всё ок - делаем коммит:

git commit -m "Ваше описание коммита"

В названии желательно подробно и доступно описывать, что было измененно, и зачем. Если это был фикс бага из трекера - нужно прописать в названии "Fixes #номер" - гитхаб понимает такие коммиты, и в дальнейшем сам проставит ссылку с номера на баг в багтрекере, а после мержа сам закроет баг.

Отправляем изменения

Пока мы только зафиксировали изменения локально, теперь нужно показать их миру и отправить в форк гитхаба. При условии, если мы этого еще не делали, и у нас не создана в репозитории нужная ветка:

git push -u origin some-awesome-feature

Создаст ветку some-awesome-feature в вашем репозитории на гитхабе, закинет туда наши коммиты. Флаг -u нужен, что бы зафиксировать связь между нашей локальной и удаленной ветками. При следующих можно будет просто указать git push, либо для надежности при работе сразу с несколькими ветками/репозиториями - git push origin some-awesome-feature

Создаем PR

Теперь остается только сделать "запрос на изменения" - предложить какие-то коммиты из форка в основной репозиторий.
На странице https://github.com/TauCetiStation/TauCetiClassic жмем New pull request, затем выбираем "compare across forks".
В списке слева, в качестве base fork, выбираем куда мы хотим отправить изменения. В нашем случае это TauCetiClassic/TauCetiClassic. В списке справа, head fork - ваш репозиторий и ветка, в которую вы только что закоммитили изменения.

После описания своего ПРа, вы должны самостоятельно написать чейнджлог, который будет виден в игре. При создании ПРа стоит придерживаться определённых норм, а именно: избегать употребления сленга, нецензурной брани и стараться избегать многократного употребления одних и тех же слов, последнее применительно только к чейнджлогу. Чейнджлог генерируется автоматически сразу после мержа изменений. Далее будет по пунктам расписано как это делается.

• Ключевым моментом для чейнджлога является метка :cl: . Всё что идёт после неё будет считаться обработчиком за чейнджлог, который и будет высвечиваться в игре. Через пробел можно написать свой ник, но это целесообразно только в том случае, если имя аккаунта на гитхабе и в игре различаются. В случае, если вы лишь посредник при публикации ПРа (просите внести кем-то нарисованные спрайты), то хорошим тоном будет вписать профиль того человека.

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

• - bugfix: тут описываются различные фиксы;

• - rscadd: в эту группу стоит вписывать какие-либо нововведения влияющие коренным образом на игровой процесс или именуемые просторечным словом - фичи;

• - rscdel: откаты фичь, удаление старого или ненужного и так далее;

• - image: всё что касается визуальной составляющей уйдёт в эту группу;

• - sound: звуки и всё что с ними связано будут тут;

• - spellcheck: исправления в тексте;

• - tweak: изменения влияющие на игровой процесс незначительно, вроде какой-то единичной возможности (смять банку, например);

• - balance: затрагивая игровой баланс смело пишите сюда;

• - map: изменения на карте;

• - performance: всё что влияет на производительность, скорость работы и прочее;

• - experiment: если вы сомневаетесь в том, что ваше нововведение приживётся на сервере, то эта группа для вас!

Стоит оговорить, что текста в чейнджлоге должно быть немного, но и информативность должна быть сохранена по-максимуму. Если сомневаетесь в том, что сможете уложиться в короткое описание, то смело приписывайте к своей группе [link], таким образом, вы создадите ссылку ведущую на ваш ПР, где уже можете всё расписать в мельчайших деталях. Она добавится в конце описания конкретного пункта чейнджлога в виде гипер-ссылки. Как это должно выглядеть на практике можно увидеть в далее приложенном примере.

На этом всё. Нажимаем "Create pull request". Готово! После создания ПРа :cl: заменится на эмодзи.

Пример

Текст с описанием вашего ПРа.
:cl:
- bugfix: Фикс невозможности сделать какое-либо действие.
- rscadd[link]: Добавлена куча ранее невиданных фич, описание каждой выльется во второй том произведения "Мёртвые души". (тут будет добавлено "- подробнее -", что и будет являться гипер-ссылкой)

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

Немного о merge (слиянии изменения)

...в процессе (кто нибудь, заполните пожалуйста)...

Полезные советы

1. Создавая ветку, можно в качестве параметра сразу указать удаленный репозиторий и ветку:

git checkout -b some-awesome-feature upstream/master

Сразу создаст ветку на основе upstream/master, без необходимости дополнительно обновлять.

2. При обновлении и мерже изменений с апстримом, можно использовать флаг rebase - избавит от лишних коммитов в истории вида "юзернейм слил мастер в свою ветку"

git pull --rebase upstream master

Данная комманда возьмет ваши коммиты, и перебазирует их поверх обновления. Можно подобное, и не только, проворачивать самостоятельно с командой rebase, но с ней стоит работать очень осторожно.
Потом, если вы попробуете отправить изменения в удаленный репозиторий, где уже были какие-то изменения, гит скорее всего будет ругаться - после rebase для него это 2 разные ветки, которые нужно мержить. Потому просто перезаписываем удаленную ветку, выполняя push с флагом --force

git push --force

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

git commit --amend

Все изменения попадут в последний коммит. Можно так же сразу поменять название:

git commit --amend -m "Новое название коммита"

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

git push --force

Напоследок

Это довольно поверхностное описание без углубления в детали и другие возможности git. Ознакомится подробнее можно в многочисленных гайдах на просторах интернета, как пример: https://git-scm.com/book/ru/v1

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