Я вижу здесь пару областей для «улучшения».

Я первый настоящий разработчик, которого наняла компания.

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

Мы пытаемся перейти на использование Git. Пользуюсь уже 7 месяцев, проблем нет

«Вы», использующие его, не составляют «Команду», использующую его. Git — это инструмент, очень похожий на многие вещи в разработке программного обеспечения. Если вы это знаете, это только помогает вам , а если вы действительно хорошо это знаете, то почему вы не обучали этому кого-то еще? Если это так легко и гладко, вы должны быть в состоянии выбить его за 5 минут. Объясните его полезность, может быть, покажите этому человеку, как много людей им пользуются.

«Вот как вы подключаете его к нашему проекту. Вот как вы время от времени нажимаете/сбрасываете/фиксируете. Вот как вы разрешаете конфликты. Это поможет нам сотрудничать и эффективно развиваться в унисон в этом проекте».

Что касается реализации Git, я бы выбрал очень простой подход:

Проблема, которую мы пытаемся решить, - это X. Способ, которым мы решаем X, заключается в использовании системы управления исходным кодом/репозитория, что позволит человеку А и мне работать вместе и совместно использовать одни и те же файлы, не наступая друг другу на пятки. Если мы не используем Git — это открывает двери для всевозможных проблем и т. д.

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

Перспектива лучше....

Я бы боялся броситься под автобус.

Представьте себе этот разговор:

«Эй, босс, почему вы реализуете процесс с помощью Git именно так, как сейчас?»

«Ну, ваш коллега не будет использовать Git».

«Я знаю! Он не будет читать учебник, который я дал ему шесть месяцев назад. Это так просто!»

— Ты уже полгода знаешь решение этой задачи и не объясняешь ему? Или не помог ему узнать?

«Ну, я отправил электронное письмо, и он должен его прочитать и стать таким же экспертом, как я!»

«Вы эксперт в предметной области, а коллега не знаком с этой технологией. Почему вы не уделили 30 минут или часу подробному объяснению?»

"... У меня нет хорошего ответа на этот вопрос."

Конкретные вопросы

Как мне объяснить ситуацию (снова) менеджеру, не вызывая волнений?

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

1. Организуйте 30-60-минутную встречу, на которой вы расскажете о преимуществах контроля версий. В первой части ВООБЩЕ НЕ ГОВОРИТЕ О GIT. Серьезно стремитесь к 60 минутам. Действуйте так, как будто ваш коллега и руководитель вообще ничего не знают о VCS.
2. После этого представьте Git и объясните, как он решает текущие проблемы, с которыми вы столкнулись.
3. Затем представьте, как, по вашему мнению, должен работать рабочий процесс для Git.
4. Пройдитесь по нескольким примерам, которые у вас и у них действительно будут.

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

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

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

Вы должны работать с инструментами и людьми, с которыми вы работаете. Иногда в бизнесе у вас не может быть оптимальных решений из-за факторов [x, y, z].

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

Как уберечь коллегу от неприятностей (он уходит, а компания разваливается)?

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

Он снисходительный и покровительственный, как это

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

Большинство менеджеров раздражает, когда им приходится принимать решения и создавать процессы, в которых их команда является экспертом, из-за нерешительности этой команды в течение ПОЛГОДА.

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

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

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

Очень немногие люди что-то делают (или не делают) без какой-либо основной причины или мотивации, и обычно очевидная причина не является настоящей причиной. Избегать изменений не так уж и редко: изменение того, как вы что-то делаете, требует больших усилий и сопряжено с риском того, что вы сделаете ошибки и будете выглядеть глупо, пока изучаете новую систему. Итак, ваш коллега не ленив, ему просто не нравится чувствовать себя некомпетентным. Как бы вы себя чувствовали, если бы кто-то дал вам набор волынок, несколько нот и указал на видео на YouTube после того, как рассказал вам, как легко играть на волынке? Подготовленному музыканту это может быть легко понять, но, возможно, не так уж сложно для разработчика.

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