Коли настав час видалити гілку функції git?

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

Робочий процес:

git co -b feat-xyz
hack hack
git ci
hack some more
git ci
git co master
git merge feat-xyz
smoke test
git br -d feat-xyz

Тут є якісь проблеми?

Видалення після злиття - звичайний спосіб. Ось чомуgit branch -d yourbranchname перевіряє, щоб гілка була повністю об’єднана, перш ніж її буде видалено.

Є кілька причин, якими я можу подумати, щоб зберегти гілку навколо: можливо, ви захочете затримати її на випадок, якщо у вас з’являться помилки, щойно вони з’являться у виробництві, або ви хочете отримати історичний запис.

У будь-якому випадку у вас є можливість позначити голову гілки, перш ніж видалити її. Тег схожий на гілку, оскільки є покажчиком на коміт, за винятком кількох незначних відмінностей: 1) порцеляна зазвичай не відображає теги в командах-дослідниках, таких як git show-branch або tab-auto complete під час оформлення замовлення, 2) перевіряючи один, ви потрапляєте у відокремлену (невід'ємну) ГОЛОВУ 3) ви можете залишити " повідомлення про позначення ", що призводить до того, що тег зберігається як об'єкт у сховищі об'єктів, як фіксація.

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

Я видаляю після злиття, але завжди роблю a git merge --no-ff, щоб уникнути швидкого пересилання вперед, щоб історія гілок була видно на графіку. Мені подобається мати історію того, де гілка об’єкта відійшла від гілки розробки і де вона приєдналася назад:

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

Я можу подумати з двох причин, чому ви хочете трохи зберегти гілку функцій навколо:

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

На практиці більшість випадків видалення після злиття просто чудово.

Типовим буде робочий процес

 // Create new branch
 $ git checkout -b myfeature
 // and then do some changes and commit them

 // Switch to master branch
 $ git checkout master

 // Merge myfeature to master. --no-ff will always keep branch information.
 $ git merge --no-ff myfeature

 // Delete myfeature branch
 $ git branch -d myfeature

 // Push the changes
 $ git push origin master

я думаю, що це типовий робочий процес (видалення після злиття)

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