Использование git / mercurial в проектах с постоянным рефакторингом?

Я пытаюсь понять, действительно ли у меня есть какие-либо аргументы в пользу использования git / mercurial.

Проекты, над которыми я работаю, - это java и c # проекты, обычно с 5-20 людьми, работающими над общей целью («релиз»). Большинство разработчиков являются профессиональными разработчиками, реорганизовывать код всего времени . Поэтому, когда типичное ядро ​​Linux имеет большое количество относительно независимых изменений в отдельных файлах, мы постоянно меняем процесс рефакторинга - часто поражая много файлов и много кода. Никто не боится изменить код здесь.

Теперь с помощью Subversion мы решаем эту проблему, оставаясь очень близко к SVN HEAD. Некоторые из нас даже имеют автоматические svn up, которые запускаются на Jabber-трансляции сервера сборки. Большинство из нас также научились (или учатся очень быстро), как планировать свою работу, чтобы держаться поближе к SVN HEAD. Если вы выполняете серьезный рефакторинг, мы постепенно сгибаем дерево исходных текстов в новом направлении, вместо того, чтобы уходить слишком долго. Иногда вы просто планируете операцию рефакторинга и начинаете в менее загруженных областях. После нескольких лет работы таким образом, это становится второй натурой. Большинство из нас просто никогда не покидают «зону комфорта», так как находятся менее чем в 2 часах езды от головы свн. Автоматизированная сборка и svn head - это проект «Импульс», и нам это нравится.

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

И мерзавец, и меркуриал звучат круто, мерзавец немного больше, так как я больше похож на МакГайвера, чем на Джеймса Бонда. Но когда дело доходит до создания случая для фактического переключения, создается впечатление, что мы с Линусом живем на двух разных планетах. Большую часть времени мы хотим, чтобы наши команды сосредоточились на HEAD.

Как GIT может улучшить контроль версий? Как GIT позволит мне улучшить мой процесс? Я динозавр подрывной деятельности?

10.12.2008 09:43:11
6 ОТВЕТОВ
РЕШЕНИЕ

С точки зрения менталитета иногда полезно иметь возможность создавать мягкую ветвь, выполнять все изменения в мягкой ветке, проверять результат изменений в мягкой ветке, а затем, когда мягкая ветвь "завершена" msgstr ", реинтегрируйте его с основной веткой локально, повторно протестируйте, а затем распространите.

В некоторых случаях это лучше, чем спешная голова, потому что у вас нет постоянного прерывания существования чужого отладочного кода, запутывающего ваш код для добавления ошибок без обработки.

Это также означает, что вы можете делать коммиты чаще, давая более полную историю, потому что коммиты не появляются мгновенно, создавая проблемы.

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

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

  1. Пройдены тесты самостоятельно
  2. Пройденные тесты после того, как изменения основных веток были согласованы с софт-веткой

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

(Что также ограничивает область решения проблем, потому что вам по большей части нужно тестировать только свои собственные изменения, а когда вы «сделали», только тогда вам нужно беспокоиться о том, что сделали все остальные, и что они сделали Также должны проходить тесты, что означает, что когда что-то не получается , вам нужно только посмотреть, что вы сделали, чтобы решить проблему)

Но буду ли я постоянно обновляться с центрального репо в свою мягкую ветку? Это действительно суть моей проблемы

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

«Непрерывное обновление» становится ненужным, потому что у вас не возникают те же проблемы.

a  b   center
         |
         |
         /      Key:   / - | \   = Flow
/----<---|             < >       = Flow Directions
|  /--<--/             *         = Commit 
*  |     |             T         = Test
|  *     |             M         = Merging with "Current" state of common branch
*  |     |             C         = Tests Complete and Current state is "sane"
|  *     |
T  |     |
|  T     |
|  C     |
|  |/-<--/
*  M     |
|  T     |
*  C     |
|  \--->-\
*  /---<-/
T  |     |
C  *     |
|/-----<-/
M  |     |
T  *     |
|  T     |
*  C     |
|  |/-<--/
*  M     |
T  T     |
C  \-->--\
|/---<---/
M        |
T        |
C        |
\---->---\
         |

Кроме того, из-за того, как работает система, позже это также может произойти:

a  b   center
|  |     |
T  |     |
C  *     |
|/</     |
M  |     |
|  *     |
T        |
C        |
|/----<--/
M        |
T        |
C        |
\-->-----\
         |

Вся концепция того, что они являются "головой" в таком сценарии, исчезает. Это десятки голов, которые вы видите перспективными.

Я мог бы также добавить, что эти логические ветви, хотя и отображаются здесь как отдельные, вполне могут представлять либо отдельные места для оформления покупок, либо просто разные мягкие ветви на отдельном компьютере. A & B может быть одним разработчиком.

По сути, «Постоянно обновлять мою софтбранч из mainbranch» концептуально не имеет смысла. Потому что на самом деле, будут изменения, которые еще не представлены в основной ветке, и когда вы узнаете, что они были перенесены или нет? SVN дает вам эту ложную иллюзию «единичного» состояния кода, когда в действительности, когда один пользователь открывает файл в своем текстовом редакторе, он фактически создает очень короткую жизненную мягкую ветвь, изменение, которое происходит, о котором никто не знает, и чтобы эта иллюзия была поддержана так, как вы думаете, она работает, по сути, пользователь должен фиксировать после каждого персонажа, что вряд ли практично. Таким образом, на самом деле люди привыкли к тому, что разные места «несинхронизируются» друг с другом, и изучают способы их решения, чтобы больше не было проблем.

Кроме того, «постоянное обновление моего дерева с изменениями всех остальных» имеет ключевую проблему: у вас слишком много отвлекающих факторов, вас постоянно бомбардируют все, что делают все остальные, и если они делают серию из 1 Линия обязуется протестировать что-то, что они не могут проверить на своей машине, тогда у вас будет кошмар с постоянно меняющимся файлом, и пользователи, видящие случайные изменения, не смогут их понять.

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

Если у вас есть какие-либо сомнения

Начните с чего-то простого и не переходите к «холодной индейке», некоторые концепции в DSCM могут быть немного пугающими (я видел трагический отказ многих понять концепцию вертикально сложенных мягких ветвей), переместить небольшую не Важная часть кодовой базы для Git / Mercurial и немного поиграйте с ней, поэкспериментируйте с преимуществами и тем, что он может сделать. Нет лучшего доказательства, чем испытать его на себе, и все мои милые объяснения вряд ли дадут вам то, что вам нужно понять, и выучить его можно только, попробовав его и провалив несколько раз (потому что неудача - это ключевая часть обучения)

19
10.12.2008 12:27:56
Хорошее предложение. Мы дисциплинированная группа TDD'еров, так что «срочно отправленная голова» обычно работает. Тревожные колокольчики звонят, когда ломается сборка, и тогда все держатся подальше от головы;)
krosenvold 10.12.2008 11:06:08
Но буду ли я постоянно обновляться с центрального репо в свою мягкую ветку? Это действительно суть моей проблемы.
krosenvold 10.12.2008 11:46:24
Спасибо за действительно хороший пост. Мне придется читать, перечитывать и думать об этом. Извините, я не могу дать вам больше одного +1.
krosenvold 10.12.2008 12:40:28

Например, вы можете использовать GIT в автономном режиме, чтобы люди могли продолжать работать под управлением источников даже во время путешествий или дома. Если любой случай может подать заявку, вы могли бы извлечь выгоду из GIT.

2
10.12.2008 09:55:29

Дал вам один голос за хорошее настроение в трещине svn / динозавра.

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

2
10.12.2008 10:56:46

Я думаю, что Mercurial это здорово. Особенно с TortoiseHg .

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

Допустим, вся команда состоит из 20 человек, но вы хотите протестировать и разработать только одну функцию с командой из 3-4 человек, прежде чем вносить в основной репозиторий. Затем с помощью Mercurial вы можете просто синхронизировать код между кодировщиком 3-4, пока вы не будете полностью удовлетворены, прежде чем совершать операции с основным репозиторием.

Или вы даже можете быть своей собственной командой, например. когда вы хотите протестировать свой код на нескольких платформах перед фиксацией в основном репозитории.

2
7.02.2012 22:02:48

то, что вы описали в SVN, можно сделать с помощью git / mercurial

1
10.12.2008 12:31:46
Правда, но я (для одного) поддержал бы это.
Frank V 20.10.2009 19:25:28

То, как ваша команда использует Subversion, означает, что происходит много усилий по слиянию. Почти каждый раз, когда член команды обновляется до самой последней основной ветки, они объединяют свою рабочую копию с последней основной, даже если на этом этапе они не фиксируют свои собственные изменения. Накладные расходы на слияние имеют тенденцию к тому, чтобы быть продуктом коэффициента фиксации и количества членов команды, и, поскольку частота фиксации является функцией числа членов команды, ваши затраты на управление исходным кодом составляют O (N ^ 2).

В модели Mercurial / Git это объединяющее усилие будет распределено между командой. Если вы регулярно извлекаете наборы изменений у всех, то часто вы обнаружите, что другие уже выполнили почти всю работу по слиянию, которую вы, возможно, должны были выполнить. И в случаях, когда слияние что-то сломало, часто люди уже исправят это. Согласование пары ветвей должно быть выполнено только один раз, и, поскольку скорость генерации новых ветвей пропорциональна количеству членов команды, накладные расходы на управление исходным кодом составляют O (N).

Я ожидаю, что 20 разработчиков, работающих близко к голове над одной веткой, вероятно, потребуют изрядного количества работ по слиянию (работа с конфликтами и регрессии из-за независимой разработки), поэтому я буду удивлен, если вы попробуете Mercurial / Git так и не нашел полезного выигрыша в производительности. Как вы думаете, вы могли бы управлять 100 разработчиками с вашим текущим прогрессом? Я бы оценил число разработчиков ядра Linux в 4000, и тем не менее они много чего сделали, и общие накладные расходы на управление исходным кодом должны быть приемлемыми.

Пока ваша система управления исходным кодом отслеживает общее происхождение, слияния часто происходят автоматически. У каждого слияния есть шанс либо стать текстовым конфликтом, либо нарушить сборку и тестирование из-за взаимодействия между изменениями; чем меньше слияний вы должны делать, тем меньше времени вам придется тратить на решение любой проблемы.

Следовательно, действительно большой выигрыш в том, что пользователи Mercurial / Git больше не боятся веток. До BitKeeper (насколько мне известно, инструмента, который действительно ввел этот способ работы), долгое время ветвились бомбы замедленного действия, время от времени взрывающиеся и занимавшие неделю, чтобы восстановиться. Теперь мы можем без колебаний разветвляться, с уверенностью, что сможем объединиться позже. В здоровой команде другие могут видеть ваши ветки в процессе и объединить их со своими, а потом приложить усилия, если они сочтут это целесообразным. В централизованной модели, если у каждого разработчика было 3 или 4 активных ветки, и я исправляю, говоря, что это O (N ^ 2), то вы просто увеличили накладные расходы на управление исходным кодом в 3ish ^ 2 раза, т.е. порядка, которого, вероятно, достаточно, чтобы действительно повредить общее здоровье, богатство и счастье.

11
15.12.2008 15:36:07
Ну , это сенсационное сообщение. Наконец-то настоящая победа, которая имеет смысл!
krosenvold 10.12.2008 13:10:01
Но объединение не является дорогостоящим, и O (N ^ 2) на самом деле означает только циклы процессора и генерирование тепла процессором. Это конфликты, которые стоят денег. Мы не получаем много конфликтов, потому что мы остаемся рядом с головой. Ребята из Linux не проводят рефакторинг так, как мы. Вы не можете сделать это в C. Хм. Должен думать. Все еще хороший ответ!
krosenvold 10.12.2008 20:15:59
Большинство слияний действительно автоматические и не имеют других последствий. Однако частота конфликтов примерно пропорциональна слияниям. Я попытался уточнить мой первоначальный ответ.
Dickon Reed 15.12.2008 15:47:41