Git/GitHub: различия между версиями

Материал из Tau Ceti Station Wiki
Перейти к навигации Перейти к поиску
м
(Добавил новые разделы чеинжлога для перевода (их Киборг три тысячи лет назад делал))
 
(не показано 5 промежуточных версий 4 участников)
Строка 4: Строка 4:
*https://github.com/Baystation12/Baystation12 билд Baystation12
*https://github.com/Baystation12/Baystation12 билд Baystation12
*https://github.com/tgstation/-tg-station билд TG
*https://github.com/tgstation/-tg-station билд TG
*https://github.com/TauCetiStation страничка с репозиториями Таукиты
*https://github.com/TauCetiStation страничка с репозиториями Тау Киты
*https://github.com/animusdev страничка с репозиториями Анимуса
*https://github.com/animusdev страничка с репозиториями Анимуса
*https://github.com/ParadiseSS13/Paradise билд Парадайзов


Регистрируемся по адресу https://github.com/join, подтверждаем email, всё стандартно.
Регистрируемся по адресу https://github.com/join, подтверждаем email, всё стандартно.
Строка 16: Строка 17:
Когда что-то готово, изменения сначала коммитятся (фиксируются) в свой форк, после с форка создается пулл-запрос на принятие изменений в основной репозиторий. PR проходит ревью у мэйнтейнеров проекта (сопровождающих разработчиков), по необходимости вносятся изменения/исправления, и далее, либо принимается, либо отклоняется.
Когда что-то готово, изменения сначала коммитятся (фиксируются) в свой форк, после с форка создается пулл-запрос на принятие изменений в основной репозиторий. PR проходит ревью у мэйнтейнеров проекта (сопровождающих разработчиков), по необходимости вносятся изменения/исправления, и далее, либо принимается, либо отклоняется.


==== Создаем PR ====
==== О issue ====
Теперь остается только сделать "запрос на изменения" - предложить какие-то коммиты из форка в основной репозиторий.<br />
В это понятие входит 2 термина:
# Баги;
# Предложения (Proporsal).
Для того чтобы создать ''issue'' (далее ишью), вам необходимо перейти на соответствующею [https://github.com/TauCetiStation/TauCetiClassic/issues страницу] и нажать на кнопу "'''New issue'''". То, как должны оформляться баги достаточно подробно расписано при создании самого ишью.
 
Предложения же оформляются в свободной форме. Тут могут быть как просьбы добавить что-либо в игру, так и оные на портирование каких-либо фич с других серверов. Хорошим тоном будет в начале заголовка добавить '''[Proporsal]'''.
 
==== О Pull request'ах ====
''Pull request'' в переводе значит - "запрос на изменения", что в свою очередь означает - предложить какие-то коммиты из форка в основной репозиторий.<br />
На странице https://github.com/TauCetiStation/TauCetiClassic жмем New pull request, затем выбираем "compare across forks".<br />
На странице https://github.com/TauCetiStation/TauCetiClassic жмем New pull request, затем выбираем "compare across forks".<br />
В списке слева, в качестве base fork, выбираем '''куда''' мы хотим отправить изменения. В нашем случае это <code>TauCetiClassic/TauCetiClassic</code>. В списке справа, head fork - ваш репозиторий и ветка, в которую вы только что закоммитили изменения.
В списке слева, в качестве base fork, выбираем '''куда''' мы хотим отправить изменения. В нашем случае это <code>TauCetiClassic/TauCetiClassic</code>. В списке справа, head fork - ваш репозиторий и ветка, в которую вы только что закоммитили изменения.
Строка 23: Строка 32:
После описания своего ПРа, вы должны самостоятельно написать чейнджлог, который будет виден в игре. При создании ПРа стоит придерживаться определённых норм, а именно: избегать употребления сленга, нецензурной брани и стараться избегать многократного употребления одних и тех же слов (последнее применительно только к чейнджлогу). Чейнджлог генерируется автоматически сразу после мержа изменений. Далее будет по пунктам расписано как он составляется.
После описания своего ПРа, вы должны самостоятельно написать чейнджлог, который будет виден в игре. При создании ПРа стоит придерживаться определённых норм, а именно: избегать употребления сленга, нецензурной брани и стараться избегать многократного употребления одних и тех же слов (последнее применительно только к чейнджлогу). Чейнджлог генерируется автоматически сразу после мержа изменений. Далее будет по пунктам расписано как он составляется.


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


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


*<code>- experiment:</code> в данном разделе нужно описывать изменения, вероятность отката которых, вы не исключаете;
*<code>- experiment:</code> в данном разделе нужно описывать изменения, вероятность отката которых, вы не исключаете;
*<code>- ru:</code> изменения, касающиеся перевода; (вместо ru также можно использовать localization)


Стоит оговорить, что текста в чейнджлоге должно быть немного, но и информативность должна быть сохранена по-максимуму. Если вы уверены, что не уложитесь в понятие ''краткость'', то вы можете воспользоваться маркером  <code>[link]</code> , который нужно добавить к конкретной группе. Маркер даст указание обработчику в автоматическом порядке дописать к чейнджлогу гипер-ссылку ведущую на ваш ПР, в котором вы можете спокойно разгуляться с описанием. Как это должно выглядеть на практике можно увидеть в далее приложенном примере.
Стоит оговорить, что текста в чейнджлоге должно быть немного, но и информативность должна быть сохранена по-максимуму. Если вы уверены, что не уложитесь в понятие ''краткость'', то вы можете воспользоваться маркером  <code>[link]</code> , который нужно добавить к конкретной группе. Маркер даст указание обработчику в автоматическом порядке дописать к чейнджлогу гипер-ссылку ведущую на ваш ПР, в котором вы можете спокойно разгуляться с описанием. Как это должно выглядеть на практике можно увидеть в далее приложенном примере.
'''Важно:''' [link] - это всего лишь маркер для обработчика . В саму метку НИЧЕГО помещать не надо, ссылка получается АВТОМАТИЧЕСКИ обработчиком в процессе генерации чейнджлога.


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

Текущая версия на 18:33, 7 июля 2021

Github

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

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

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

Краткий курс

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

О issue

В это понятие входит 2 термина:

  1. Баги;
  2. Предложения (Proporsal).

Для того чтобы создать issue (далее ишью), вам необходимо перейти на соответствующею страницу и нажать на кнопу "New issue". То, как должны оформляться баги достаточно подробно расписано при создании самого ишью.

Предложения же оформляются в свободной форме. Тут могут быть как просьбы добавить что-либо в игру, так и оные на портирование каких-либо фич с других серверов. Хорошим тоном будет в начале заголовка добавить [Proporsal].

О Pull request'ах

Pull request в переводе значит - "запрос на изменения", что в свою очередь означает - предложить какие-то коммиты из форка в основной репозиторий.
На странице 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: в данном разделе нужно описывать изменения, вероятность отката которых, вы не исключаете;
  • - ru: изменения, касающиеся перевода; (вместо ru также можно использовать localization)

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

Важно: [link] - это всего лишь маркер для обработчика . В саму метку НИЧЕГО помещать не надо, ссылка получается АВТОМАТИЧЕСКИ обработчиком в процессе генерации чейнджлога.

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

Пример

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

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