Git/Git-console

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

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

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

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

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

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-е.
Важно: после клонирования билда Тау Киты или Baystation12, стоит выполнить команду:

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

Для /tg/ или репозиториев, базированных на /tg/, это делать не нужно. Это добавит файл baystation12.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 - ваш репозиторий и ветка, в которую вы только что закоммитили изменения.

Описываем свои изменения, по необходимости прикладываем скриншоты, нажимаем "Create pull request". Готово!

Немного о 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 - довольно простая система, необходимых для работы команд не так много, и все можно быстро запомнить. Если что-то пошло не так - всегда можно найти решение в интернете, или спросить у нашей команды разработчиков в чате, мы поможем.