Як перейменувати гілку в Git?
Розглянемо на прикладі
Під час роботи з Git розробники часто створюють окремі гілки для нового функціонала, виправлення багів чи експериментів. І буває трапляється так, що вже після створення виникає потреба змінити назву гілки. Наприклад, ви випадково припустилися помилки в назві, вирішили дати змістовнішу або хочете дотримуватися стандартів у команді чи вони змінилися відповідно до характеру фіч, над якими зараз працюєте. У такому разі, щоб не «плодити», як то кажуть, зайві гілки, знадобиться перейменування локальної гілки.
У цій статті розглянемо, як це зробити, та розберемо повний практичний приклад.
Які команди використовують для перейменування гілок у Git?
Звичайно, існує безліч графічних інтерфейсів використання Git і там перейменування буде схожим на щось типу кнопки Rename і введення нової назви. Це доволі просто, а як це роблять у таких інструментах, можна переглянути в документації відповідного графічного інтерфейсу, який ви використовуєте. Що ж водночас відбуватиметься «під капотом», ми розглянемо нижче. Оскільки саме командний інтерфейс часто викликає багато запитань і в ньому потрібно знати напевне, як виконують ту чи іншу дію, щоб не зробити додаткових проблем у репозиторії.
У Git існує спеціальна команда для перейменування:
git branch -m <new-branch-name>
Якщо ви хочете перейменувати іншу гілку, не переключаючися на неї:
git branch -m <old-branch-name> <new-branch-name>
-mозначає move/rename.- Якщо
<old-branch-name>не вказано, Git перейменує поточну активну гілку, яку ви зараз використовуєте.
Розглянемо повний процес на прикладі
На практиці розуміння приходить найкраще, тож розглянемо крок за кроком, як працювати з гілками в Git і за потреби змінювати їхні назви.
1. Створюємо новий репозиторій та гілку
Для початку формуємо нову директорію для прикладу і переходимо до неї:
mkdir git-branch-demo
cd git-branch-demo
Для того щоб новостворена директорія була не просто папкою в системі, ініціалізуємо git-репозиторій:
git init
Тепер створюємо файл, для прикладу, просто текстовий файл. Після цього закомітимо створення файлу:
echo "Hello Git" > readme.txt
git add readme.txt
git commit -m "Initial commit"
Створюємо нову гілку:
git branch feat
Зверніть увагу, що назву навмисно робимо неповною, щоб не плутати з новою, яку ми дамо гілці під час перейменування.
2. Перемикаємося на нову гілку
Для перемикання на нову гілку виконаємо команду:
git checkout feat
Тепер ми працюємо у гілці з неповною назвою feat.
3. Перейменовуємо гілку
От ми й підійшли до перейменування гілки. Потрібно здійснити перейменування поточної активної гілки, виконавши команду, яку згадували на початку:
git branch -m feature
Тепер гілка має повну назву — feature.
4. Перевіряємо список гілок
Для виведення повного списку гілок репозиторію виконаємо команду:
git branch
Отримуємо інформацію з переліком поточних гілок. Побачимо щось схоже на екрані:
* feature
main
Такий вивід буде в тому разі, якщо маємо тільки дві гілки в репозиторії main та feature. До того ж зірочка позначає ту гілку, яка зараз активна і в якій ви вноситимете зміни безпосередньо.
Важливий момент у роботі з віддаленим репозиторієм
Якщо гілку вже запушено на віддалений репозиторій (наприклад, GitHub), то перейменування відбудеться тільки локально. Для того щоб зміни відбулися і на віддаленому репозиторії, потрібно видалити стару гілку із сервера та запушити нову. Таким чином, ми фактично створюємо нову гілку, яка є копією тієї, яку потрібно перейменувати.
Як це зробити:
# видаляємо стару гілку на сервері
git push origin --delete feat
# пушимо нову гілку
git push origin feature
# встановлюємо відстеження для локальної гілки змін на віддаленому репозиторії
git push --set-upstream origin feature
Якщо ж гілка існує лише локально, то достатньо команди git branch -m так, як ми розглядали вище.
Для чого це може знадобитися?
Як ми зазначали на початку, перейменування локальних гілок у Git — проста дія, яка допомагає підтримувати чистоту й правильний неймінг у репозиторії, це якщо загалом. Але на практиці бувають різні ситуації, і ви як технічний спеціаліст маєте добре розумітися на Git та його можливостях, щоб швидко оптимізувати взаємодію і підтримувати гігієну в репозиторії.
Таким чином, завдяки правильному неймінгу гілок ваша команда швидше орієнтуватиметься у проєкті й уникатиме плутанини.
Якщо ж ви використовуєте репозиторій в соло, то часто трапляється так, що доопрацювання фіч відкладається на певний період. І тоді, коли ви повернетеся до роботи над тією, яку розпочинали раніше, релевантний неймінг зможе економити ваш час. Ну й, звісно, ніхто не застрахований від одруківок, а вашому тімліду це може ой як не сподобатися. Тож практикуйтеся, бо це базова навичка, яка обов’язково стане у пригоді.
