Введение в Git и GitHub для разработчиков Python

Смотреть сейчас К этому учебнику прилагается видеокурс, созданный командой Real Python. Посмотрите его вместе с письменным учебником, чтобы углубить свое понимание: Введение в Git и GitHub для разработчиков Python

Вы когда-нибудь работали над проектом Python, который перестал работать после того, как вы сделали изменение здесь или очистку PEP-8 там, и вы не были уверены, как вернуть его обратно? Системы контроля версий могут помочь вам решить эту и другие связанные с ней проблемы. Git – одна из самых популярных систем контроля версий на сегодняшний день.

В этом учебнике я расскажу вам о том, что такое Git, как использовать его для своих личных проектов и как использовать его в сочетании с GitHub для работы с другими людьми над более крупными проектами. Мы рассмотрим, как создать репозиторий, как добавлять новые и измененные файлы, а также как перемещаться по истории проекта, чтобы вы могли “вернуться” к тому времени, когда проект работал.

Эта статья предполагает, что у вас в системе уже установлен Git. Если нет, то в отличной книге Pro Git есть раздел о том, как это сделать.

Что такое Git?

Git – это распределенная система контроля версий (DVCS). Давайте немного разделим это понятие и посмотрим, что оно означает.

Контроль версий

Система контроля версий (СКВ) – это набор инструментов, которые отслеживают историю набора файлов. Это означает, что вы можете указать своей VCS (в нашем случае Git) сохранить состояние ваших файлов в любой момент. Затем вы можете продолжить редактирование файлов и сохранить это состояние. Сохранение состояния похоже на создание резервной копии рабочего каталога. При использовании Git’а мы называем это сохранение состояния фиксацией.

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

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

Распределенный контроль версий

Итак, это система контроля версий. А что такое распределенная часть? Наверное, проще всего ответить на этот вопрос, начав с небольшой истории. Ранние системы контроля версий работали, храня все коммиты локально на жестком диске. Эта коллекция коммитов называлась репозиторием. Это решало проблему “мне нужно вернуться к тому, на чем я остановился”, но не очень хорошо масштабировалось для команды, работающей над одной и той же базой данных.

Когда начали работать большие группы (и сетевое взаимодействие стало более распространенным), VCS сменились на sto

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

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

Базовое использование

Теперь, когда мы поговорили о том, что такое Git в целом, давайте рассмотрим пример и увидим его в действии. Мы начнем с работы с Git’ом только на нашей локальной машине. Как только мы освоим его, мы добавим GitHub и объясним, как с ним взаимодействовать.

Создание нового репозитория

Чтобы работать с Git’ом, сначала нужно сообщить ему, кто вы. Вы можете задать свое имя пользователя с помощью команды git config:

После этого вам понадобится репозиторий для работы. Создать репозиторий очень просто. Используйте команду git init в каталоге:

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

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

Добавление нового файла

Теперь создайте файл, о котором Git не знает. С помощью вашего любимого редактора создайте файл hello.py , в котором есть только оператор print.

Если вы снова запустите git status, то увидите другой результат:

Теперь Git видит новый файл и говорит вам, что он не отслеживается. Это просто способ Git’а сказать, что файл не является частью репозитория и не находится под контролем версий. Мы можем исправить это, добавив файл в Git. Для этого используйте команду git add:

Теперь Git знает о hello.py и вносит его в список изменений, подлежащих фиксации. Добавление файла в Git перемещает его в область staging (о ней речь пойдет ниже) и означает, что мы можем зафиксировать его в репозитории.

Фиксация изменений

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

Вы видите, что команда commit вернула кучу информации, большая часть которой не слишком полезна, но она сообщает, что изменился только 1 файл (что логично, так как мы добавили один файл). Она также сообщает вам SHA коммита (25b09b9). О SHA мы поговорим чуть позже.

Выполнение команды git status снова показывает, что у нас чистый рабочий каталог, а это значит, что все изменения зафиксированы в Git.

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

В сторону: Область постановки

В отличие от многих систем контроля версий, в Git есть область хранения (часто называемая индексом). Область постановки – это то, как Git отслеживает изменения, которые вы хотите внести в свой следующий коммит. Когда мы выполнили git add выше, мы сказали Git’у, что хотим переместить новый файл hello.py в область постановки. Это изменение было отражено в git status . Файл перешел из раздела “Не отслежено” в раздел “Будет зафиксировано”.

Обратите внимание, что область staging отражает точное содержимое файла, когда вы запустили git add . Если вы измените его снова, файл появится как в части staged, так и в части unstaged в выводе статуса.

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

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

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

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

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

.gitignore

Команда status очень удобна, и вы часто будете ею пользоваться. Но иногда вы обнаружите, что есть куча файлов, которые отображаются в разделе “Не отслежено” и которые вы хотите, чтобы Git просто не видел. Вот тут-то и приходит на помощь файл .gitignore.

Давайте рассмотрим пример. Создайте новый файл Python в том же каталоге под названием myname.py .

Затем измените свой hello.py, чтобы включить в него myname и вызвать его функцию:

Когда вы импортируете локальный модуль, Python компилирует его в байткод для вас и оставляет этот файл в вашей файловой системе. В Python 2 он оставит файл под названием myname.pyc , но мы предположим, что вы используете Python 3. В этом случае он создаст каталог __pycache__ и сохранит в нем pyc-файл. Это то, что показано ниже:

Теперь, если вы запустите git status, вы увидите этот каталог в разделе untracked. Также обратите внимание, что ваш новый файл myname.py не отслеживается, а изменения, которые вы внесли в hello.py, находятся в новой секции под названием “Changes not staged for commit”. Это означает, что эти изменения еще не были добавлены в область постановки. Давайте попробуем это сделать:

Прежде чем мы перейдем к файлу gitignore, давайте немного наведем порядок. Сначала добавим файлы myname.py и hello.py, как мы делали ранее:

Зафиксируем эти изменения и закончим уборку:

Теперь, когда мы запускаем status, все, что мы видим, это каталог __pycache__:

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

Теперь, когда мы запускаем git status , мы больше не видим каталог __pycache__. Однако мы видим новый .gitignore! Взгляните:

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

Другая распространенная запись в файле .gitignore – это каталог, в котором вы храните свои виртуальные среды. Подробнее о virtualenvs можно узнать здесь, но каталог virtualenv обычно называется env или venv . Вы можете добавить их в свой файл .gitignore. Если файлы или каталоги присутствуют, они будут проигнорированы. Если их нет, то ничего не произойдет.

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

Вот пример простого файла .gitignore в Python:

Более полный пример можно найти здесь, а если вы хотите создать свой собственный, git help gitignore содержит все необходимые сведения.

Что НЕ следует добавлять в Git Repo

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

Начнем с основного правила для всех систем контроля версий.

Помещайте в систему контроля версий только исходные файлы, никогда не генерируйте файлы.

В данном контексте исходный файл – это любой файл, который вы создаете, обычно набирая текст в редакторе. Сгенерированный файл – это то, что создает компьютер, обычно путем обработки исходного файла. Например, hello.py – это исходный файл, а hello.pyc – это сгенерированный файл.

Есть две причины не включать сгенерированные файлы в репозиторий. Первая заключается в том, что это пустая трата времени и места. Сгенерированные файлы могут быть созданы заново в любое время, и, возможно, их нужно будет создать в другой форме. Если кто-то использует Jython или IronPython, а вы используете интерпретатор Cython, файлы .pyc могут быть совершенно разными. Коммиттинг одного конкретного вида файлов может привести к конфликту

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

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

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

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

Осторожно: Никогда не помещайте конфиденциальную информацию в публичный репозиторий на GitHub. Пароли, API-ключи и тому подобные вещи не должны фиксироваться в репозитории. Кто-то все равно их найдет.

В сторону: Что такое SHA

Когда Git хранит вещи (файлы, каталоги, коммиты и т.д.) в вашем репозитории, он хранит их сложным способом с использованием хэш-функции. Нам не нужно вдаваться в подробности, но хэш-функция берет вещь и создает уникальный ID для этой вещи, который намного короче (20 байт, в нашем случае). Этот идентификатор в Git’е называется “SHA”. Он не гарантированно уникален, но для большинства практических приложений это так.

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

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

Вы можете заметить, что иногда Git использует полное 20-символьное значение, чтобы показать вам SHA:

Иногда он показывает более короткую версию:

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

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

Журнал Git

Еще одна очень часто используемая команда Git – git log . Git log показывает историю коммитов, которые вы сделали до этого момента:

Как вы можете видеть в листинге выше, для нашего репозитория показаны все сообщения о фиксации по порядку. Начало каждого коммита отмечено словом “commit”, за которым следует SHA этого коммита. git log покажет вам историю каждого SHA.

Возвращение в прошлое: проверка конкретной версии вашего кода

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

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

Чтобы изменить место в нашей истории, мы воспользуемся командой git checkout, чтобы указать Git’у, какой SHA мы хотим посмотреть. Давайте попробуем это сделать:

Хорошо, здесь много информации, которая сбивает с толку. Давайте начнем с определения некоторых терминов. Начнем с HEAD .

HEAD – это название Git’а для SHA, который вы просматриваете в любой момент времени. Это НЕ означает то, что находится в вашей файловой системе или в области хранения. Это означает то, что, по мнению Git’а, вы проверили. Поэтому, если вы отредактировали файл, версия в вашей файловой системе отличается от версии в HEAD (и да, HEAD пишется с заглавной буквы).

Далее, у нас есть ветка. Проще всего думать о ветке как о метке на SHA. У него есть еще несколько полезных свойств, но пока что думайте о ветке как о метке SHA.

Примечание: Те из вас, кто работал с другими системами контроля версий (я смотрю на вас, Subversion), будут иметь

Давайте вернемся к нашей демонстрации. Если вы посмотрите на состояние системы сейчас, вы увидите, что файл .gitignore больше не существует. Мы вернулись к состоянию системы до внесения изменений. Ниже приведена диаграмма нашего репозитория в этом состоянии. Обратите внимание, что указатели HEAD и master указывают на разные SHA:

Хорошо. Теперь, как нам вернуться туда, где мы были? Есть два способа, один из которых вы уже должны знать: git checkout 1cada8f . Это вернет вас к SHA, на котором вы находились, когда начали перемещаться.

Примечание: Одна странность, по крайней мере в моей версии Git’а, заключается в том, что он всё ещё выдаёт предупреждение об отсоединённом HEAD’е, даже если вы вернулись к SHA, связанному с ветвью.

Другой способ возврата более распространен: проверьте ветку, на которой вы были. Git всегда начинает работу с ветки под названием master . Позже мы узнаем, как создавать другие ветви, но сейчас мы будем придерживаться master .

Чтобы вернуться к исходному состоянию, вы можете просто выполнить git checkout master . Это вернёт вас к последнему SHA, зафиксированному в ветке master, который в нашем случае имеет сообщение о фиксации “created .gitignore”. Другими словами, git checkout master указывает Git’у, что HEAD должен указывать на SHA, отмеченный меткой, или веткой, master .

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

Основы ветвления

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

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

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

Мы использовали опци ю-b в команде checkout, чтобы указать Git’у, что мы хотим, чтобы он создал новую ветку. Как вы можете видеть выше, выполнение git status в нашей ветке показывает, что имя ветки действительно изменилось. Давайте посмотрим на журнал:

Как вы, надеюсь, и ожидали, журнал выглядит точно так же. Когда вы создаете новое ответвление, оно начинается с того места, где вы находились. В данном случае мы находились на вершине master, 1cada8f59b43254f621d1984a9ffa0f4b1107a3b , поэтому новая ветвь начинается именно оттуда.

Теперь давайте поработаем над этой функцией. Внесите изменения в файл hello.py и зафиксируйте их. Я покажу вам команды для ознакомления, но не буду показывать вывод команд для тех вещей, которые вы уже видели:

Теперь, если вы сделаете git log, вы увидите, что наш новый коммит присутствует. В моём случае он имеет SHA 4a4f4492ded256aa7b29bf5176a17f9eda66efbb, но ваш репозиторий, скорее всего, имеет другой SHA:

Теперь переключитесь обратно на ветку master и посмотрите на журнал:

Есть ли там новый коммит “added code for feature x”?

В Git’е есть встроенный способ сравнить состояние двух веток, чтобы вам не пришлось так напрягаться. Это команда show-branch. Вот как это выглядит:

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

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

Третья строка является разделителем.

Начиная с четвертой строки, находятся коммиты, которые находятся в одной ветке, но не в другой. В нашем текущем случае это довольно просто. В my_new_feature есть один коммит, которого нет в master. Вы можете увидеть это в четвертой строке. Обратите внимание, что эта строка начинается со знака * в первом столбце. Это указывает на то, в какой ветке находится этот коммит.

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

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

Теперь вы можете видеть, что в каждой ветке есть разные коммиты. Обратите внимание, что текст [my_new_feature

2] – это один из методов отбора коммитов, о которых я говорил ранее. Если вы хотите видеть SHA, вы можете показать их, добавив к команде опци ю-sha1-name:~Теперь у вас есть ветка с кучей различных коммитов. Что делать, когда вы наконец-то закончите работу над функцией и будете готовы передать ее остальным членам команды?

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

Слияние

Слияние – самый простой из трех способов для понимания и использования. Когда вы выполняете слияние, Git создаст новый коммит, объединяющий верхние SHA двух ветвей, если это необходимо. Если все коммиты в другой ветке находятся впереди (на основе) вершины текущей ветки, он просто сделает быстрое слияние и поместит эти новые коммиты в эту ветку.

Давайте вернёмся к тому моменту, когда наш вывод show-branch выглядел следующим образом:

Теперь мы хотим, чтобы коммит 4a4f449 оказался на master. Проверьте master и выполните там команду git merge:

Поскольку мы находились на ветке master, мы выполнили слияние с веткой my_new_feature. Вы можете видеть, что это быстрое слияние и какие файлы были изменены. Давайте теперь посмотрим на журнал:

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

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

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

Cherry-Picking

Cherry picking – это ещё один метод перемещения коммитов из одной ветки в другую. В отличие от слияния и ребасинга, при “вишневом пикете” вы точно указываете, какие коммиты вы имеете в виду. Самый простой способ сделать это – указать только один SHA:

Это говорит Git’у взять изменения, вошедшие в 4a4f449, и применить их к текущей ветке.

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

Быстрый совет о ветвлениях: Я не могу оставить эту тему, не порекомендовав отличный ресурс для изучения ветвлений Git. Learn Git Branching содержит набор упражнений с использованием графических представлений коммитов и ветвей для наглядного объяснения разницы между слиянием, ребасингом и cherry-picking. Я настоятельно рекомендую потратить некоторое время на выполнение этих упражнений.

Работа с удаленными репозиториями

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

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

Давайте рассмотрим каждую из этих команд по очереди.

Клонировать

Git clone – это команда, которую вы используете, когда у вас есть адрес известного хранилища и вы хотите сделать локальную копию. Для этого примера возьмем небольшое хранилище, которое я держу на своем аккаунте GitHub, github-playground.

Страница GitHub для этого репозитория находится здесь. На этой странице вы найдете кнопку “Clone or Download”, которая дает вам URI для использования с командой git clone. Если вы скопируете его, вы сможете клонировать репозиторий:

Теперь у вас есть полный репозиторий этого проекта на вашей локальной машине. Он включает все коммиты и все ответвления, когда-либо сделанные в нём. (Примечание: Это репозиторий использовался некоторыми друзьями, когда они изучали Git. Я скопировал или скопировал его у кого-то другого).

Если вы хотите поиграть с другими удаленными командами, вам следует создать новое репозиторий на GitHub и выполнить те же шаги. Вы можете форкнуть репо github-playground на свой аккаунт и использовать его. Форк на GitHub осуществляется нажатием кнопки “fork” в пользовательском интерфейсе.

Fetch

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

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

Git не создает для вас локальных веток, за исключением master. Однако он отслеживает ветви, которые были на сервере. Для этого Git создает набор веток, которые начинаются с remotes/origin/ .

Лишь изредка (почти никогда) вы будете проверять эти ветви remotes/origin, но знать, что они есть, удобно. Помните, что у каждой ветки, существовавшей на удалённом компьютере, когда вы клонировали репозиторий, будет ветка в remotes/origin .

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

Теперь, когда вы знаете об удаленных/родственных ветвях, понять git fetch будет довольно просто. Все, что делает fetch, это обновляет все удаленные/родственные ветви. Она изменит только ветки, хранящиеся в remotes/origin, и не изменит ни одну из ваших локальных веток.

Git pull – это просто комбинация двух других команд. Сначала выполняется git fetch для обновления веток remotes/origin. Затем, если ветка, на которой вы находитесь, отслеживает удаленную ветку, то выполняется git merge соответствующей удаленной/родственной ветки с вашей веткой.

Например, допустим, вы находитесь на ветке my_new_feature, а ваш коллега только что добавил в нее код на сервере. Если вы сделаете git pull, Git обновит ВСЕ удаленные/оригинальные ветви, а затем выполнит git merge remotes/origin/my_new_feature, который перенесет новый коммит на ветвь, в которой вы находитесь!

Конечно, здесь есть некоторые ограничения. Git не позволит вам даже попытаться сделать git pull, если в вашей локальной системе есть измененные файлы. Это может создать слишком много беспорядка.

Если у вас есть коммиты на локальной ветке, а на удаленной также есть новые коммиты (т.е. “ветки разошлись”), то часть git merge для pull создаст коммит слияния, как мы обсуждали выше.

Те из вас, кто внимательно читал, увидят, что вы также можете заставить Git сделать rebase вместо слияния, выполнив git pul l-r .

Как вы уже, наверное, догадались, git push прямо противоположен git pull . Ну, почти противоположность. Push посылает информацию о ветке, которую вы толкаете, и спрашивает удалённое устройство, не хочет ли оно обновить свою версию этой ветки, чтобы она соответствовала вашей.

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

Здесь есть фантастическая статья. Суть в том, что git push делает ваши новые коммиты доступными на удаленном сервере.

Putting It All Together: Простой рабочий процесс Git

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

git status – Убедиться, что ваша текущая область чиста.

git pull – Получить последнюю версию из удаленного репозитория. Это поможет избежать последующего слияния.

Отредактируйте свои файлы и внесите изменения. Не забудьте запустить линтер и провести модульные тесты!

1. git status – Найти все измененные файлы. Не забудьте проследить и за неотслеживаемыми файлами!
2. git add [files] – Добавить измененные файлы в область хранения.
3. git commi t-m “message” – Сделать новый коммит.
4. git push origin [branch-name] – Переместите изменения на удалённую ветку.
5. Это один из самых основных потоков через систему. Существует много, много способов использования Git, и в этом руководстве вы только поцарапали поверхность. Если вы используете в качестве редактора Vim или Sublime, вам стоит ознакомиться с этими руководствами, которые покажут вам, как получить плагины для интеграции Git в ваш редактор:
6. Если вы хотите глубже погрузиться в Git, я могу порекомендовать вам эти книги:
7. Бесплатный онлайн Pro Git – это очень удобный справочник.

Для тех, кто любит читать на бумаге, существует печатная версия книги Pro Git, а я нашел полезной книгу O’Reilly’s Version Control with Git.

Наконец, если вы заинтересованы в использовании возможностей искусственного интеллекта в своем кодировании, то вам стоит поиграть с GitHub Copilot.

• Смотреть сейчас К этому учебнику прилагается видеокурс, созданный командой Real Python. Посмотрите его вместе с письменным учебником, чтобы углубить свое понимание: Введение в Git и GitHub для разработчиков Python
• Получайте короткие и милые советы по Python в свой почтовый ящик каждые несколько дней. Никакого спама. Отпишитесь в любое время. Курируется командой Real Python.

О Джиме Андерсоне

Смотреть сейчас К этому учебнику прилагается видеокурс, созданный командой Real Python. Посмотрите его вместе с письменным учебником, чтобы углубить свое понимание: Введение в Git и GitHub для разработчиков Python

Каждый учебник на Real Python создается командой разработчиков, чтобы он соответствовал нашим высоким стандартам качества. Над этим учебником работали следующие члены команды:

Мастер

Навыками работы с Python в реальном мире

С неограниченным доступом к Real Python

Присоединяйтесь к нам и получите доступ к тысячам учебников, практическим видеокурсам и сообществу экспертов Python: Мастер Навыки реального мира Python

С неограниченным доступом к реальному Python

Присоединяйтесь к нам и получите доступ к тысячам учебников, практическим видеокурсам и сообществу экспертов Python: Мастер Навыки реального мира Python

С неограниченным доступом к реальному Python

Трюки Python Слияние словарей