Инструкция по использованию GitHub Enterprise

-Инструкция-.md

У нас появился свой GitHub (пока что без блэкджека и шлюх). Для того, чтобы оценить его, все новые проекты имеет смысл заводить в нём. Разработчикам были отправлены ссылки на регистрацию, все остальные могут свободно смотреть. Аккаунты разработчиков уже созданы, можно воспользоваться восстановлением пароля.

Для полноценной и простой работы надо:

• Через веб-браузер:

  1. Добавить следующие строчки в C:\Windows\System32\drivers\etc\hosts:

     192.168.88.93	mbs.pos		#Micro build server
     

  2. После этого можно пользоваться GitHub через веб-интерфейс по адресу https://pos-github.payonline.ru/

• Для разработки:
  1. Установить удобный графический клиент GitHub for Windows с http://windows.github.com/
  2. В GitHub for Windows указать адрес GitHub Enterprise https://pos-github.payonline.ru/ и ваши логин/пароль к GitHub Enterprise
  3. Обязательно в git shell (в меню "Пуск") выполняем команды git config --global core.autocrlf true и git config --global pull.ff only

Предлагаю следующую схему работы:

• Каждый из разработчиков, работающих над проектом, делает его Fork (в правом верхнем углу на странице репозитория) к себе, и настраивает build server (см. ниже);
• Баги/фичи заводятся в вкладке Issues исходного репозитория (на сайте); указываем в Issue ссылку на исходную задачу в Jira (например, заголовок Issue - "SERVICES-123 Добавить в сервис CurrencyExchange поддержку валюты BTC", текст issue - URL задачи в Jira), в исходной задаче в Jira ссылаемся на Issue на гитхабе;
• Разработчик, работающий над багом/фичей, создаёт ветку с названием feature-456-btc-support, где 456 – номер issue, btc-support – краткое название ветки (название ветки проверяется выражением /^feature-(\d+)(?:-[a-z0-9]+)+$/;
• Коммиты должны быть атомарными; каждое изменение – коммит; изменения регулярно синхронизируются на сервер;
• После окончания работы над фичей разработчик на странице своего репозитория открывает Pull Request для соответствующей ветки; название Pull Request – вида «Closes #456 (implemented BTC support)» (так pull request будет автоматически связан с issue);
• Другой из разработчиков, работающих над этим проектом (или тимлид) по итогам code review принимает или отклоняет pull request. При принятии pull request изменения автоматически мёрджатся в выбранную ветку исходного репозитория (обычно – master), issue автоматически закрывается.

Кроме того, у нас есть build server, реагирующий на все изменения в репозиториях github, который может собирать ваш проект при каждой синхронизации локального репозитория на сервер. Для этого надо:

• В настройках репозитория GitHub добавить в Collaborators пользователя PayOnlineAdmin.
• В настройках репозитория GitHub в web hooks добавить hook с адресом http://mbs.pos/github/postreceive (в будущем это будет происходить автоматически)

Сейчас это выглядит примерно так.

В связи с тем, что билд-сервер сейчас работает на моей машине, возможны тормоза; от синхронизации до обновления статуса на странице репозитория может проходить достаточно много времени. GitHub сейчас работает на специальной виртуалке it-online, с ним тормозов быть не должно.

Как обновить свой форк?

Перед тем, как вносить изменения в проект, над которым одновременно работает много людей, надо обновить свою версию (так, чтобы в неё пришли изменения, внесённые другими людьми), чтобы при открытии Pull Request не было конфликтов. В будущем этот функционал должен появиться одной кнопкой в GitHub for Windows. А пока что для этого надо залезть в консоль (в GitHub for Windows в правом верхнем углу шестерёнка, нажимаем на ней и выбираем Open a Git shell) и выполнить в ней следующие команды:

# Эти две команды надо выполнить, когда хотите синхронизировать свой форк с основным репозиторием.
# Перед этим надо убедиться, что у вас в master нет изменений, не попавших в master основного репозитория;
# если есть - надо либо откатить их (rollback), либо открыть на них pull request.
# Но если вести всю разработку в feature-ветках, изменений в master быть не должно.
git pull upstream master
git push origin master

# При использовании PowerShell можно обойтись одной командой:
git pull upstream master ; git push origin master

Основные команды git.md

git checkout BRANCHNAME - переключает в ветку BRANCH

git checkout -b BRANCHNAME - создаёт новую ветку на основе текущей и переключает в неё

git status - посмотреть, какие файлы изменены (и какие отслеживаются)

git add PATH - добавление файлов для отслеживания (аналогично Include changes в TFS, только на уровне конкретных изменений, а не файлов; по умолчанию все изменения не включены)

git add -A - добавление всех изменений для отслеживания

git diff - посмотреть изменения

git diff --cached - посмотреть изменения отслеживаемых файлов

git commit -m "message" - закоммитить отслеживаемые изменения

git push origin BRANCHNAME - загрузить коммиты в ветке BRANCH на сервер

после принятия pull request

git checkout master (переключаемся на master-ветку)

git pull upstream master ; git push origin master (забираем изменения из master-ветки корневого репозитория в локальный репозиторий и загружаем их в свой репозиторий на сервере)

git branch -D BRANCHNAME (удаляем локальную ветку для старой фичи, если CR закрыт, и все дальнейшие изменения будут вестись только по новым CR / дефектам)