[Перевод] Как научить людей использовать 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. Ваши локальные коммиты будут воспроизведены, так что вы не увидите в истории коммитов известную форму бриллианта.
Можете добавить в среду разработки ещё одну область, чтобы проще прятать накопленные изменения: грязный рабочий каталог.
Когда люди усвоят эти понятия, вам будет легче объяснить дальнейшее: ветви, историю коммитов, перебазировку и так далее, потому что прочный фундамент уже заложен.
Я работала с другими системами управления версиями (Visual SourceSafe, TFS и Subversion): по моему скромному опыту, недостаток знаний вредит и со старым инструментом, и с новым. Сосредоточьтесь не только на выборе инструмента, но и на его освоении.
Мой друг Марк Виллаграса напомнил, что очень полезно решить задачки Git и делиться с коллегами решением.
Ресурсы из комментариев на Hacker News:
Прочитав комментарии на Reddit, я подумала, что более точным названием этой статьи было бы «Идея, как научить людей использовать Git», потому что это только идея, которая появилась в моей голове, когда я сама несколько лет назад изучала Git по книге Pro Git. Статья не является полным руководством, лишь отправная точка. Уверена, что все эти ресурсы будут очень полезны. Спасибо!
И спасибо Стюарту Максвеллу, который поделился ссылкой на Hacker News, и u/cryptoz, который запостил её на Reddit!
