dvcs - це "клон до гілки" загальний робочий процес?

Нещодавно я обговорював dvcs з колегою, тому що наш офіс починає розглядати питання про перехід від TFS (ми - магазин MS). У процесі мене дуже розгубився, тому що він сказав, що, хоча він використовує Mercurial, він не чув про команду "відділення" або "checkout", і ці умови йому були незнайомі. Поцікавившись, як можливо, що він не знав про них, і пояснивши, як відділення dvcs працюють "на місці" у ваших локальних файлах, він сильно розгубився.

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

Шукаючи цей сайт, щоб дізнатись, чи це запитували, перш ніж я побачив коментар, що багато інтернет-ресурсів пропагують цю методологію "клонування до гілки", до жалю афіші. Це насправді часто в спільноті dvcs? І які є плюси і мінуси в цьому шляху? Я б ніколи цього не робив, оскільки мені не потрібно бачити відразу кілька гілок, перемикання відбувається швидко, і мені не потрібні всі клони, що заповнюють мій диск.

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

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

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

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

http://mercurial.selenic.com/wiki/StandardBranching пояснює це детальніше. Варто також згадати, що з Mercurial 1.8 можна створити закладку ( hg bookmark) - одноразову назву для короткотривалої гілки. Закладки можна натискати, витягувати, переміщувати та видаляти.

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

• Якщо ніхто не вносив змін під час здійснення комісії, це не буде схоже на гілку DAG (спрямований ациклічний графік)
• Якщо хтось інший змінив під час вашого зобов’язання, це буде схоже на відділення в DAG, лише без назви

Запам’ятайте кнопку «fork» у Bitbucket / github?, Розгортання може розглядатися як синонім розгалуження, а те, що робить кнопка «fork», є лише клоном цього сховища до вашого облікового запису.

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

Скажіть своєму колезі, щоб навчитися вести гілки , тут дуже легко мати підручник:

D:\>mkdir lol

D:\>cd lol

D:\lol>hg init

D:\lol>hg branch
default

D:\lol>touch lol

D:\lol>hg add lol

D:\lol>hg commit -m "lol"

D:\lol>hg branch lol
marked working directory as branch lol
(branches are permanent and global, did you want a bookmark?)

D:\lol>hg branches
default                        0:35d562fafaf2

D:\lol>echo "lol" > lol

D:\lol>hg commit -m "New lol branch"

D:\lol>hg branches
lol                            1:9384f923e78d
default                        0:35d562fafaf2 (inactive)

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg update lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

D:\lol>hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
default

D:\lol>hg merge lol
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

D:\lol>hg commit -m "lol merge"

D:\lol>hg branch
default

D:\lol>hg update lol
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branch
lol

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

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

D:\lol>hg branches
default                        2:46420aca1612
lol                            1:9384f923e78d (inactive)

D:\lol>hg branch
lol

D:\lol>hg commit --close-branch -m "Obai, glorious lol branch"

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branch
lol

D:\lol>hg update default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

D:\lol>hg branches
default                        2:46420aca1612

D:\lol>hg branches --closed
default                        2:46420aca1612
lol                            3:4b79c577e029 (closed)

Сподіваюся, це очистить ваші сумніви щодо розгалуження DVCS, тут гілки вже не страшні.

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

Ця методологія пропагується у багатьох інтернет-ресурсах, особливо для Hg. Я ніколи не бачив, щоб він використовувався у виробництві, в умовах CI набагато частіше зустрічаються короткочасні гілки функцій, ніж додаткові клони сховищ. Я не бачу переваги в цьому, якщо що-небудь зробить вашу історію більш заплутаною, не меншою, і це також не принесе вам нічого. Якщо ви хочете переглянути свій новий код поруч зі старим кодом, ви можете скористатися інструментом diff / merge для перегляду двох комітетів поруч, з додатковою перевагою, що ви побачите зміни.