Как обновлять и поддерживать отдельные ветки Git
Одной из основных функций Git является возможность создавать несколько версий вашего проекта. Часто они используются для краткосрочных ответвлений, называемых «функциональными ветвями», которые объединяются в мастер. Однако иногда необходимо иметь действительно отдельные ветки, что усложняет их синхронизацию.
Зачем поддерживать разные ветки?
Обычно ветки недолговечны и предназначены для слияния с основной веткой релиза. Однако в некоторых случаях необходимо поддерживать полностью отдельные ветки. Например, у вас могут быть ветки, предназначенные для разных платформ или зависимостей, с разными функциями, или просто отдельные ветки релиза, которые вы поддерживаете какое-то время.
Это тот же рабочий процесс с большинством форков, и в зависимости от количества и серьезности изменений может быть сложно синхронизироваться с исходным потоком. Если ваши две ветки в значительной степени синхронизированы за вычетом нескольких коммитов, вам будет намного легче справляться с конфликтами и поддерживать актуальность.
Однако в большинстве случаев вам следует искать альтернативу разделению веток, потому что это может стать довольно утомительным, особенно с конфликтами слияния и всем дополнительным тестированием. Например, если у вас есть две сборки, предназначенные для разных платформ, многие языки имеют конфигурацию сборки и препроцессоры, которые могут справиться с этим. C# имеет #if NETVERSION, что позволяет вносить изменения в код в зависимости от платформы, для которой он компилируется.
Какой бы ни была ваша причина, это правильный рабочий процесс Git, который используют многие люди.
Поддержание веток в синхронизации с перебазированием
Есть в основном два варианта того, как это сделать. Первый и наиболее распространенный метод — это ребазинг, который очень похож на слияние, но позволяет ветвям быть полностью независимыми.
Коммиты Git можно представить как цепочку изменений, уходящих в прошлое, каждое из которых указывает на предыдущую фиксацию. Когда вы создаете новую ветку, она отделяется от основной ветки master в определенной точке, базе ветки.
Перебазирование — это, по сути, поднятие всей ветки feature и ее перемещение в новый момент времени, где конец указывает на другую цепочку коммитов. Это наиболее полезно, если разветвленная ветвь содержит только несколько коммитов, потому что тогда конфликты слияния будет легче разрешить. В этом примере перебазирование этой ветки включает в себя коммиты B и C, но не D и E, так как не нужно перебазировать в HEAD ветки.
Однако перебазирование обычно используется только для локальных веток и создает несколько проблем при использовании с общими ветками. Коммиты на самом деле не перемещаются; они копируются, в результате чего появляются новые идентификаторы коммитов, а HEAD ветки перемещается в новое место.
Это означает, что старые коммиты остаются незавершенными. Поскольку Git — это децентрализованная система контроля версий, ваши коллеги могут иметь неотправленные коммиты, которые ссылаются на эти удаленные коммиты. Перебазирование должно быть чем-то, что вы согласовываете с любыми соавторами, и если у кого-то возникнут какие-либо конфликты, им нужно будет исправить это локально, скопировав эти изменения в правильное место.
Перебазировать ветку довольно просто. Вам нужно будет проверить ветку feature, получить все изменения с пульта, а затем запустить rebase , чтобы переместить feature. ветвление на целевую ветку.
git checkout feature git pull git rebase master
Это, скорее всего, приведет к конфликтам слияния, которые вам придется разрешать самостоятельно, а затем зафиксировать изменения.
В то время как большинство повседневных задач Git можно довольно легко выполнить из командной строки, перемещение по своей природе является довольно визуальной операцией, поэтому мы рекомендуем использовать Git-клиент с графическим интерфейсом, такой как Fork или GitKraken, если вы можете. Это покажет вам линии ветвления и поможет более эффективно спланировать перебазирование и даже может выполнять интерактивные перебазирования.
Поскольку перебазирование в основном применяет каждую фиксацию из функциональной ветки в новое место, вам не нужно включать их все, а интерактивное перебазирование может отбрасывать ненужные вам коммиты. Это можно сделать из командной строки, но имеет смысл использовать графический интерфейс.
Исправление нежелательных коммитов
Что произойдет, если вы не хотите включать некоторые коммиты при перебазировании? Если у вас есть коммиты в ветке feature, которые вы хотите исключить при перебазировании на master, вы можете выполнить интерактивное перебазирование. Это удалит нежелательные коммиты при перемещении, по существу удалив их из истории.
Но гораздо более вероятно, что в ветке master есть коммиты, которых вы не хотели бы иметь в своей ветке feature. Поскольку перебазирование устанавливает основу новой ветки на master, невозможно не включить эти коммиты.
Если есть только один или два коммита, которых вы не хотели бы иметь, вы, вероятно, все равно можете перебазировать и либо разобраться в конфликте слияния, исправить это вручную, либо просто отменить коммит. В Git есть команда «revert», которая применяет противоположные изменения, по существу отменяя коммит и делая его таким, как будто его никогда не было. Чтобы использовать его, запустите git log, чтобы найти фиксацию, которую вы хотите отменить:
Затем скопируйте хеш SHA1 и отмените коммит:
git revert 62ee517cc7c358eafbbffdebdde1b38dea92aa0f
Это создаст «обратный коммит» в ветке feature.
Cherry-Picking переходит на другую ветку
Последний сценарий, с которым вы можете столкнуться, — это всего несколько коммитов от master , которые вы хотели бы иметь в feature. Это обычное дело, если вы поддерживаете ветки для разных версий, потому что часто есть исправления и исправления, которые необходимо применять к более старым версиям программного обеспечения.
Однако это самый раздражающий метод синхронизации, потому что, если вы не синхронизируете свои ветки хотя бы частично, существует высокая вероятность того, что фиксация, которую вы хотите включить, может быть несовместима со старой веткой.
Но у Git есть инструменты для копирования и вставки коммитов в другую ветку. Это действие называется «выбор вишни», потому что вы выхватываете один коммит из истории и выдергиваете его. Подобно перебазированию, выбор вишни создает новые скопированные коммиты, но Git обычно достаточно умен, чтобы отсортировать их, даже если позже вы объедините ветки вместе.
Чтобы выбрать вишню, вам нужно получить идентификатор коммита. Если история вашей ветки сложна, вы можете запустить git log с параметром --graph , чтобы получить визуальное представление вашей истории, хотя клиент с графическим интерфейсом особенно полезен для задач. так.
git log --pretty=format:"%h %s" --graph
Затем убедитесь, что вы находитесь в ветке feature, и запустите cherry-pick с идентификатором коммита, чтобы скопировать его.
git checkout feature git cherry-pick 1da76d3
Это может привести к конфликтам, которые вам придется решать.