контекст

Моя команда из 8 инженеров в настоящее время переходит на Git (из Subversion) для нашей следующей большой вещи. У нас есть горстка «более опытных» инженеров, которым очень трудно подобрать Git. Мне задают одни и те же тривиальные вопросы, несмотря на то, что я предоставил руководства пользователя, учебные мероприятия и занятия на доске. У нас было два младших консультанта, которые подобрали все за несколько дней, и это действительно пролило свет на проблему. Это не шаблон, ограниченный Git, но в результате он стал видимым.

Вопрос

Я не испытываю особого одобрения к инженерам, которые не могут / не будут учиться, особенно к сотрудникам с тем уровнем старшинства, который у нас здесь есть. Тем не менее, я хочу, чтобы команда преуспела и создала отличный продукт. Мы используем централизованную модель Git Flow, и я чувствую, что вся новая терминология сбивает их с толку.

Могу ли я чем-нибудь помочь этим сотрудникам в изучении Git?

Sourcetree - это клиент, который используется всей командой.

Дайте им игрушку.

Git это сложно. Особенно, если вы выполняете контроль исходного кода в другой парадигме. Я сломал сборку в первый раз, когда попытался работать с git. Это сделало меня настолько параноиком, что я не хотел регистрироваться, пока все не будет сделано. Я прятал версии в папках. Тогда я наконец понял, что мне нужно, чтобы пройти через это:

Мне нужно было безопасное место, чтобы играть.

Получив это, я намеренно создавал проблемы, чтобы научиться их исправлять - все в моем безопасном месте. Я разработал шаблон, который мог бы использовать, даже если его прервали, и все еще возвращался в хорошее состояние. Вскоре ко мне пришли люди за помощью с мерзавцем. Все потому, что я нашел время поиграть с игрушкой.

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

Средний разработчик не нуждается в большом количестве положительных героев. Это распределенная система управления исходным кодом, но большинство команд будет использовать ее с центральным каноническим репо, чтобы толкать и вытягивать.

Основные команды, которые понадобятся вашей команде:

• извлекать и объединять изменения с удаленного компьютера и обрабатывать возникающие конфликты (возможно перебазирование)
• commit и push commits для удаленного (или push для промежуточного репо / ветки, чтобы получить изменения, внесенные в main после просмотра)
• Для поддержки: исправьте беспорядок после неправильной работы.

те, которые понадобятся более продвинутым пользователям,

• обрабатывать местные коммиты
• управлять филиалами

Для людей, незнакомых с git, и тех, кто не хочет изучать его, настройте несколько быстрых команд с псевдонимами, чтобы выполнить их и убедиться, что все правильно (добавьте новые файлы, удалите удаленные файлы из репозитория и т. Д.)

Убедитесь, что они хорошо документированы и прилично защищены от дурака.

Это в духе комикса xkcd , просто запомните команды и надейтесь, что вещи не слишком запутаются, когда они спросят профессионала.

Пусть они используют Git UI.

Если у них есть опыт работы с TortoiseSVN, TortoiseGit (только для Windows) работает практически так же. В противном случае, SourceTree (Windows + Mac) замечательный - у нас есть несколько не связанных с разработчиками QA, которые смогли легко справиться со сложными задачами в Git благодаря SourceTree.

Этот ответ пытается понять, как заинтересовать старших программистов 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детали. Добавьте в сценарии все средства контроля ошибок и т. Д. И попытайтесь заставить это работать.

Я хотел бы отослать вас к этой записи в блоге Джоэла Спольски .

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

В дополнение к этому, насколько мне не нравится говорить это; кто на самом деле читает руководства пользователя? Как правило, они очень плохо объясняют основное использование. Просто посмотрите на страницу git commit из руководства и подумайте, сколько новых терминов и фраз вводится тому, кто не в курсе этой концепции. Без хорошего представления я бы, скорее всего, сразу же отказался от использования Git.

Мой личный совет - начать объяснять команды:

• git add <files>
• мерзавец совершить
• мерзавец
• мерзавец
• мерзавец статус

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

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

Просто чтобы подвести итог: из моего личного опыта некоторые люди просто не тратят так много времени на изучение новых методов, концепций или инструментов, и они обычно склонны подбирать вещи, с которыми вы их знакомите, более медленными темпами. Это не означает, что они плохие программисты или плохие люди, но обычно у них более узкий набор навыков.

Git - это серьезное переосмысление, если вы узнали, как управлять исходным кодом в SVN. Многие из привычек, которые вы там разработали (что, возможно, было лучшей практикой для SVN), могут ввести вас в заблуждение при использовании git. В первую очередь это связано с тем, что модель ветвления в git существенно отличается. Он не использует папки для веток, и его также можно сделать нелинейным, поскольку он был разработан для лучшей поддержки распределенных сценариев использования. Требуется некоторое время, чтобы выучить привычки SVN и понять, как вы должны использовать git.

Начните с простого

Вы говорите, что выбрали Gitflow в качестве стандарта для управления филиалами. Это кажется мне самой большой ошибкой.

Процитируем Gitflow, считающийся вредным :

Все эти используемые ветки заставляют GitFlow иметь сложный набор сложных правил, которые описывают, как они взаимодействуют. Эти правила в сочетании с неосязаемой историей делают ежедневное использование GitFlow очень сложным для разработчиков.

Можете ли вы догадаться, что происходит, когда вы настраиваете сложную сеть таких правил? Правильно - люди делают ошибки и случайно их ломают. В случае с GitFlow это происходит постоянно. Вот короткий, ни в коем случае не исчерпывающий список наиболее распространенных ошибок, которые я наблюдал. Они повторяются постоянно, иногда каждый день, часто снова и снова одними и теми же разработчиками, которые в большинстве случаев очень компетентны в других областях программного обеспечения.

Ваши разработчики, вероятно, ошеломлены сложностью этого стандарта. Я лично не думаю, что это имеет какую-либо выгоду, и статья выше приводит тот же аргумент. Но это отдельная дискуссия. Тем не менее, объективно, это довольно тяжелый стандарт с большим количеством ручного управления, и он требует больших когнитивных усилий.

Вам нужно начать проще. Не беспокойтесь о стандарте ветвления прямо сейчас. Сосредоточьтесь на том, чтобы сначала привыкнуть к использованию git . Вам действительно нужно всего несколько операций, чтобы начать:

• клон
• вытащить
• ветка
• сливаться
• совершить
• От себя
• знание о том, как .gitignoreработает
• может быть тег

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

Постепенно увеличивать знания

Отсюда вы можете постепенно обучить их более сложному использованию.

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

Особенно убедитесь, что вы используете возможности, чтобы показать им более чистые способы загрузки своего кода в репозиторий, а также научите этому материалу в учебных мероприятиях и что у вас есть. Наличие одного или двух гуру, к которым люди могут обратиться, когда они не уверены, что делать, тоже очень поможет. Если у вас есть что-то вроде Slack, создайте специальный канал и предложите людям задавать и отвечать на вопросы там.

Затем выберите стандарт ветвления

После того как вы большинство компаний компетентных в использовании мерзавца на всех, то вы можете посмотреть на ветвящихся стандартах. Выбор одного из них является действительно плохой идеей по нескольким причинам:

• У них недостаточно знаний об инструменте, чтобы сказать вам, хорошо ли работает стандарт для случаев использования компании
• Они не смогут предложить альтернативные стандарты
• Они должны изучать как инструмент, так и стандарт одновременно
• Некоторые считают, что выбранный вами стандарт - единственный способ использовать git
• Они не смогут определить редкие крайние случаи, когда стандарт приносит больше вреда, чем пользы

Вы не должны передавать рабочий процесс Git с горы. Ваша команда должна внести свой вклад в это и иметь возможность дать вам обратную связь о том, идет ли она хорошо или нет. Они не могут этого сделать, если они еще даже не понимают основ. Вам не нужно, чтобы каждый разработчик обладал такими глубокими знаниями, но вам определенно нужно несколько, которые действительно его получают. И вам нужно подавляющее большинство, чтобы быть по крайней мере компетентным в git, чтобы они знали достаточно, чтобы хоть немного остаться на рельсах.

Вот несколько альтернатив Gitflow, которые ваша команда может рассмотреть:

• OneFlow
• Рабочий процесс ветки
• Централизованный рабочий процесс

Посмотрите на них и Gitflow, сравните их с вашими вариантами использования и выберите тот, который подходит.

Я нашел стекопоток очень полезным, когда впервые начал изучать терминологию Git. Такие вопросы были очень полезны для меня (в основном из-за их краткости), и я держал их открытыми во вкладках в течение первых нескольких недель, когда я их использовал. Может быть, распечатать пару ответов жирным шрифтом? Особенно схема на первом.

Каковы различия между «git commit» и «git push»?

В чем разница между «git pull» и «git fetch»?

Я также обнаружил, что визуальное представление ствола является удивительно полезным, но вы уже покрываете его с помощью SourceTree.

_{Кроме того, этот бит, вероятно, принадлежит комментарию, но мне не хватает представителя: я один из младших консультантов, упомянутых в вопросе. До того, как я начал, у меня было некоторое представление о том, что такое система контроля версий, и я буквально ткнул SVN дважды, Гусдор дает мне больше кредитов, чем я заслуживаю. У всей команды были качественные специализированные Git-тренировки, игрушки и время для игр. Проблема не в инструкции Гусдора. Я надеюсь, что есть хорошее альтернативное решение для этого, поэтому я могу добавить его в закладки и узнать больше.}

Купи им книгу

Честно говоря, я попал прямо в лагерь, который вы описываете. Я пришел из фона SourceSafe и ClearCase. Сначала Git был совершенно непостижим для меня, несмотря на то, что мой босс проходил через него несколько раз.

Что помогло мне, так это книга, в которой четко описывалось, что происходит, но, что более важно, то, как Git принципиально отличался от любой системы контроля версий, которую я использовал ранее. Теперь я предпочитаю Git любому другому варианту.

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

Лучшее предположение для рекомендации книги:

Pro Git от Scott Chacon (ссылка Amazon для простоты ... покупайте у того, кого вы хотите: https://www.amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6 )

Примечание : не покупайте справочник по Git. Это не поможет вообще.

По моему опыту, некоторые люди могут спокойно пользоваться git, не понимая этого. Они находят базовые учебные пособия, подбирают базовые команды, и они готовы к работе. Это, вероятно, где вы, младшие консультанты, подходите. Я не верю, что вы действительно сможете выучить git за несколько дней!

Другие люди не могут этого сделать, им нужно понять, что делает Git, а это занимает больше времени. Я был в этой категории; Я обнаружил, что очень полезно поиграть с содержимым .gitдиректории, вот тогда все и стало меня интересовать. Также помогли занятия один на один с нашим техническим лидером.

Вы можете делать уроки один на один, потому что люди учатся по-разному и могут быть по-настоящему запутаны в разных частях, а в сеансе один на один это легче увидеть и решить. Если их действительно беспокоит тот факт, что они не понимают, как git отслеживает ветки, показывает им содержимое .gitкаталога и так далее ...

Я играю с представлением, gitгде я (из TFS), чтобы ваш вопрос был своевременным для меня, тем более, что у меня также был некоторый толчок назад при обсуждении предмета.

В Peopleware основные положения всей книги:

Основные проблемы нашей работы носят не столько технический, сколько социологический характер .

Я поднимаю это, потому что у нас нет технической проблемы. git, хотя и немного тупой, вероятно, не выходит за пределы возможностей ваших или моих старших разработчиков, если они не очень глупы *.

Давайте посмотрим на это с точки зрения ваших разработчиков, как людей, а не технических машин:

Вы просите их прекратить использование системы контроля версий, которой они (вероятно) владеют, той, которой они не обладают. Это все равно, что попросить gitэксперта прекратить использование gitи перейти на svnэто, не так ли? Я полагаю, что эксперт по git будет раздражен и, вероятно, не приложит много усилий, svnпотому что gitработает отлично, и есть части, которые ей действительно нравятся, которые действительно трудно сделать svn.

Вероятно, именно поэтому юниоры восприняли это лучше - возможно, они не поняли, svnи gitэто их шанс бросить это ^.

Хотя пожилые люди опасаются альтернативных издержек - если они учатся git, то они не:

• Реакция на обучение / Angular / Swift / Blockchain / Kotlin (некоторые другие вещи, которые, по их мнению, они должны изучать).
• Заниматься своими руками, заниматься творчеством, заниматься парусным спортом, поэзией, глокеншпилем или чем-то еще, что они на самом деле хотят делать.
• Проводить время со своими детьми / родственниками / друзьями / значимыми другими.

• Доставка этой «большой новой вещи» - есть крайний срок, бюджет и т. Д. Они, вероятно, беспокоятся об этом.

  «Мне нужно сделать все вышеперечисленное, почему я должен использовать, git когда у нас уже есть контроль версий?»

Какие причины вы дали им для перехода от одной вещи, в которой они хороши, к другой, которая откровенно неловкая, когда вы новичок в этом, и требует полного переосмысления того, как вы делаете dev? Вы объяснили преимущества gitфункций?

Pull-запросы? Мелкозернистые чекины? Распределенный источник? Вилы?

Они привели к этим причинам? Это массивные структурные изменения, если вы находитесь в централизованном сознании контроля источников - не только технические изменения, но и культурные, и мы знаем, как трудно изменить культуру.

В общем, продумайте, что именно вы предлагаете своим разработчикам, и убедитесь, что это по правильным причинам. Если вы просто хотите сделать это, потому что svnэто глупо и старо, и никто больше не пользуется, тогда хорошо, но это труднее продать другим, которые не думают, как вы, и просто хотят продолжить свой день. Вы должны указать преимущества с точки зрения вашей команды и проекта. Если вы можете заставить их согласиться, что gitэто стоит боли, тогда вам не нужно беспокоиться о том, что они изучат технологию, просто соглашаясь с тем, какой рабочий процесс вы настроили.

Удачи.

Я думаю, что это не вопрос разработки программного обеспечения, а скорее вопрос психологии. Я хотел бы сослаться на Algorithms to Live By: The Computer Science of Humand Decisions. В нем автор переходит к теме компромисса изучения / использования. Люди обычно проходят фазу исследования и затем фазу использования (использования) того, что они исследовали. За этим стоит некая солидная математическая теория, позволяющая добиться оптимального использования чего-либо в определенном интервале.

Это также распространяется на возраст и опыт. Люди видят свою жизнь как интервал, и после определенного этапа исследования оптимально начать использовать ваши знания. Они процитировали исследование, в котором старших участников спросили, хотят ли они встретить кого-то известного, кого они любят, или, скорее, члена семьи. Обычно они выбирают члена семьи, в то время как молодые люди выбирают известного человека с большей вероятностью. Однако когда их попросили представить, как они решат, будут ли они на 20 лет моложе, пожилые люди обычно также выбирают известного человека. Это говорит о том, что люди перестают строить свои социальные сети, когда считают, что они получают меньше от исследований, чем от эксплуатации того, что они уже знают.

Ваши старшие инженеры, вероятно, старше, они, вероятно, прошли через несколько систем контроля версий. SVNвероятно, лучшая из тех, что они использовали до сих пор (по крайней мере, если смотреть на старые системы управления версиями, которые я использовал, SVN победил их всех).

Их оптимальная стратегия состоит в том, чтобы использовать SVN, потому что они сделали свое исследование и обнаружили, что это лучшее, что они используют сейчас.

Это базовая человеческая психология и сотни тысяч лет эволюционной оптимизации, с которой вы боретесь.

Вы должны показать им) , как долго карьера у них есть перед ними, чтобы воспламенить их думать , с другой точки зрения на отрезке они видят себя, и б) спросить их , что они думают , что это здорово и то , что они» отсутствует в SVN. Вы можете изложить сотни преимуществ git, но у них уже будет четкое представление о том, что SVNявляется лучшим, ведь они уже испытывали, вероятно, 5 систем контроля версий. Вам нужно найти щель в доспехах этого аргумента, а затем посмотреть, gitсмогут ли они решить эти проблемы, тогда они сами себя убедят.

Не давайте им инструмент или графический интерфейс для использования Git. Это только запутает вещи. Git был задуман для запуска из командной строки, так что, вероятно, он должен быть тем местом, где его изучают. Любой графический интерфейс может иметь свои собственные условия и особенности, придерживаясь того, что просто.

Далее следует рассмотреть некоторые проблемы, которые Git делает лучше, чем SVN. Чтобы ваша команда научилась этому, вам нужно мотивировать их, чтобы понять, почему Git лучше.

• Возможность совершать, пока не подключен к сети
• Возможность создавать и играть своими ветками
• Патчи, которые можно пересылать между собой и по-прежнему объединять дорожки
• сбор вишни без боли.
• перебрасывание изменений
• поиск ошибок с помощью git splice

Я уверен, что SVN продвинулся в последние несколько лет, но раньше это были вещи, которые причиняли бы боль. Если разработчики увидят, что этот новый инструмент не просто необычен, но имеет существенные преимущества для своей работы, они могут с большей вероятностью от него отстать.

Это новая вещь для изучения, и в ней достаточно сходств, которые могут запутать, но на самом деле, в 2017 году DCVS станет важным навыком для каждого разработчика.

Скажи им, чтобы не беспокоиться

В Git, когда работа завершена, проиграть практически невозможно. Единственная работа, которую вы можете легко потерять - это работа, которая еще не была совершена.

Покажите им, как git reflogработает. Им не нужно знать, как это использовать; им просто нужно знать, что это там, чтобы они могли получить помощь, чтобы вернуть свою работу, если что-то пойдет не так.

Затем убедите их в этом простом правиле: если сомневаетесь, совершайте. Они всегда могут отменить коммит позже (даже с пульта!).

Не используйте графический интерфейс

Графический интерфейс даст им более быстрый старт, но они никогда не поймут Git. Кроме того, я обнаружил , что это не «почти невозможно потерять» совершил работу при использовании Git GUI. Я видел, как графические интерфейсы делают ужасные вещи, например, представляют контрольный список при слиянии, а затем, если пользователь снимает флажок с элемента, стирают этот файл из истории без предупреждения и без записи о нем. Графический интерфейс намного хуже, чем просто изучение Git из командной строки.

Код парной программы фиксирует

Обучение с git add -Aпоследующим git commitне должно быть слишком трудным, но особенно при объединении (или перебазировании) с удаленным, им потребуется некоторая помощь. Дайте понять, что любой может обратиться за помощью в любое время. Подождите, пока они набирают команды и делают заметки. Со временем они будут постепенно увеличивать количество ситуаций, с которыми они могут справиться без посторонней помощи.

Git уже в безопасности

Кто-то выше говорил о «безопасном месте для игры». Но Git - это безопасное место. Есть только два обычных повседневных случая, когда легко потерять работу:

• Незафиксированный код
• Использование графического интерфейса

Удостоверьтесь, что они выполняют свои действия рано и часто, и что они не идут по неверному пути с помощью графического интерфейса, и вскоре они увидят, что могут доверять Git свой код даже больше, чем другие системы контроля версий в прошлом.

Я бы посоветовал взглянуть на Gitless . Это обертка над git, которая значительно упрощает базовый рабочий процесс (не нужно беспокоиться о промежуточной области, ветки сохраняют свои собственные рабочие копии файлов, git rebaseобрабатываются более простые способы использования и gl fuseт. Д.), Сохраняя при этом базовый репозиторий git для совместной работы. или если вам нужно сделать что-то необычное. Кроме того, сообщения немного более удобны для новичков. И команды достаточно близки, чтобы выступать, чтобы действовать в качестве трамплина, если им нужно использовать систему без лишних мер по какой-либо причине.

Я попытался документировать основы того, как использовать командную строку git. Это все еще сбивало с толку - и меня самого (который имел опыт использования Perforce и Source Safe), и программистов, которые предпочитали старую парадигму «просто заархивируй соответствующие папки». Было неприятно, когда непрозрачный инструмент изменял содержимое моего рабочего каталога, и часто приходилось спорить с этим инструментом, чтобы включить определенные изменения в мой рабочий каталог.

Вместо этого я использую два вида косвенного обращения.

• Я использую GitKraken для предоставления визуальной истории моих ветвей и графического интерфейса, который скрывает операторы командной строки. GitKraken обрабатывает взаимодействия между удаленным репозиторием «origin» и тем, что git считает моим локальным рабочим каталогом.

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

Могу ли я чем-нибудь помочь этим сотрудникам в изучении Git?

Вы уверены, что проблема в Git, а не в чем-то еще? Что я понял из комментария, так это то, что руководство решило что-то изменить, не получая прикуп от старших участников и поручает кому-то младшему из них руководить изменениями. Это кажется хорошей отправной точкой для неудачи, что бы это ни было. Сложность Git не проблема, проблема в том, что им навязывают изменения, в которых они не нуждаются.

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

Часто Git используется в компании для решения проблем с филиалами. Да, лучше в ветках, чем в Subversion, но это не делает никакой магии.

Весьма вероятно, что опытные разработчики работают во многих компаниях.

• Созданные филиалы, поскольку руководство не желает выбирать между противоречивыми требованиями
• Использовали ветку для каждого клиента, а не конфигурационные коммутаторы.
• Нужно было иметь ветку исправления ошибок для каждого клиента, так как руководство не хотело, чтобы все клиенты обновляли одну и ту же версию программного обеспечения.
• И т.п.

Поэтому, как только некоторые говорят мне, что инструмент хорош в ветвлении, мой разум говорит мне.

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

Также концепция, что два человека будут работать над одним файлом в одно и то же время, является «хорошей», просто неприемлема для кого-то, кто испытал хорошо управляемый проект, поэтому продвижение Git как инструмента для этого вряд ли получится опытным. разработчики любят вас.

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

Но я хотел бы работать где-нибудь, где:

• Никакой код не попадает в центральную систему, пока он не скомпилирован и не протестирован модулем на доверенном сервере.
• Существует простой способ отслеживать отзывы кода
• Где всякий раз, когда я делаю «get», код всегда компилируется и работает
• Где я могу вносить свои изменения без необходимости участвовать в гонке с кем-то еще или без необходимости уходить в офис, чтобы увидеть, не сломал ли я сборку.

Так что решайте реальные проблемы, и если Git является частью решений, которые будут покупать ваши опытные разработчики, но не ждите, что им понравится Git только потому, что это крутая игрушка, способная совершать «магические слияния».

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

Я ожидаю, что Kiln ( http://www.fogcreek.com/fogbugz/devhub ) или даже GitHub, использующий рабочий процесс «pull request», порадует опытных разработчиков, например, не начинайте с низкого уровня, начните с улучшенного процесс.