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

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

Используйте грёбаный Git GUI

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

Я лично рекомендую Sourcetree от Atlassian (та же компания, которая стоит за Bitbucket и Jira; у них также есть отличные подробные руководства по Git на их веб-сайте).

Понимание терминологии

Первым и главным препятствием для серьезного использования Git является понимание жаргона и всех его запутанных метафор. Все начинается с понимания областей управления версиями в Git (я придумал это название, потому что не смог найти официальное в Интернете). Ваш исходный код, как есть, независимо от собственных метаданных Git, называется рабочей областью/ рабочим каталогом. Оттуда вы add (или stage) код в индекс (также называемый промежуточной областью) перед фиксацией изменений в вашем локальном репозитории. После фиксации изменений на вашем компьютере вы можете push отправить их на сервер (т. е. origin, в удаленный репозиторий, upstream).

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

Зачем тебе индекс?

Это кажется излишне сложным, не так ли? Ну, идея в том, что вы можете не захотеть контролировать версии каждого файла в исходном коде (т. е. локальные файлы конфигурации). Вы также можете разделить свои изменения на несколько коммитов. Помните, что основная цель Git — обеспечить совместную работу разработчиков. Это означает, что ваши коммиты могут (и будут) просматриваться другими людьми. Таким образом, в ваших интересах сделать ваши коммиты максимально простыми. Сосредоточьте свои изменения на нескольких файлах и на одной функции. Здесь на помощь приходит индекс. Индекс позволяет вам выбрать, какие изменения войдут в ваш следующий коммит, а какие нет. Вы можете stash оставить любые изменения на потом.

Исправление беспорядка: сброс и возврат

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

Понимание моделей ветвления

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

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

Слияние против перебазирования

Одна картинка стоит тысячи слов:

Одно из самых важных правил философии Git можно сформулировать следующим образом: НЕ ИЗМЕНЯЙТЕ ПУБЛИЧНУЮ ИСТОРИИ. КОГДА-ЛИБО. Единственным исключением из этого правила является случай, когда вы случайно публикуете закрытый ключ (в этом случае вам в помощь существует специализированное программное обеспечение). Перебазирование приводит к более чистому виду истории за счет отказа от загрязняющего коммита слияния. Но это происходит за счет изменения истории. Если перебазирование используется в общедоступной ветке, это может сильно сбить с толку других разработчиков. В случае сомнений используйте merge.

Написание хороших сообщений коммитов

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

  1. Первая строка должна быть написана в императиве и давать краткое описание коммита в 50 или меньше символов.
  2. Если необходимо, дальнейшие абзацы должны начинаться с пустой строки и содержать более подробное объяснение изменений, а их длина должна составлять 72 символа.

Подробнее об этом можно прочитать здесь.

Понимание пул-реквестов

Итак, вы, возможно, уже слышали о запросах на вытягивание. «Запросы на вытягивание — это то, как вы сотрудничаете!». На самом деле запросы на вытягивание даже не являются функцией самого Git. Они являются частью службы хостинга, которую вы используете, например, GitHub, Bitbucket или GitLab. Запросы на вытягивание можно сделать двумя разными способами. Логистика будет зависеть от ваших привилегий репозитория.

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

Если вы просто случайно вносите свой вклад в проект с открытым исходным кодом, скорее всего, у вас нет доступа к репозиторию. Но никаких ладов! Услуги хостинга позволяют вам разветвитьрепозиторий, то есть «клонировать его на стороне сервера». Таким образом, ваша учетная запись будет иметь точную копию проекта, с которым вы сможете работать. После того, как вы завершили свою функцию / исправили ошибку, пришло время создать запрос на включение! Обязательно прочитайте документ CONTRIBUTING.md репозитория, если он существует. Просмотрите запросы на вытягивание, сделанные другими в репозитории, чтобы понять, какую информацию вам нужно предоставить. Выберите правильную ветку, чтобы слиться с ней, используйте лучшие навыки письма и нажмите большую зеленую кнопку!

А теперь иди и сделай что-нибудь великое!