3.1 Розгалуження в Git - Про розгалуження у двох словах

Майже кожна система контролю версій у тій чи іншій формі підтримує розгалуження. Використовуючи розгалуження, Ви відхиляєтесь від основної лінії розробки та продовжуєте роботу незалежно від неї, не втручаючись у основну лінію. У багатьох системах контролю версій створення гілок — це дуже витратний процес, який часто вимагає створення нової копії каталогу з вихідним кодом, що може зайняти багато часу для великого проекту.

Деякі люди, говорячи про модель розгалуження Git, називають її "кілер-фіча", що вигідно виділяє Git на тлі інших систем контролю версій. Що в ньому такого особливого? Розгалуження Git дуже легковажно: операція створення гілки виконується майже миттєво, перемикання між гілками туди-сюди, як правило, також швидко. На відміну від багатьох інших систем контролю версій, Git заохочує процес роботи, при якому розгалуження та злиття виконується часто, навіть кілька разів на день. Розуміння та володіння цією функціональністю дає вам унікальний та потужний інструмент, який може повністю змінити звичний процес розробки.

Про розгалуження у двох словах

Для точного розуміння механізму розгалужень необхідно повернутися назад і вивчити те, як Git зберігає дані.

Як ви можете пам'ятати з Що таке Git?, Git не зберігає дані у вигляді послідовності змін, він використовує набір знімків (snapshot).

Коли ви робите коміт, Git зберігає його у вигляді об'єкта, що містить покажчик на знімок (snapshot) підготовлених даних.Цей об'єкт також містить ім'я автора та email, повідомлення та покажчик на комміт або комміти, що безпосередньо передують даному (його батьків): відсутність батька для початкового комміту, один з батьків для звичайного комміту, і кілька батьків для результатів злиття двох і більше гілок.

Припустимо, у вас є каталог з трьома файлами і ви додаєте їх у індекс і створюєте комміт. Під час індексації обчислюється контрольна сума кожного файлу (SHA-1, як ми дізналися з Що таке Git?), потім кожен файл зберігається в репозиторій (Git називає такий файл блоб — великий бінарний об'єкт), а контрольна сума потрапить до індексу:

$ git add README test.rb LICENSE $ git commit -m 'Initial commit'

Коли ви створюєте коміт командою git commit, Git обчислює контрольні суми кожного підкаталогу (у нашому випадку, лише основний каталог проекту) і зберігає його в репозиторії як об'єкт дерева каталогів. Потім Git створює об'єкт комміту з метаданими та вказівником на основне дерево проекту для можливості відтворити цей знімок у разі потреби.

Ваш репозиторій Git тепер зберігає п'ять об'єктів: три блоби об'єкта (по одному на кожен файл), об'єкт дерева каталогів, що містить список файлів і відповідних їм блобів, а також об'єкт комміта, що містить метадані та вказівник на об'єкт дерева каталогів.

Якщо ви зробите зміни та створите ще один коміт, то він міститиме покажчик на попередній коміт.

Гілка в Git - це простий вказівник, що переміщується, на один з таких коммітів. За умовчанням, ім'я основної гілки Git - master . Як тільки ви почнете створювати комміти, гілка master завжди вказуватиме на останній комміт.Щоразу при створенні комміта покажчик гілки master буде пересуватися на наступний коміт автоматично.

Гілка "master" в Git - це не якась особлива гілка. Вона така сама, як і всі інші гілки. Вона існує майже у всіх репозиторіях тільки тому, що її створює команда git init, а більшість людей не змінюють її назву.

Створення нової гілки

Що ж насправді відбувається під час створення гілки? Лише створюється новий покажчик для подальшого переміщення. Допустимо ви хочете створити нову гілку з ім'ям testing. Ви можете це зробити командою git branch:

$ git branch testing

Через війну створюється новий покажчик поточний комит.

Як Git визначає, в якій галузі ви знаходитесь? Він зберігає спеціальний покажчик HEAD. Майте на увазі, що Git концепція HEAD значно відрізняється від інших систем контролю версій, які ви могли використовувати раніше (Subversion або CVS). У Git це покажчик на поточну локальну гілку. У нашому випадку ми все ще знаходимося у гілці master. Команда git branch тільки створює нову гілку, але не перемикає на неї.

Ви можете легко це побачити за допомогою простої команди git log, яка покаже вам, куди вказують покажчики гілок. Ця опція називається --decorate.

$ git log --oneline --decorate f30ab (HEAD -> master, testing) Add feature #32 - здатність до нових форматів до центральної interface 34ac2 Fix bug #1328 - stack overflow under certain conditions 98ca9

Тут можна побачити вказівки на коміт f30ab гілки: master і testing.

Перемикання гілок

Для перемикання на існуючу гілку виконайте команду git checkout. Давайте перейдемо на гілку testing :

$ git checkout testing

В результаті покажчик HEAD переміститься на гілку testing.

Який у цьому сенс? Давайте зробимо ще один коміт:

$ vim test.rb $ git commit -a -m 'made a change'

Цікава ситуація: покажчик на гілку testing перемістився вперед, а master вказує на той же коміт, де ви були до перемикання гілок командою git checkout. Давайте перейдемо назад на гілку master :

$ git checkout master

Якщо виконати команду git log прямо зараз, то в її висновку щойно створена гілка "testing" фігурувати не буде.

Гілка нікуди не зникла; просто Git не знає, що саме вона вас цікавить, і виводить найкориснішу на його думку інформацію. Інакше кажучи, за умовчанням git log відобразить історію коммітів лише поточної гілки.

Щоб переглянути історію коммітів іншої гілки, необхідно явно вказати її ім'я: git log testing Щоб подивитися історію по всіх гілках — виконайте команду з додатковим прапором: git log --all .

Ця команда зробила дві речі: перемістила покажчик HEAD назад на гілку master і повернула файли в робочому каталозі в стан, на знімок якого вказує master . Це також означає, що всі зміни, що вносяться з цього моменту, будуть відноситися до старої версії проекту. Іншими словами, ви відкотили всі зміни гілки testing та можете продовжувати в іншому напрямку.

Важливо запам'ятати, що при перемиканні гілок Git відбувається зміна файлів у робочому каталозі. Якщо ви переключаєтеся на стару гілку, то робочий каталог виглядатиме так само, як виглядав на момент останнього комміту в гілку. Якщо Git з якихось причин не може цього зробити, він не дозволить вам переключитися взагалі.

Давайте зробимо ще кілька змін і створимо черговий коміт:

$ vim test.rb $ git commit -a -m 'зроблені інші зміни'

Тепер історія вашого проекту розійшлася (див. Розгалужена історія). Ви створили гілку і переключилися на неї, попрацювали, а потім повернулися в основну гілку та попрацювали в ній. Ці зміни ізольовані одна від одної: ви можете вільно перемикатися туди й назад, а коли знадобиться об'єднати їх. І все це робиться простими командами: branch, checkout та commit.

Усі описані дії можна візуалізувати за допомогою команди git log. Для відображення історії коммітів, поточного положення вказівників гілок та історії розгалуження виконайте команду git log --oneline --decorate --graph --all .

$ git log -- oneline -- decorate --graph --all * c2b9e (HEAD, master) Made other changes | * 87ab2 (testing) Зміна зміни |/ * f30ab Додайте перевагу #32 - здатність до нових форматів до центрального interface * 34ac2 Fix bug #1328 - stack overflow under certain conditions * 98ca9

Гілка Git — це простий файл, що містить 40 символів контрольної суми SHA-1 комміта, на який вона вказує; тому операції з гілками є дешевими з погляду споживання ресурсів чи часу. Створення нової гілки в Git відбувається так само швидко і просто як запис 41 байта у файл (40 знаків та переклад рядка).

Це принципово відрізняє процес розгалуження Git від більш старих систем контролю версій, де всі файли проекту копіюються в інший підкаталог. Залежно від розміру проекту операції розгалуження в таких системах можуть займати секунди або навіть хвилини, коли в Git ці операції миттєві. Оскільки при комміті ми зберігаємо покажчик на батьківський коміт, то пошук підходящої бази для злиття гілок робиться автоматично і, як правило, дуже простий.Ці можливості спонукають розробників частіше створювати та використовувати гілки.

Давайте подивимося, чому і вам має сенс робити так само.

Як правило, при створенні нової гілки ви хочете відразу на неї перейти - це можна зробити використовуючи команду git checkout -b .

Починаючи з Git версії 2.23, ви можете використовувати git switch замість git checkout , щоб:

• Перейти на існуючу гілку: git switch testing-branch .
• Створити нову гілку і перейти на неї: git switch -c new-branch . Прапор -c означає створення, але також можна використовувати повний формат: --create.
• Повернутися до попередньої гілки: git switch - .

Як видалити гілку Git віддалено та локально?

Git – це система контролю версій, яка допомагає розробникам управляти змінами та ефективно співпрацювати над проектами. Гілки Git дозволяють одночасно працювати над різними частинами одного проекту, не заважаючи один одному коду. Гілки служать окремими екземплярами проекту зі своєю історією коммітів та кодовою базою.

Це означає, що кілька розробників можуть одночасно працювати над тим самим файлом, не впливаючи на роботу один одного. Це також дозволяє тестувати нові функції перед інтеграцією в основний проект, що дозволяє розробникам експериментувати з новими ідеями, не впливаючи на стабільність існуючого коду.

Пояснення гілок Git

Гілки Git використовуються для створення альтернативного набору змін, не торкаючись основної гілки або ствола. Простіше кажучи, гілки - це копії вашого репозиторію, над якими ви можете працювати незалежно і за бажання об'єднати їх пізніше.

Кожна гілка має свою власну історію, повідомлення про фіксацію та файли, що дозволяє кільком співавторам одночасно вносити зміни, не заважаючи роботі один одного. Наприклад, якщо у вас є функція, яку ви хочете розробляти окремо від основної гілки, доки вона не буде готова до використання у робочому середовищі; створіть нову гілку для цієї функції в Git, потім перейдіть в цю нову область робочого процесу, де ви виконуватимете всі свої завдання з розробки, пов'язані виключно з завершенням цієї функції, перш ніж знову об'єднатися з її батьківською гілкою (швидше за все, що розробляється іншими) .

Важливість видалення гілок Git

Git неймовірно гнучкий; однак така гнучкість може призвести до захаращення репозиторію, якщо не керувати ним належним чином. Чим більше гілок у репозиторії, тим складніше ефективно переміщатися ними і швидко знаходити те, що шукаєте.

Старі або гілки, що не використовуються, можуть накопичуватися з часом, оскільки вони застарівають або стають непотрібними для майбутніх циклів розробки. Таким чином, видалення гілок git стає необхідним, оскільки воно підвищує ясність, зберігаючи у вашому репозиторії лише відповідні версії.

Як видалити гілку Git локально

Перевірити поточну гілку

Перед видаленням локальної гілки необхідно перевірити активну на даний момент гілку. Відкрийте командний рядок у Windows або Термінал на Mac і перейдіть до конкретного каталогу проекту. Використовуйте наступну команду:

Ця команда показує всі гілки доступні у вашому локальному репозиторії.

Поточна гілка буде виділена символом зірочки (*) ліворуч від неї.Важливо перевірити та підтвердити, що ви зараз не працюєте над гілкою, яку збираєтесь видалити.

Видалити локальну філію

Після того, як ви переконалися, що не працюєте над гілкою, яку необхідно видалити, скористайтеся одним із цих методів:

Використання інтерфейсу командного рядка (CLI)

Найпростіший спосіб видалити локальну гілку git – використовувати команди CLI. Запустіть цю команду –

Наведена вище команда видаляє певну гілку git, вказану ''. Зверніть увагу: якщо в цю конкретну гілку git включені будь-які незв'язані зміни, їх не можна видалити за допомогою цього методу, доки ці зміни не будуть об'єднані.

Використання коду Visual Studio (VS Code)

Видалення гілок за допомогою VS Code пропонує користувачам візуальну допомогу та знижує ймовірність помилок введення під час виконання команд Git. Спочатку відкрийте VS Code, а потім відкрийте папку вашого проекту.

Виконайте такі кроки.

• Натисніть одночасно клавіші Ctrl+Shift+P.
• Введіть "Git: видалити гілку".
• З'явиться список доступних гілок.
• Виберіть та натисніть Enter над потрібною гілкою для видалення.

Після підтвердження вашого вибору VS Code виконає команду видалення Git і назавжди видалить вибрану гілку git з локальних репозиторіїв.

Видалення Git, що не використовується, з вашого робочого простору може допомогти зберегти ясність на етапах розробки проекту і в кінцевому підсумку підвищити швидкість вашого ПК. Дуже важливо вживати запобіжних заходів при видаленні гілок git, оскільки помилкове видалення не тієї гілки може призвести до втрати часу і зусиль, витрачених на проект.

Як видалити гілку Git віддалено

Перевірте віддалені філії

Перш ніж видаляти віддалену гілку, важливо переконатися, що вона існує у віддаленому репозиторії. Щоб перевірити список усіх віддалених гілок, використовуйте в терміналі наступну команду:

Ця команда відобразить усі видалені гілки вашого репозиторію разом із відповідними вищими репозиторіями.

Видалити віддалену гілку

Використання інтерфейсу командного рядка

Щоб видалити гілку віддалено з вашого репозиторію Git за допомогою CLI, використовуйте таку команду:

Замініть `` на ім'я віддаленого репозиторію і `` на ім'я гілки, яку ви хочете видалити. Наприклад, якщо ви хочете видалити гілку «функція/вхід» з вашого репозиторію GitHub, ви повинні запустити.

git push origin --delete feature/login

Це призведе до видалення функції/логіну з вашого репозиторію GitHub.

Використання VS-коду

Видалення видаленої гілки за допомогою VS Code просто і зрозуміло. Щоб досягти цього, виконайте такі дії:

• Відкрийте VS Code і перейдіть до «Керування версіями», клацнувши його на вертикальній панелі дій ліворуч.
• Натисніть «Гілки» у нижній частині системи керування версіями.
• Звідти знайдіть і клацніть правою кнопкою миші цільову гілку (ту, яку потрібно видалити).
• Виберіть "Видалити віддалену гілку", після чого вам буде запропоновано підтвердити дію, перш ніж продовжити.

VS Code автоматично виконує «git push» при видаленні віддаленої гілки з інтерфейсу користувача.

Найкращі практики з видалення гілок Git

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

Важливість угод про імена

Перша найкраща практика — встановити та дотримуватися правильних угод про імена для ваших гілок Git. Це особливо важливо у великих проектах, де код пишуть кілька розробників.

Наслідуючи угоду про імена, легше визначити, яка гілка яка, і уникнути випадкового видалення неправильної. Однією з популярних угод про імена є використання префікса, що ідентифікує тип гілки.

Наприклад, feature/ може вказувати гілку для додавання нових функцій, а bugfix/ може вказувати гілку для виправлення помилок. Крім того, включення номера заявки Jira або Trello у назву гілки може допомогти відстежувати, до яких проблем належить кожна гілка.

Процедури резервного копіювання та відновлення

Друга найкраща практика – мати процедури резервного копіювання та відновлення перед видаленням будь-яких гілок Git. Це означає створення резервних копій важливих даних, коду або файлів в іншому місці, перш ніж видаляти щось із вашого репозиторію.

Якщо ви випадково видалили важливу гілку, є способи відновити її за допомогою команд Git, таких як git reflog або git fsck. Однак ці команди можуть виявитися складними та забирати багато часу, якщо ви з ними не знайомі.

Завжди краще мати резервну копію у разі, якщо щось піде негаразд. Дотримання правильних угод про імена та наявність процедур резервного копіювання та відновлення можуть запобігти помилкам при видаленні гілок git з вашого репозиторію.

Висновок

Видалення гілок Git – життєво важлива частина підтримки чистої та ефективної бази коду. У цій статті ми розглянули, як видаляти гілки локально та віддалено за допомогою інтерфейсу командного рядка та коду Visual Studio.Ми також обговорили найкращі практики щодо угод про імена та процедури резервного копіювання, щоб гарантувати, що важливий код не буде втрачено в процесі видалення.

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

Статті з цієї тематики:

• Автоматичне створення, видалення та запис файлів під час запуску в Ubuntu
• Знайдіть та видаліть файли старші X днів у Linux
• Як безпечно і назавжди видалити ваші дані в Linux
• Як знайти та видалити найстаріший файл у каталозі в Linux
• Знайдіть та видаліть файли, в іменах яких міститься певний текст у Linux
• Як знайти і видалити повторювані файли в Linux
• Як видалити репозиторій і ключ GPG в Ubuntu
• Видаліть файли, до яких не було доступу протягом певного часу в Linux
• Знайти та видалити непрацюючі символічні посилання на Linux
• Додавання, видалення та надання привілеїв Sudo користувачам у CentOS
• Додавання, видалення та надання привілеїв Sudo користувачам в Arch Linux
• Додавання, видалення та надання привілеїв Sudo користувачам в Alpine Linux
• Як видалити застарілі Vagrant Box у Linux
• PHP MySQL DELETE, TRUNCATE, DROP Table
• Додавання, видалення та надання привілеїв Sudo користувачам в Ubuntu