Должен ли я ожидать, что моя команда будет обладать чем-то большим, чем базовые знания в нашей системе контроля версий?

Моя компания перешла с Subversion на Git около трех месяцев назад. У нас было предварительное уведомление за несколько недель до переключения. Поскольку я никогда раньше не использовал Git (или любую другую DVCS), я читал Pro Git и провел немного времени, раскручивая свои собственные репозитории и играя, так что, когда мы перешли, я мог продолжать работать с минимальной болью. Теперь я "Git парень" по умолчанию.

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

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

Должен ли я ожидать, что моя команда хоть немного понимает, как Git работает внутри, и как использовать его помимо самых простых операций вытягивания / слияния / проталкивания? Или я просто делаю что-то из ничего?

Профессионализм, естественно, диктует, чтобы разработчик ознакомился со стандартными инструментами своей команды, даже если они новы и незнакомы (или даже нежелательны).

Однако несколько вещей в вашем посте заставляют меня задуматься.

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

Недели? Поменять систему контроля версий - это большое дело. Должны были быть месяцы уведомления, приведшие к таким изменениям.

За некоторыми исключениями, большая часть моей команды до сих пор не знает, как работает Git.

Итак, ваша компания перешла на систему контроля версий, которую в то время мало кто понимал?

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

Мы внедряли Git там, где я работаю, и, естественно, было сопротивление. Это было для нового проекта, поэтому мы сейчас поддерживаем два хранилища.

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

• Местные отделения поощряют эксперименты
• Git bisect, чтобы легко отследить ошибки
• частые коммиты, не перебивая других
• Быстрое переключение между ветками

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

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

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

CLI Git является загадочным, и тривиальные проблемы (для нас с вами) не позволят людям работать. Вот что произошло в нашей команде (заметьте, это довольно компетентные разработчики):

• Git с SSH на Windows была распространенной проблемой.
• Люди будут тянуть, сливаться, но не толкать сливаться. Так что график будет огромным путаницей
• Проблема с производительностью в Windows заставила "git status" занять 15 секунд
• Не могу понять, как вытащить новую ветку. Они будут делать "git checkout -b", который будет отделяться от всего, над чем они работают.
• У EGit в затмении было подавляющее меню. Закончил всем говорить сначала использовать командную строку
• На основе предыдущего пункта, слияние и настройка git mergetool
• Запутался в различиях между «git add» и «git commit» и «git push».

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

Мастер против Гитмании

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

Почему это важно (так много)

Инструменты контроля версий очень важны, потому что неправильное использование может замедлить не только одного человека, но и целую команду. Неправильное использование Git должно быть менее проблематичным, чем неправильное использование SVN, CVS и других систем. Исторически, неумелое использование систем, которые блокировали файлы, было особенно проблематичным, и компании нанимали отдельные команды сборки, чтобы, когда у кого-то возникали проблемы, был беглый эксперт, который почти ничего не делал, кроме контроля исходного кода, который мог бы вылечить рану хранилища. Это частично объясняет некоторую страсть, которую вы найдете за мерзавцем.

Как выглядит базовое мастерство?

Некоторые конкретные критерии включают в себя:

• Без ссылки на документацию:

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

• С документацией:

  • Добавить пользователей и учетные данные для локального репо.
  • инициировать локальное репо.
  • Администрирование удаленного репо.
  • Настройте игнорируемые файлы, сгенерируйте пары открытого и закрытого ключей PKI.
  • Переместите и удалите файлы.
  • Используйте bisect, чтобы найти изменения, которые привели к конкретной ошибке.

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

Что бы вы добавили для продвинутой квалификации?

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

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

GIT - это просто инструмент для выполнения работы, и одна из его самых больших проблем заключается в том, что многие евангелисты GIT ожидают, что все пользователи GIT окажутся под капотом экспертов, понимая тонкости его работы. Это самая большая слабость GIT - чтобы использовать его, нужно знать, как он работает. Нет никаких рецептов с GIT, вы должны быть экспертом GIT или не использовать его. Замечательно, что вы читаете Pro-GIT, вашей организации нужен GOT-гуру "goto" (или два), чтобы максимизировать инвестиции в него, потому что не каждый разработчик хочет стать GIT-гуру - и это нормально.

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

Я не рассказываю обезьянам, как работает GIT, если я знаю, как заставить GIT работать на меня.

Да.

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

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

Я использовал Git только в личных условиях, а не в профессиональной, и хотя мне нравится его мощь и идея более децентрализованного контроля источников, у него есть серьезные проблемы. Git имеет дырявую абстракцию, и для выполнения простых задач требуется несколько команд (например, для внесения изменений: git add, git commit, затем git push). Кроме того, некоторая часть документации отсутствует и / или путается, как в описании команды rebase ... «Локальный канал прямого порта фиксирует обновленный заголовок восходящего потока». Я понятия не имею, что это значит, и хотя теперь я знаю, что вы можете перемещать коммиты и переписывать историю с ним (еще одно раздражение ... почему вам следует разрешить это делать ???), я бы никогда не догадался об этом по этой команде описание. Я думаю, что некоторые чтения со стороны вашей команды, и некоторые дополнительные тренировки, проведенные вами, в порядке.

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

Нет; Я думаю, что разумно ожидать следующего:

1. Выполняйте повседневные задачи (коммит, толчок, вытягивание, ветвление, слияние, разделение и т. Д.) Без ручного удержания.
2. Выполняйте нестандартные задания без повторных инструкций. (Несколько повторений в порядке - я должен встретиться с кем-то 2-3 раза, прежде чем его имя действительно зафиксируется.)

Если они не могут сделать # 1, то обучающая часть вашего развертывания, вероятно, была недостаточной. Если они не могут сделать № 2, то сначала убедитесь, что вы объясняете вещи достаточно четко, прежде чем расстраиваться.