Как научить людей использовать Git

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

Они не знали, зачем. Программистам просто сказали строго следовать инструкции, иначе беда. Но проблемы возникали так часто, что я решила провести семинар по Git.

Идея

Мне нравится составлять карту в голове. Я не говорю «ментальные карты», потому что это хорошо известный тип диаграмм. Речь о неких картинках, структурах или любом графическом представлении в уме. Например, в детстве я учила арифметику, представляя игральные кубики.

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

Кроме того, очень важно научить человека терминам. Иначе он не поймёт сообщения от Git. Рисунки — хороший способ.

Распределенная система контроля версий

На рисунке четыре области распределены следующим образом:

• Среда разработки:
  • Рабочий каталог
  • Промежуточная область (staging) или индекс
  • Локальный репозиторий
• Сервер:
  • Удалённый репозиторий

Здесь можно объяснить преимущества распределённой системы управления версиями.

Клонирование репозитория

При клонировании данные из удалённого репозитория перемещаются в две области:

• Рабочий каталог
• Локальный репозиторий

Внесение изменений в рабочий каталог

В рабочем каталоге два типа файлов:

• Отслеживаемые: файлы, о которых знает Git.
• Неотслеживаемые: которые ещё не были добавлены, поэтому Git не знает о них.

Обновление удаленного репозитория

После подготовки изменений в рабочем каталоге их необходимо добавить в промежуточную область (staging area).

Когда там накопился ряд изменений с общей целью, самое время создать в локальном репозитории коммит с сообщением об этой цели.

Если в локальном репозитории есть один или несколько коммитов, готовых к совместному использованию всем остальным миром, они отправляются в удалённый репозиторий.

В этот момент можно говорить о различных состояниях файла в среде разработки: изменённом, промежуточном (staged) и зафиксированном (commited).

Далее вы можете объяснить:

• как показать изменения файла в рабочем каталоге: git diff
• как показать изменения файла в промежуточной области: git diff --staged
• как изменить файл в рабочем каталоге после добавления в промежуточную область
• и т. д.

Обновление среды разработки

Получение (fetching)

При выполнении git fetch данные из удалённого репозитория перемещаются только в локальный репозиторий.

Вытягивание (pulling)

При выполнении git pull данные из удалённого репозитория перемещаются в две области:

• В локальный репозиторий: fetch
• В рабочий каталог: merge

Если важна история коммитов, рассмотрите возможность использования git pull --rebase. Тогда вместо команд fetch + merge выполняются команды fetch + rebase. Ваши локальные коммиты будут воспроизведены, так что вы не увидите в истории коммитов известную форму бриллианта ^[1].

Дальнейшие действия

Можете добавить в среду разработки ещё одну область, чтобы проще прятать накопленные изменения: грязный рабочий каталог.

Когда люди усвоят эти понятия, вам будет легче объяснить дальнейшее: ветви, историю коммитов, перебазировку и так далее, потому что прочный фундамент уже заложен.

Дружеское напоминание

Я работала с другими системами управления версиями (Visual SourceSafe, TFS и Subversion): по моему скромному опыту, недостаток знаний вредит и со старым инструментом, и с новым. Сосредоточьтесь не только на выборе инструмента, но и на его освоении.

Дальнейшее чтение

• Книга Pro Git ^[2]

Полученные отзывы

Мой друг Марк Виллаграса ^[3] напомнил, что очень полезно решить задачки Git ^[4] и делиться с коллегами решением.

Ресурсы из комментариев на Hacker News ^[5]:

• Величайшее изобретение Линуса Торвальдса ^[6]
• Лекция Линуса Торвальдса о Git ^[7]
• Linux.conf.au 2013 — Git для детей от 4 лет ^[8]
• Git от начала до конца ^[9]
• Git от начала до конца (PDF) ^[10]
• Изучаем ветвления Git ^[11]
• Правила полётов для git ^[12]
• Пакет Emacs: Magit ^[13]
• Как написать хорошее сообщение для коммита ^[14]
• Станьте гуру git ^[15]
• Погружение в Git ^[16]
• Udacity: как использовать Git и GitHub ^[17]

Прочитав комментарии на Reddit ^[18], я подумала, что более точным названием этой статьи было бы «Идея, как научить людей использовать Git», потому что это только идея, которая появилась в моей голове, когда я сама несколько лет назад изучала Git по книге Pro Git ^[2]. Статья не является полным руководством, лишь отправная точка. Уверена, что все эти ресурсы будут очень полезны. Спасибо!

И спасибо Стюарту Максвеллу ^[19], который поделился ссылкой на Hacker News, и u/cryptoz ^[20], который запостил её на Reddit!

Автор: m1rko

Источник ^[21]