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

Материал из Tau Ceti Station Wiki
Перейти к навигации Перейти к поиску
м (Как я это вообще нашёл?)
 
(не показано 11 промежуточных версий 5 участников)
Строка 1: Строка 1:
{{wip}}
Небольшое руководство по консольному git. Часть про установку рассчитана на Windows, часть про работу с Github будет актуальна и для пользователей гуи-интерфейсов.


Общее небольшое руководство по github-у и консольному git.<br />
Есть много различных GUI-клиентов, например [https://tortoisegit.org/ TortoiseGit] (на [https://tgstation13.org/wiki/Setting_up_git вики tg-станции] есть подробный обновляемый гайд), [https://www.sourcetreeapp.com/ SourceTree].
Часть про установку рассчитана на Windows, часть про работу с Github будет актуальна и для пользователей гуи-интерфейсов.
 
Есть много различных GUI-клиентов, например [https://tortoisegit.org/ TortoiseGit] (на [https://tgstation13.org/wiki/Setting_up_git вики tg-станции] есть подробный обновляемый гайд), [https://www.sourcetreeapp.com/ SourceTree].<br />
Мы же в данной статье остановимся по большей части на консольном клиенте git:
Мы же в данной статье остановимся по большей части на консольном клиенте git:
# Сам Git - изначально консольный инструмент. И удобный!
# Сам Git изначально консольный инструмент. И удобный!
# Консоль дает больше возможностей, чем GUI-клиенты.
# Консоль дает больше возможностей, чем GUI-клиенты.
# В GUI-клиентах есть возможность запустить консоль, если понадобится. Так что это универсальная инструкция.
# В GUI-клиентах есть возможность запустить консоль, если понадобится. Так что это универсальная инструкция.
Строка 12: Строка 9:


В любом случае, какой-бы клиент вы не выбрали, в интернете всегда найдется документация и куча различных инструкций.
В любом случае, какой-бы клиент вы не выбрали, в интернете всегда найдется документация и куча различных инструкций.
== 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 клиент, настройка ==
== Git клиент, настройка ==
[[Image:Git-example.png|thumb|350px|Пример Posh-Git на Windows 8.]]
[[Image:Git-example.png|thumb|350px|Пример Posh-Git на Windows 8.]]
Гитхаб — наиболее популярный в сообществе станции хостинг репозиториев. Более подробнее в [[Git/GitHub]]


Самый простой способ - поставить Github for windows все с того же гитхаба: https://desktop.github.com/<br />
Регистрируемся по адресу https://github.com/join, подтверждаем email, всё стандартно.<br>
Да, это графический клиент, и если работа с консолью не понравится, можете попробовать использовать его. На деле же нам потребуется запустить его только раз для настройки.<br />
'''''Важно:''' email, который вы укажете при регистрации, в дальнейшем будет указан под каждым вашим коммитом на гитхабе. Если не хотите светить — зарегистрируйте отдельный.''
Но что нас интересует больше - это идущие в комплекте [http://git-scm.com/downloads Git] (сам клиент) и [https://github.com/dahlbyk/posh-git Posh-Git] (расширение для Windows Powershell, не обязательно но крайне полезно - автодополнение по TAB и подсветка), самостоятельная установка и настройка которых может вызвать сложности (кому не хватает приключений - в интернете можно найти инструкции).


Итак, запускаем с рабочего стола GitHub, логинимся под своим зарегестрированным ранее аккаунтом, пропускаем шаг с локальными репозиториями.<br />
Самый простой способ начать — скачать git с официального сайта: https://git-scm.com/downloads
Осталось только зайти в Options, и выбрать место для хранения репозиториев.<br />
Всё, можете закрыть и забыть про гуи, и с рабочего стола запустить Git Shell.


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


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


Строка 59: Строка 36:
git clone https://github.com/%аккаунт%/TauCetiClassic.git tauceticlassic
git clone https://github.com/%аккаунт%/TauCetiClassic.git tauceticlassic
</pre>
</pre>
По окончанию клонирования у вас будет актуальный билд в папке <code>tauceticlassic/</code>, с которым можно уже работать в DreamMaker-е. Прежде всего, для продолжения работы в консоли, вам необходимо сделать вход в папку, написав в ней <code>cd %имя папки%</code><br />
По окончанию клонирования у вас будет актуальный билд в папке <code>tauceticlassic</code>, с которым можно уже работать в DreamMaker-е. Прежде всего, для продолжения работы в консоли, вам необходимо сменить рабочую папку, написав <code>cd tauceticlassic</code>
'''Важно''': после клонирования билда Тау Киты, стоит выполнить команду:
 
<pre>
git update-index --assume-unchanged taucetistation.int
</pre>
==== Подключаем удаленный репозиторий ====
==== Подключаем удаленный репозиторий ====
Время от времени необходимо обновлять свой репозиторий с центрального. Это нужно делать, например, в случае возникновения конфликтов (если, пока вы пилили фичу, кто-то успел в аналогичных файлах внести свои изменения), и просто для профилактики.<br />
Время от времени необходимо обновлять свой репозиторий с центрального. Это нужно делать, например, в случае возникновения конфликтов (если, пока вы пилили фичу, кто-то успел в аналогичных файлах внести свои изменения), и просто для профилактики.
Традиционно центральный репозиторий именуется как <code>upstream</code> (или апстрим), но никто не мешает подобрать своё имя, к тому же никто не мешает иметь подключенными сразу несколько удаленных репозиториев. Кстати, после <code>git clone ...</code> у вас уже есть 1 подключенный удаленный репозиторий под названием <code>origin</code>, ссылающийся на репозиторий, который вы клонировали (ваш форк на гитхабе).<br />
 
Традиционно центральный репозиторий именуется как <code>upstream</code> (или апстрим), но никто не мешает подобрать своё имя, к тому же никто не мешает иметь подключенными сразу несколько удаленных репозиториев. Кстати, после <code>git clone ...</code> у вас уже есть 1 подключенный удаленный репозиторий под названием <code>origin</code>, ссылающийся на репозиторий, который вы клонировали (ваш форк на гитхабе).
 
Подключим центральный репозиторий Тау Киты:
Подключим центральный репозиторий Тау Киты:
<pre>
<pre>
Строка 75: Строка 51:
git fetch upstream
git fetch upstream
</pre>
</pre>
Можете посмотреть список своих удаленных репозиториев по команде <code>git remote -v</code><br />
Можете посмотреть список своих удаленных репозиториев по команде <code>git remote -v</code>


==== Создаем ветку, переключаем ветки ====
==== Создаем ветку, переключаем ветки ====
Ветка, или же branch - ссылка на определенное состояние репозитория.
Ветка, или же branch ссылка на определенное состояние репозитория.
Изначально у вас есть основная ветка <code>master</code>, как правило это актуальная рабочая версия, которая и стоит на сервере.<br />
Изначально у вас есть основная ветка <code>master</code>, как правило это актуальная рабочая версия, которая и стоит на сервере.
Но при активной работе над билдом, предпочтительно её не трогать, и создавать для каждого фикса\фичи свою отдельную ветку.
Но при активной работе над билдом, предпочтительно её не трогать, и создавать для каждого фикса\фичи свою отдельную ветку.
<pre>
<pre>
git checkout -b some-awesome-feature
git checkout -b some-awesome-feature
</pre>
</pre>
Создаст ответвление от вашей текущей ветки с названием <code>some-awesome-feature</code>, и переключится на неё. <br />
Создаст ответвление от вашей текущей ветки с названием <code>some-awesome-feature</code>, и переключится на неё.  
'''Важно:''' по умолчанию создается ответвление от '''текущей''' ветки, что может быть неудобно в случае работы сразу над несколькими ветками. В качестве параметра можно указать необходимую ветку для ответвления <code>git checkout -b some-awesome-feature master</code>
'''Важно:''' по умолчанию создается ответвление от '''текущей''' ветки, что может быть неудобно в случае работы сразу над несколькими ветками. В качестве параметра можно указать необходимую ветку для ответвления <code>git checkout -b some-awesome-feature master</code>


Строка 97: Строка 73:
* Если это случайные, не нужные изменения, можно их сбросить командой <code>git checkout .</code>
* Если это случайные, не нужные изменения, можно их сбросить командой <code>git checkout .</code>
* Спрятать изменения через <code>[https://git-scm.com/book/ru/v1/%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B-Git-%D0%9F%D1%80%D1%8F%D1%82%D0%B0%D0%BD%D1%8C%D0%B5 git stash]</code>
* Спрятать изменения через <code>[https://git-scm.com/book/ru/v1/%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B-Git-%D0%9F%D1%80%D1%8F%D1%82%D0%B0%D0%BD%D1%8C%D0%B5 git stash]</code>
* Если это часть работы (например, работали над фичей и возникла необходимость переключиться на другую ветку), то возможно лучшим способом будет их просто закомментить.
* Если это часть работы (например, работали над фичей и возникла необходимость переключиться на другую ветку), то возможно лучшим способом будет их просто закоммитить.


==== Обновляем ветку ====
==== Обновляем ветку ====
Строка 104: Строка 80:
git pull upstream master
git pull upstream master
</pre>
</pre>
Если было что обновлять, то откроется тектовый редактор и предложит отредактировать название для merge-коммита. Можно оставить дефолтный, так что сохраняем/закрываем.<br />
Если было что обновлять, то откроется тектовый редактор и предложит отредактировать название для merge-коммита. Можно оставить дефолтный, так что сохраняем/закрываем.
Желательно это так же делать в дальнейшем перед самым ПР-ом, и аналогично придется делать в случае возникновения конфликтов в ПР-е (придется мержить).
Желательно это так же делать в дальнейшем перед самым ПР-ом, и аналогично придется делать в случае возникновения конфликтов в ПР-е (придется мержить).


==== Фиксируем изменения ====
==== Фиксируем изменения ====
Данный гайд не затрагивает DreamMaker, так что предположим вы уже закодили и протестировали свою фичу. Пора коммитить!<br />
Данный гайд не затрагивает DreamMaker, так что предположим вы уже закодили и протестировали свою фичу. Пора коммитить!
Проверяем изменения через
Проверяем изменения через
<pre>
<pre>
Строка 125: Строка 101:
</pre>
</pre>


Через <code>git status</code> мы увидим список добавленных файлов, и если всё ок - делаем коммит:
В случае, если вы зафиксировали не нужный вам файл, то для извлечения из индекса вам необходимо ввести следующею команду:
<pre>
git reset head path/to/file/file.dm
</pre>
 
Через <code>git status</code> мы увидим список добавленных файлов, и если всё ок делаем коммит:
<pre>
<pre>
git commit -m "Ваше описание коммита"
git commit -m "Ваше описание коммита"
</pre>
</pre>
В названии желательно подробно и доступно описывать, что было измененно, и зачем. Если это был фикс бага из трекера - нужно прописать в названии "Fixes #номер" - гитхаб понимает такие коммиты, и в дальнейшем сам проставит ссылку с номера на баг в багтрекере, а после мержа сам закроет баг.
В названии желательно подробно и доступно описывать, что было измененно, и зачем. Если это был фикс бага из трекера нужно прописать в названии "Fixes #номер" гитхаб понимает такие коммиты, и в дальнейшем сам проставит ссылку с номера на баг в багтрекере, а после мержа сам закроет баг.
 
Но стоит учитывать, что коммит получится сделать только в том случае, если не будет не зафиксированных изменений, которые могут появится по тем или иным причинам. Дабы их откинуть, необходимо прописать такую команду:
<pre>
git checkout -- path/to/file/file.dm
</pre>


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


==== Создаем PR ====
О создании ПРа стоит прочитать в [[Git/GitHub|этой]] статье
Теперь остается только сделать "запрос на изменения" - предложить какие-то коммиты из форка в основной репозиторий.<br />
На странице https://github.com/TauCetiStation/TauCetiClassic жмем New pull request, затем выбираем "compare across forks".<br />
В списке слева, в качестве base fork, выбираем '''куда''' мы хотим отправить изменения. В нашем случае это <code>TauCetiClassic/TauCetiClassic</code>. В списке справа, head fork - ваш репозиторий и ветка, в которую вы только что закоммитили изменения.
 
После описания своего ПРа, вы должны самостоятельно написать чейнджлог, который будет виден в игре. При создании ПРа стоит придерживаться определённых норм, а именно: избегать употребления сленга, нецензурной брани и стараться избегать многократного употребления одних и тех же слов (последнее применительно только к чейнджлогу). Чейнджлог генерируется автоматически сразу после мержа изменений. Далее будет по пунктам расписано как он составляется.
 
* Ключевым моментом для чейнджлога является метка <code>:cl:</code> . Всё что идёт после неё будет считаться обработчиком за чейнджлог, который и будет высвечиваться в игре. '''(Поэтому важно, чтобы под меткой ничего кроме самих чейнджлогов не было.)''' Через пробел можно написать свой ник, но это целесообразно только в том случае, если имя аккаунта на гитхабе и в игре различаются. В случае, если вы лишь посредник при публикации ПРа (вас попросили залить кем-то нарисованные спрайты), то хорошим тоном будет вписать профиль того человека.
 
Далее речь пойдёт непосредственно о наполнении чейнджлога. Для упрощения восприятия и систематизации, различные нововведения подразделяются на группы, маркеры для которых представлен ниже. Вам необходимо сначала написать маркер, а уже затем описать, что вы сделали:
 
*<code>- bugfix:</code> тут описываются различные фиксы;
 
*<code>- rscadd:</code> в эту группу нужно вносить добавление нового функционала или фичь;
 
*<code>- rscdel:</code> откаты фичь, удаление старого или ненужного и так далее;
 
*<code>- image:</code> всё что касается визуальной составляющей уйдёт в эту группу;
 
*<code>- sound:</code> звуки и всё что с ними связано будут тут;
 
*<code>- spellcheck:</code> исправления/изменения в тексте;
 
*<code>- tweak:</code> изменения влияющие на игровой процесс, но, как правило, базирующиеся на существующем и являющиеся, в общем масштабе, незначительными (настройки чего-то или мелкофичи);
 
*<code>- balance:</code> затрагивая игровой баланс смело пишите сюда;
 
*<code>- map:</code> изменения на карте;
 
*<code>- performance:</code> всё что влияет на производительность игры или работы билда в целом, и прочее;
 
*<code>- experiment:</code> в данном разделе нужно описывать изменения, вероятность отката которых, вы не исключаете;
 
Стоит оговорить, что текста в чейнджлоге должно быть немного, но и информативность должна быть сохранена по-максимуму. Если вы уверены, что не уложитесь в понятие ''краткость'', то вы можете воспользоваться маркером  <code>[link]</code> , который нужно добавить к конкретной группе. Маркер даст указание обработчику в автоматическом порядке дописать к чейнджлогу гипер-ссылку ведущую на ваш ПР, в котором вы можете спокойно разгуляться с описанием. Как это должно выглядеть на практике можно увидеть в далее приложенном примере.
 
На этом всё. Нажимаем "Create pull request". Готово! После создания ПРа <code>:cl:</code> заменится на эмодзи.
 
<div class="toccolours mw-collapsible mw-collapsed" style="width:99%">
Пример
<div class="mw-collapsible-content"><pre>
Текст с описанием вашего ПРа.
:cl:
- bugfix: Фикс невозможности сделать какое-либо действие.
- rscadd[link]: Добавлена куча ранее невиданных фич, описание каждой выльется во второй том произведения "Мёртвые души". (Тут, в игре, будет добавлено "- подробнее -", которое будет являться гипер-ссылкой.)
</pre></div></div>В случае, если вы сделаете что-то неправильно, не стоит пугаться, всегда найдутся те, кто подскажет, а в случае надобности и покажет как сделать правильно.


==== Немного о merge (слиянии изменения) ====
==== Немного о merge (слиянии изменения) ====
...в процессе (кто нибудь, заполните пожалуйста)...
<!-- TODO: что-то нужно? если да, то надо дописать -->
Скорее всего вам редко придётся пользоваться командой git merge, поэтому мы просто оставим [https://git-scm.com/docs/git-merge ссылку на документацию].


== Полезные советы  ==
== Полезные советы  ==
1. Создавая ветку, можно в качестве параметра сразу указать удаленный репозиторий и ветку:
1. Создавая ветку, можно в качестве параметра сразу указать удаленный репозиторий и ветку:
<pre>
<pre>
Строка 197: Строка 139:




2. При обновлении и мерже изменений с апстримом, можно использовать флаг rebase - избавит от лишних коммитов в истории вида "юзернейм слил мастер в свою ветку"
2. При обновлении и мерже изменений с апстримом, можно использовать флаг rebase избавит от лишних коммитов в истории вида "юзернейм слил мастер в свою ветку"
<pre>
<pre>
git pull --rebase upstream master
git pull --rebase upstream master
</pre>
</pre>
Данная комманда возьмет ваши коммиты, и перебазирует их поверх обновления. Можно подобное, и не только, проворачивать самостоятельно с командой rebase, но с ней стоит работать очень осторожно.<br />
Данная комманда возьмет ваши коммиты, и перебазирует их поверх обновления. Можно подобное, и не только, проворачивать самостоятельно с командой rebase, но с ней стоит работать очень осторожно.
Потом, если вы попробуете отправить изменения в удаленный репозиторий, где уже были какие-то изменения, гит скорее всего будет ругаться - после rebase для него это 2 разные ветки, которые нужно мержить. Потому просто перезаписываем удаленную ветку, выполняя push с флагом --force
Потом, если вы попробуете отправить изменения в удаленный репозиторий, где уже были какие-то изменения, гит скорее всего будет ругаться после rebase для него это 2 разные ветки, которые нужно мержить. Потому просто перезаписываем удаленную ветку, выполняя push с флагом --force
<pre>
<pre>
git push --force
git push --force
Строка 214: Строка 156:
<pre>
<pre>
git commit --amend -m "Новое название коммита"
git commit --amend -m "Новое название коммита"
</pre>
Чтобы не изменять название коммита можно воспользоваться опцией --no-edit:
<pre>
git commit --amend --no-edit
</pre>
</pre>


Полезно, если необходимо поправить незначительную ошибку/опечатку, и не хочется засорять историю коммитов. И вообще, держать чистую историю коммитов - хороший тон. Так же как и выше, это изменение истории, закоммитить изменения можно будет как и выше с
Полезно, если необходимо поправить незначительную ошибку/опечатку, и не хочется засорять историю коммитов. И вообще, держать чистую историю коммитов хороший тон. Так же как и выше, это изменение истории, закоммитить изменения можно будет как и выше с
<pre>
<pre>
git push --force
git push --force
Строка 225: Строка 171:
https://git-scm.com/book/ru/v1
https://git-scm.com/book/ru/v1


Git - довольно простая система, необходимых для работы команд не так много, и все можно быстро запомнить. Если что-то пошло не так - всегда можно найти решение в интернете, или спросить у нашей команды разработчиков в [http://chat.tauceti.ru/channel/rnd чате], мы поможем.
Git довольно простая система, необходимых для работы команд не так много, и все можно быстро запомнить. Если что-то пошло не так всегда можно найти решение в интернете, или спросить у нашей команды разработчиков в [https://discord.gg/YCWRjkb чате], мы поможем.

Текущая версия на 17:46, 31 января 2022

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

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

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

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

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

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

Гитхаб — наиболее популярный в сообществе станции хостинг репозиториев. Более подробнее в Git/GitHub

Регистрируемся по адресу https://github.com/join, подтверждаем email, всё стандартно.
Важно: email, который вы укажете при регистрации, в дальнейшем будет указан под каждым вашим коммитом на гитхабе. Если не хотите светить — зарегистрируйте отдельный.

Самый простой способ начать — скачать git с официального сайта: https://git-scm.com/downloads

Краткий курс

Здесь и дальше алгоритм приводится на примере текущего основного репозитория Тау Киты, 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 tauceticlassic

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

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

Традиционно центральный репозиторий именуется как 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 reset head path/to/file/file.dm

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

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

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

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

git checkout -- path/to/file/file.dm

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

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

git push -u origin some-awesome-feature

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

О создании ПРа стоит прочитать в этой статье

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

Скорее всего вам редко придётся пользоваться командой git 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 "Новое название коммита"

Чтобы не изменять название коммита можно воспользоваться опцией --no-edit:

git commit --amend --no-edit

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

git push --force

Напоследок

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

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