dvcs - это "клон на ветку" распространенный рабочий процесс?

9

Недавно я обсуждал dvcs с коллегой, потому что наш офис начинает рассматривать переход с TFS (мы магазин MS). При этом я очень запутался, потому что он сказал, что, хотя он использует Mercurial, он не слышал о командах «ветка» или «оформить заказ», и эти термины были ему незнакомы. Задумавшись, как это возможно, что он не знал о них, и объяснив, как ветки dvcs работают «на месте» в ваших локальных файлах, он был в замешательстве.

Он объяснил, что подобно тому, как работает TFS, когда он хочет создать «ветку», он делает это путем клонирования, поэтому у него есть полная копия репо. Мне это показалось очень странным, но я должен признать, что вы можете одновременно работать с двумя ветвями, потому что файлы разные.

Когда я искал этот сайт, чтобы узнать, спрашивался ли он об этом, до того, как я увидел комментарий, что многие интернет-ресурсы продвигают эту методологию "клонирования в ветку", к ужасу автора. Это на самом деле распространено в сообществе dvcs? И каковы некоторые плюсы и минусы такого пути? Я бы никогда этого не сделал, поскольку мне не нужно видеть несколько веток одновременно, переключение происходит быстро, и мне не нужны все клоны, заполняющие мой диск.

workflows dvcs branching

— Tesserex
источник

7

это удержание от рабочих процессов CVS и SVN, помните: «с молотка все выглядит как гвоздь»

1

@JarrodRoberson - Только если вы ограничиваетесь тем, как gitработает. С hgэтим обычно учат первый рабочий процесс, и он все еще очень полезен.

— Марк Бут

3

Помимо общего преимущества / недостатка возможности видеть обе ветви, я думаю, что для этого есть специфическое для Mercurial преимущество.

Если вы клонируете, чтобы создать ветку, вы можете удалить клон позже, если не хотите сохранять свои изменения. Если вы решите объединить их, то тот факт, что вы решили отделить свои изменения таким образом, не виден никому другому.

Напротив, если вы используете hg branchдля создания новой именованной ветви, имя ветви записывается в историю, когда вы фиксируете ее, видно всем и должно быть достаточно уникальным, чтобы избежать возможной путаницы позже. Это может быть неуместно, если ваша ветвь предназначена для разработки некоторой экспериментальной функции или для изменения, которое может оказаться небольшим.

Если вы используете именованные ветви для поддержки выпущенных версий вашего программного обеспечения, а также используете их для разработки краткосрочных функций или исправлений, легко запутаться, потому что нет никакого способа (кроме соглашений об именах) разделить эти два вида ветвей.

http://mercurial.selenic.com/wiki/StandardBranching объясняет это более подробно. Также стоит упомянуть, что начиная с Mercurial 1.8, можно создать закладку ( hg bookmark) - одноразовое имя для кратковременной ветви. Закладки можно нажимать, тянуть, перемещать и удалять.

— Benj
источник

2

Я не использовал Mercurial, но у Git нет этой проблемы. Я могу весь день локально переходить, объединяться в ветку разработки, нажимать, и никто не должен смотреть на названия моих веток.

— Эндрю Т Финнелл

3

@AndrewFinnell: Это действительно не вписывалось в вопрос, но я хотел сказать, что это не обязательно проблема - есть также некоторые преимущества в способе именованных веток в Mercurial. Например, вы можете увидеть, на какой ветке изначально был сделан коммит, что может быть полезно знать.

— Бендж

1

@AndrewFinnell - Я очень скучаю по именованным веткам git, привыкнув к ним hg. Кроме того, необходимость помнить, что git branchкаждый раз, когда я хочу создать ветку, раздражает, по сравнению hgс автоматическим созданием неназванных веток.

— Марк Бут

Вы по-прежнему можете использовать расширение полосы в комплекте, чтобы удалить свою ветку в hg. Mercurial лучше поддерживает изменение истории в

— наши

2

Каждый раз, когда вы делаете коммит в 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, здесь ветки больше не страшны.

— dukeofgaming
источник

0

Лично я бы не беспокоился о том, что код заполняет мой диск ... во-первых, это всего лишь код, а во-вторых, вы не собираетесь хранить все свои клоны вечно.

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

— philosodad
источник

Я широко использовал это в производстве, с hg. Возможность перемещаться между несколькими hgрепозиториями может быть действительно мощным инструментом для совместной работы. Только возможность извлекать из непрозрачных gitрепозиториев может существенно ограничить ваши возможности с таким рабочим процессом.

— Марк Бут