найкращі практики в ртутному: гілка проти клонування та часткове злиття?

... так що я звик до простої речі з Mercurial ( add, commit, diff) і дізнався про .hgignore файлу (яй!) І отримали повісити створення і перемикання між гілками ( branch, update -C).

У мене є два основних питання:

1. Якби я це зробив, якщо я перебуваю у відділенні "Відділення1" і хочу внести деякі, але не всі зміни з відділення "Відділення2"? Зокрема, якщо всі зміни знаходяться в одному підкаталозі. (Я думаю, я міг би просто клонувати ціле сховище, а потім скористатися інструментом злиття каталогів, як Beyond Compare, щоб вибрати та вибрати мої редагування. Здається, що повинен бути спосіб просто ізолювати зміни в одному файлі чи одному каталозі.)

2. Перемикатися між гілками за допомогою update -Cздається настільки простим, мені цікаво, чому я б турбувався використанням clone. Я можу подумати лише про декілька причин (див. Нижче) - чи є деякі інші причини, яких я втрачаю?

   a. якщо мені потрібно діяти одночасно з двома версіями / гілками (наприклад, зробити різницю між показниками продуктивності)

   b. для резервного копіювання ( cloneсховище на мережевий диск у фізично іншому місці)

   c. зробити збір та вибір злиття, як я вже згадував вище.

Я використовую клон для:

• Недовговічні місцеві філії
• Клонування до різних машин та серверів розробки

Колишнє використання для мене досить рідкісне - головним чином, коли я випробовую ідею, від якої, можливо, хотів би повністю відмовитись. Якщо я хочу об’єднати, я хочу об’єднати ВСІ зміни. Таке розгалуження в основному призначене для відстеження гілок різних розробників, щоб вони не заважали один одному. Тільки для пояснення цього останнього моменту:

• Я продовжую працювати над своїми змінами і тягну за змінами своїх співробітників, а вони тягнуть мої.
• Коли мені буде зручно, я об’єднаю ВСІ зміни з однієї (або всіх) цих гілок у мою.

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

В основному я дивлюся на це так:

• Іменовані гілки призначені для розробки різних гілок або версій програми
• Клони призначені для управління різними внесками в одну і ту ж версію програми.

Це моя думка, хоча насправді це питання політики.

Щодо питання 1, вам слід трохи чіткіше зрозуміти, що ви маєте на увазі під «змінами». Що з цього ви маєте на увазі:

1. "Я хочу перенести деякі, але не всі, набори змін в іншій гілці в цю."
2. "Я хочу перетягнути в цю останню версію деяких, але не всіх файлів з іншої гілки."

Якщо ви маєте на увазі пункт 1, вам слід розглянути розширення Transplant , зокрема ідею вибору декількох наборів змін.

Якщо ви маєте на увазі пункт 2, ви зробите наступне:

• Оновіть до гілки, у яку ви хочете внести зміни.
• Використовуйте hg revert -r <branch you want to merge> --include <files to update>для зміни вмісту цих файлів таким, яким вони є на іншій гілці.
• Використовуйте hg commitдля фіксації цих змін у гілці як нового набору змін.

Що стосується питання 2, я ніколи не використовую клони сховищ для розгалуження, тому я не знаю. Я використовую іменовані гілки або анонімні гілки (іноді із закладками).

У мене є ще один варіант, на який ви можете розглянути: ртутні черги.

Ідея полягає в тому, щоб мати пакет виправлень (без комітів, "справжні" виправлення) поверх поточного робочого каталогу. Потім ви можете додати або видалити застосовані виправлення, додати один, видалити його, додати інший і т. Д. Один окремий виправлення або їх підмножина закінчується новою "функцією", як ви, мабуть, хочете зробити з гілками. Після цього ви можете застосувати патч як зазвичай (оскільки це зміна). Гілки, мабуть, корисніші, якщо ви працюєте з кимось іншим ...?