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

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

Направляясь прямо в GUI Tools, не пытаясь использовать терминал

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

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

Наконец, использование терминала даст дополнительные навыки тем, кто не использует, например, сценарии bash, что обеспечивает безумную полезность при разработке.

Лично я использую расширение объектива Git в коде Visual Studio из-за его удобного пользовательского интерфейса для отслеживания истории, но в целом я предпочитаю удобство терминала.

Команды над структурой

Команды — это то, что запускает процесс разработки. Однако было бы неплохо узнать, как Git структурирован/разработан.

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

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

Избегайте запросов на включение / проверки кода

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

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

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

И, самое главное:

Вы позволяете себе получить признание.

Не обращая внимания на слияния/перебазирования с важностью

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

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

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

Нет старшего лица, чтобы обратиться за помощью

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

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

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

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

Забавный факт."Jogar aos Leões" ("Бросить во львов") — популярное португальское выражение, когда это происходит. Он используется, когда кто-то попадает в трудную ситуацию, не ожидая от нее успешной работы.

Не искать и не просить о помощи

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

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

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

Если вы ищете какой-то источник информации в виде структуры Git, вы можете использовать некоторые слайды, которые я писал ранее о Git в здесь. Большое спасибо Дэвиду Рамальо за размещение в Azure.

Хорошей недели,

Пауло