Посмотрите, как работают ветки в Git

Посмотритекакработаютветкивgit

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

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

В этом посте я хотел бы изучить и объяснить, что, почему, и как ветки:

  • Вкратце, что такое ветки?
  • Почему ветки так полезны?
  • Как они используются, особенно в командах?
  • Как выглядят ветки под капотом в Git?

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

Вкратце, что такое ветки?

Проще говоря, база кода – это набор файлов. . Любое значимое изменение (например, при разработке новой функции или исправлении проблемы), скорее всего, будет связано с парой этих файлов.

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

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

Давайте углубимся в детали!

Почему ветки так полезны?

Значение ветвления становится очевидным, если вы подумаете о своем рабочем процессе без них: представьте, что команда 15 или же 31 все разработчики работают, так сказать, в одной «папке». Все они одновременно редактируют одни и те же файлы исходного кода. Внезапно их код стал вашим. Некоторые могут внедрять совершенно новые функции, которые вначале могут приводить к ошибкам. Каждый эксперимент, который разработчик должен провести, чтобы добиться прогресса, и каждая ошибка, которая неизбежна в этом процессе, повлияет на всех его товарищей по команде. Горстки людей, работающих вместе таким образом, достаточно, чтобы остановить весь процесс разработки.

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

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

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

Функции и исправления ошибок четко отделены друг от друга, и так же их коммиты и их код:

В приведенном выше примере , изменения в «Содержании часто задаваемых вопросов» и «Новом дизайне №1» не мешают друг другу.

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

Почему Git?

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

  • Простота: Использовать ветки в Git очень просто. Новички иногда колеблются перед созданием новой ветки и спрашивают себя, оправдывает ли конкретная ситуация создание новой ветки. В таких колебаниях нет необходимости: создавать новые ветки в Git так просто и без каких-либо недостатков. Просто возьмите дисковое пространство в качестве примера: создание новой ветки в Git не копирует файлы, возможно создание большого количества файлов-дубликатов; вместо этого управление файлами Git гарантирует, что ничего не нужно копировать!
  • Скорость: В Git все операции по работе с ветками выполняются очень быстро. В то время как некоторые системы контроля версий, например, создают копии файлов при создании новой ветки, внутреннему управлению Git это не нужно. В результате не требуется время ожидания при создании новых веток или работе с существующими.
  • Объединение: Создание безопасных отдельных контекстов с помощью веток – это одно. Но интеграция (или «слияние») ветвей обратно в другие контексты – это другая часть игры. Во многих других системах контроля версий слияние может быть сложной задачей: вас могут попросить предоставить точные версии или выбрать определенные наборы изменений. С другой стороны, Git делает его очень простым и удобным для пользователя. В большинстве случаев он просто работает без какого-либо вмешательства пользователя.

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

Как ветки используются на практике?

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

Эксперименты / Новые возможности

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

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

Исправление ошибок

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

Кратковременные ветки

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

Долгосрочные ветви

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

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

Наряду с этим различием между короткими живые и долго работающие ветки, также часто существует золотое правило: никогда не выполняйте фиксацию напрямую в долго работающей ветке ; код должен попадать в эти ветки только через преднамеренную интеграцию (посредством слияния или перебазирования).

Реальный пример долгоживущих и недолговечных ветвей, визуализированный в Графический интерфейс рабочего стола Tower Git .

Как ветки работают технически, под капотом?

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

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

Указатели , а не копии файловой системы

Если ветки не являются копиями файловой системы, что они собой представляют? Чтобы ответить на этот вопрос, важно знать, что коммиты в Git невероятно безопасны и эффективны при хранении данных:

  • Безопасность : содержимое и метаданные фиксации обрабатываются хэш-алгоритмом SHA-1, что очень затрудняет манипулирование данными после факта.
  • Эффективность : Коммиты не сохраняют данные снова, если они уже имеют были сохранены ранее. Это означает, что файлы, которые НЕ были изменены между коммитами, не занимают ненужного дискового пространства.

Помня об этом, есть ли необходимость «изобретать» что-то поверх этого? Нет, конечно нет! Вот почему ветки в Git – это чрезвычайно легкая концепция – они далеки от тяжелых «копий файловой системы».

Ветвь – это просто указатель на последнюю фиксацию в данном контекст.

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

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

Какие действительно ли указатель?

Но как выглядят эти мистические указатели и где они живут? Чтобы ответить на этот вопрос, нам нужно совершить небольшое путешествие во внутреннее устройство Git: скрытый каталог «.git», расположенный в корне вашего проекта. Здесь вы найдете подкаталог с именем «refs» и еще один подкаталог с именем «Heads»: здесь каждая ветвь представлена ​​файлом, названным в честь этой ветки.

Когда вы создаете новую ветку, например, с помощью такой команды, как «git department my-new-branch», вы найдете здесь новый физический файл с именем «my-new-branch».

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

На изображении выше показано содержимое такого «файла-указателя»: ветвь с именем «principal» в настоящее время указывает в фиксацию с хешем SHA-1 «bf ef 73 c ».

Какой из этих указателей активен в данный момент?

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

Git сохраняет другой специальный указатель с именем «HEAD». Единственная цель HEAD – указать на текущую активную (или «извлеченную») ветвь:

В локальной папке репозитория .git вы найдете эту информацию, сохраненную в файл соответствующим образом названный «ГОЛОВА». И содержимое этого файла обычно выглядит примерно так:

ref: refs / Heads / my-new-branch

Что происходит при переключении ветвей?

Наконец , давайте посмотрим, что происходит, когда вы переключаете текущую активную ветвь – например, с помощью такой команды, как git checkout other-branch или же git change other-branch .

Такая команда будет делать две вещи:

  1. a) Указатель HEAD изменен и теперь указывает на «другую ветвь».
  2. б) Файлы в вашей рабочей копии поменялись местами и теперь представляют состояние последней фиксации в этой ветке.
  3. Я надеюсь, что этот пост дал вам лучшее понимание того, как на самом деле работают ветки - один из основных инструментов Git.

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

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

    Удачи, становясь лучшим программистом!

    Теги: , ,

Leave a comment

Your email address will not be published. Required fields are marked *