Этот ответ пытается понять, как заинтересовать старших программистов git, а не о том, как учить gitсамый быстрый способ - для этого отличная книга по git - это замечательно, или любое количество учебников (=> Google). Хорошие ссылки для ответа на этот вопрос: Git - это чисто функциональная структура данных или, в частности, краткая информация о том, как git хранит ваши данные .
Боюсь, у меня довольно мрачный взгляд на это. Я был точно в твоей шкуре - я gitботаник и хотел превратить команду из svnс, давайте посмотрим правде в глаза, крошечные результаты. В моем случае это привело к тому, что я активно изменил свое собственное восприятие и признал, что людей просто нельзя «принуждать к счастью». Люди не компьютеры, их невероятно сложно программировать. Я все еще счастлив, что попробовал, он довольно мягко показал мне, что я делаю и чего не хочу делать в своей профессиональной жизни.
Есть люди, которые начинают мотивироваться, когда появляются новые вещи, и есть те, кто демотивирован. Это не имеет ничего общего git, но, в gitчастности, у вас всегда есть эффект «зачем вообще его использовать, если все svnхорошо?», Что является серьезным психологическим барьером.
Кроме того, настоящий гроккинг gitтребует интенсивного интереса к абстрактным структурам данных. Это может показаться невероятным, но, по моему опыту, есть программисты, которые вообще не интересуются этим, и которым скучно и перегружено элементами, более сложными, чем простые массивы. Вы можете спорить взад и вперед, должны ли они делать ту работу, которую они делают, но это так и есть.
Если люди не заинтересованы в этом, они этого не поймут. Легко и просто. Держу пари, что незаинтересованность - главная причина плохих оценок в школе, а не недостатка интеллекта.
Тем не менее, здесь будет учебный план, как я бы его применил, основанный на накоплении знаний снизу вверх. Это не сработало для меня, но вы можете взять это как вдохновение, чтобы свернуть свое собственное.
графический интерфейс пользователя
Хотя следующему подходу не обязательно требуется поддержка GUI для действий ( git addв репозитории hello world ...), он чрезвычайно помогает иметь графический интерфейс для визуализации репозитория с самого начала. Если вы не можете решить, какой из них использовать, тогда используйте в gitkкачестве последнего средства. Если ваши ребята используют какой-либо визуальный редактор, найдите их gitграфический компонент.
(Статическая) структура данных является ключевой
Начните с объяснения внутренних типов данных (их только три плюс один: BLOB-объектов, деревьев, коммитов, аннотированных тегов, последний из которых не имеет значения на данном этапе) и их структура. Вы можете легко сделать это на доске / карандашом; дерево легко нарисовать, так как его нельзя изменить, вы можете буквально все время добавлять вещи. Вы можете выполнить сеанс воспроизведения в только что созданном локальном репозитории и использовать его git cat-fileдля просмотра реальных объектов, чтобы показать им, что они на самом деле так же тривиальны, как рекламируются.
Если вы можете помочь им понять, что
- ... в истории буквально всего 3 типа объектов, все они очень простые, почти тривиальные и
- ... большинство
gitподкоманд просто «массируют» эти объекты тем или иным способом с почти тривиальными операциями (в основном, есть только один: добавить новый коммит где-нибудь), и ...
- ... все можно легко увидеть прямо перед вами
lsи git cat-file...
тогда у них будет мысленный перевод того, что на самом деле находится в хранилище. На этом этапе пожилые люди могут помнить, что внутренности - svnэто тайная магия (когда-либо возникали проблемы с блокировками внутри репозитория svn или с «реинтегрирующимися» ветвями и т. Д.), И это может лишь немного их мотивировать.
Одна из проблем, особенно у людей, привыкших к этому svn, состоит в том, чтобы привыкнуть к идее, что один коммит (объект, а не действие) всегда представляет собой целое дерево каталогов. В svn, люди используются для фиксации отдельных файлов. Это принципиально другой подход. Да, и тот факт, что один и тот же термин «коммит» используется как для статического объекта, так и для действия, тоже не помогает.
Другая проблема для svnпарней заключается в том, что svnиспользуется линейная история, а не дерево. Это опять дико по-другому. Так что это время , чтобы указать эти различия много .
Действия объяснены с точки зрения структуры
Когда они поняли, из каких частей сделан gitрепозиторий, пришло время показать им , что именно делают отдельные gitподкоманды в отношении них.
Я говорю о том add, commitв сочетании с локальной рабочей директорией и на стадии (убедитесь , что они понимают , что рабочий каталог не такие же , как плацдарм , которая не является таким же , как хранилище).
Когда они поняли, что эти команды просто растут дерево (которое, опять же, на данном этапе, состоит из 3 типов - BLOB-объектов, деревьев, коммитов, а не только коммитов), вы можете выполнить первый git pushи git pull(в режиме ускоренной перемотки! ) показать им, что они gitбуквально только перемещают свои объекты, что хеши на самом деле являются только хешами содержимого, что вы можете легко скопировать этот материал с помощью команды копирования файловой системы и так далее.
Очевидно, держитесь подальше от любых необязательных опций этих команд, о которых мы здесь говорим git add hello.txt.
ветви
Обратите внимание, что ветвление особенно сложно для svnлюдей, так как оно совершенно другое. svnМодель намного легче визуализировать, так как там в основном нет ничего , чтобы визуализировать - это в виду. gitМодель не так много. Убедитесь, что они с самого начала знают, что ветви и теги - это просто «липкие заметки», указывающие куда-то, и на самом деле «не существуют» в терминах статической неизменной истории.
Затем делайте пример за простым примером, чтобы показать, что вы на самом деле можете сделать с ними. Как вы сами, кажется, привыкли git, у вас не должно быть проблем с поиском мотивации там. Убедитесь, что они всегда рассматривают это с точки зрения того, как растет дерево.
Если у них есть это, вы можете объяснить, как git pullна самом деле git fetch && git merge; как все репозитории на самом деле содержат одни и те же объекты ( git fetchэто почти то же самое, что копирование содержимого scpвнутри каталога объектов git) и так далее.
Вероятно, если к этому времени вы еще не пробудились, чтобы пробудить их интерес, то вы можете с тем же успехом сдаться, но если им удастся продвинуться так далеко, тогда в их распоряжении будут все умственные инструменты, и их должно быть немного. страх включается больше. Остальное (рабочий процесс git ...) должно быть под гору.
Последние слова
Это звучит как много усилий, и это действительно так. Не продавайте это как «нам нужно это для этого проекта», но «это поможет вам лично развиваться и поможет вам во всех ваших дальнейших взаимодействиях». Вам нужно много времени для этого, а время это деньги. Если у вас нет одобрения со стороны руководства, это может просто не стоить того; возможно, вам следует обсудить это со своим боссом.
Если вы решили, что хотите отказаться от обучения разработчиков, которые, по-видимому, не в состоянии это понять, но вы обязательно должны их использовать gitв будущем, рассмотрите возможность замены всего взаимодействия с gitкомандами на готовые сценарии или некоторый графический интерфейс, который убирает все gitдетали. Добавьте в сценарии все средства контроля ошибок и т. Д. И попытайтесь заставить это работать.