Использование Git / ртутный на проектах с непрерывным рефакторинга?

голоса
20

Я пытаюсь понять, действительно ли я иметь какие-либо дела для использования GIT / Mercurial.

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

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

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

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

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

Задан 10/12/2008 в 10:43
источник пользователем
На других языках...                            


6 ответов

голоса
2

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

Ответил 10/12/2008 в 10:55
источник пользователем

голоса
2

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

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

Ответил 10/12/2008 в 11:56
источник пользователем

голоса
19

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

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

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

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

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

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

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

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

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

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

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

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        |
\-->-----\
         |

Вся концепция их принадлежность «голова» в таком случае исчезает. Он есть десятки голов, которые вы видите один склонен к перспективе.

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

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

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

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

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

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

Ответил 10/12/2008 в 11:59
источник пользователем

голоса
2

Я думаю , что ртутный велик. Особенно с TortoiseHg .

Одна из вещей я нахожу наиболее полезным является возможность разделить развитие функций только с основной командой.

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

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

Ответил 10/12/2008 в 12:10
источник пользователем

голоса
1

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

Ответил 10/12/2008 в 13:31
источник пользователем

голоса
11

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

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

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

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

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

Ответил 10/12/2008 в 14:00
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more