Лучшая практика Управления исходным кодом - периодически обновление Вашей рабочей копии с репозитория

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

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

• A. Автоматическое слияние SVN (или TFS, или что-то еще) и
• B. проще, когда ты человек должен разрешать конфликты.

Это, конечно, зависит от того, сколько других разработчиков используют тот же код и насколько вероятно, что они будут работать с модулем, над которым вы работаете. (Например, сейчас я единственный, кто работает над моим проектом. Я не обновляюсь почти так часто, как когда другие тоже.)

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

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

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

Другой способ - работать в своей ветке, а не в стволе. Таким образом, единственное слияние будет выполнено, когда будет выполнена ваша функция / исправление ошибки / что-то еще. Никто другой не будет делать коммиты в вашей ветке, так что вы в безопасности, пока не закончите.

Есть что-то среднее земля - ​​вы можете сохранить свои изменения в ветке, отдельно от текущих изменений в основной ветке. Это очень просто в git и менее просто (я бы сказал) в Subversion. Это позволяет вам регулярно извлекать изменения из ствола без автоматического "риска" испортить ваши локальные изменения из-за конфликтов с коммитами ствола. Я думаю, что это основная причина того, почему вы не хотите получать обновления, а именно потому, что вы не готовы к ним. Однако вы увидите, что изменения произошли, и это очень хорошо. Наличие ваших изменений в отдельной ветке означает, что вы можете попытаться объединить восходящие изменения, но если они не совпадают, вы можете прервать это слияние и немного поработать над своим кодом, пока не будете готовы действительно потратить усилия. для разрешения конфликтов.

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

• обновлять каждый раз, когда вы сидите перед ПК.
• обновляете перед каждой фиксацией

=> годы беспроблемного использования SCM.

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

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

• Обновить так часто, как вы считаете нужным. По крайней мере, каждое утро. И каждый раз, когда товарищи по команде говорят вам об этом. Каждый раз, когда вы знаете, что кто-то совершил что-то в той области, где вы работаете.

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

Как уже упоминалось несколько раз выше, мой совет аналогичен:

• Обновляйте часто, как можно чаще, но по крайней мере раз в день, и
• Завершайте часто, idem (но, конечно, у вас должна быть скомпилированная/работающая/тестированная функция)

Второй пункт также очень важен: как только "что-то" работает, это должно быть зафиксировано, в литературе говорится "don't go blind", i. e., не держите разработку на жестком диске в течение месяца, пока она не станет идеальной (она все равно никогда не станет таковой :-))

Это основная идея, лежащая в основе Continuous Integration (много материала на сайте Мартина Фаулера и очень понятные объяснения).

Напоследок:

• Что касается "синтаксических" конфликтов, не беспокойтесь о них, они редки и легко устранимы,
• Что касается "семантических" или "архитектурных" конфликтов, еще важнее обнаружить их как можно скорее, отсюда и девиз: обновлять часто, коммитить часто, объединять часто (для людей, использующих DVCS), и часто тестировать интегрированную функцию, чтобы обнаружить эти потенциальные семантические конфликты.