Всем привет! Сегодня статья на тему, которая не касается непосредственно разработки плагинов для Revit, но важна для всех, кто занимается программированием — работа с GitHub.
Сразу скажу, что я не являюсь супер-экспертом по гитхабу, да и активно пользуюсь я им всего около полугода, поэтому статья может содержать неточности. Если увидите их — смело пишите в комментарии.
Зарегистрироваться на GitHub можно здесь.
GitHub и Git
Давайте определимся с терминами:
- GitHub — это веб-сайт, на котором хранятся репозитории (есть также мобильное и десктопное приложение)
Соответственно, нам необязательно использовать именно GitHub: мы можем выбрать любое другое хранилище для своих репозиториев. Кроме того, мы можем использовать Git локально: просто создать репозиторий у себя на компьютере, делать в него коммиты, создавать ветки и т.д, не отправляя это всё в интернет.
Репозитории и действия с ними
Репозиторий может быть локальным и удалённым. Большинство действий мы делаем с локальным репозиторием, а с удалённым проводим только синхронизацию — отправляем или принимаем коммиты. Давайте рассмотрим, какие действия существуют:
1. Коммит (фиксация) — фиксирует состояние репозитория на момент совершения коммита, с добавлением текстового описания. Потом можно в любой момент вернуться к этому состоянию и посмотреть, что было там.
Если мы написали сложный код, а потом поняли, что он в этом месте сейчас мешает, но может пригодится позже, мы можем не комментировать его, а сделать коммит и потом вернуться. Код будет чище, а информация не пропадёт.
2. Push (отправка) — отправляет коммиты из локального репозитория в удалённый.
3. Pull (вытягивание) — переносит коммиты из ветви удалённого репозитория в выбранную ветвь локального.
4. Fetch (извлечение) — добавляет в локальный репозиторий те ветви и коммиты, которые есть в удалённом, но отсутствуют в локальном.
5. Создание ветви (branch) — разделяет репозиторий от текущего коммита на 2 ветки. Коммиты в одной не влияют на другую, разработка идёт параллельно.
6. Pull-request (пулл-реквест, запрос на вытягивание). Порядок тут такой: мы создали ветвь, сделали в неё коммит, а затем хотим объединить этот коммит с основной веткой. Тогда мы создаём пулл-реквест на объединение нашей ветки с основной, git проверяет, нет ли там конфликтов, и если нет, то его можно объединить.
7. Merge (слияние) — объединяет ветки (переносит коммиты из одной ветки в другую). Может пройти без конфликтов или с оными. Если возникли конфликты, то слияние нельзя выполнить без их решения.
8. Clone (клонирование) — создаёт копию удалённого репозитория на локальном компьютере.
Сценарии использования
Для одного пользователя
По идее, git вам особо не нужен. Но может быть весьма полезен. Итак, допустим, сценарий такой:
1. Создаём проект (приложение).
2. Добавляем в него плагин.
3. Добавляем ещё плагин.
4. Исправляем первый плагин.
5. Добавляем третий, переписываем второй и т.д.
Каждый такой шаг мы можем зафиксировать в локальном репозитории, и в случае чего либо быстро откатиться назад, либо посмотреть, что мы там делали в начале, для нового проекта.
Чтобы создать локальный репозиторий, выберите Git — Создать репозиторий Git и выберите слева "Только локальный".
Создание репозитория сразу же создаст и первый коммит. Допустим, мы провели ещё работу, написали плагин в приложение, и хотим сделать коммит (ассоциация — сохраниться, как в игре).
Выбираем Вид — Изменения Git. В появившемся окне пишем описание изменения и жмём "Зафиксировать всё" (коммит == фиксация):
Впрочем, в том же окне можно создать сразу и удалённый репозиторий на GitHub. Можно сделать его частным, чтобы никто не видел недоделанные результаты работы.
Откат к предыдущему состоянию (или его просмотр)
Итак, допустим у нас есть несколько коммитов. Выбираем Git — управление ветвями. Затем жмём правой кнопкой мыши на коммит, выбираем --detach:
Мы перейдём в состояние на момент коммита. Далее мы можем вернуться назад в наиболее поздний коммит (посмотрели и вернулись), либо создать новую ветвь и продолжить работу в ней.
Чтобы вернуться, кликнем слева на нашу ветвь правой кнопкой и выберем "Получить для изменения":
Чтобы создать ветвь, выберем Git — Создать ветвь (branch).
Для объединения ветвей просто нажмём "Объединить ветвь". Если конфликтов нет, то слияние произойдёт автоматически. Иначе, их придётся разрешать. Впрочем, откуда взяться конфликтам, если вы пока работаете в одиночку.
Клонирование репозитория с GitHub
Тут всё просто: можно открыть Visual Studio прямо с сайта:
Совместная работа
Принцип: есть одна главная ветвь для работы, с которой все синхронизируются и следят, чтоб она была актуальна и их ветви создавались от актуальной версии. И много-много ветвей для разных дополнительных фич, которые мы разрабатываем, и которые появляются и исчезают (объединяясь с основной).
Алгоритм такой:
1. Жмём Fetch (извлечение), чтобы получить наиболее актуальную версию основной ветки.
2. Создаём локальную ветвь. Правило такое: 1 фича — 1 ветвь. Это может быть написание нового плагина, исправление бага, или выполнение задачи из Jira. У одного программиста может быть много своих ветвей. Над одной веткой могут работать несколько программистов (по очереди).
3. Делаем коммиты в эту ветвь по мере необходимости. Фича простая — один коммит. Фича сложная — несколько. Сделали коммит и увидели лишнюю пустую строку — ничего, стираем и делаем ещё один коммит.
4. Отправляем (Push) наши коммиты на GitHub. Наша новая локальная ветвь станет удалённой ветвью.
5. Далее работаем на сайте GitHub. Заходим на наш репозиторий. Там сразу после пуша появится плашка "Compare and pull request". Жмём на неё:
Далее выбираем, в какую ветку (в основную) мы будем переносить изменения, заполняем описание и создаём пулл-реквест:
6. Проверяем пулл-реквест. Далее второй участник (тим-лид) может проверить, всё ли окей. Можно посмотреть, что изменилось по результатам работы и в каких файлах, оставить комментарии и запросить изменения. Заодно можно посмотреть, нет ли конфликтов, и если есть, разрешить их прямо на сайте.
Можно и самому себе создавать пулл-реквесты, чтобы проверить отсутствие конфликтов и сделать само-ревью, либо проверять друг друга, если работаете в паре.
"А ты даёшь ясные и полные имена переменных, коллега?"
(с) Конфуций, пять постоянств праведного программиста, V век до н.э.
7. Объединяем (Merge) пулл-реквест.
8. Удаляем ветку для фичи (она теперь есть в основной ветке и более не нужна).
9. Теперь каждый разработчик может сделать fetch и синхронизировать основную ветвь до актуального состояния.
Резюме
Главное правило работы с Git, которое надо запомнить: сначала делаем коммит (фиксируем изменения), потом все манипуляции — иначе рискуете затереть свои несохранённые изменения.
Второе правило: Если не поняли, как работает система с пулл-реквестами при работе в команде: спрашиваем товарища или перечитываем статью. Отрабатываем внесение изменений на коммите в 1 пустую строку (удалённую или добавленную). Запомнив порядок действий, работаем с кодом.
Третье правило: увидели хороший репозиторий на GitHub (например, мой :) ) — ставим звёздочку.
А на этом всё! Не забывайте подписываться на мой телеграм-канал и до новых встреч!
