Контроль версий - блокировка против слияния?

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

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

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

Какая самая веская причина использовать один метод вместо другого?

Там, где я нахожусь, у нас есть настраиваемый (кашляющий) слой поверх SourceSafe, который блокируется по проекту! Плакать...

Benjol 09.06.2009 14:58
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
27
1
6 746
12

Ответы 12

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

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

В распределенных системах контроля версий, таких как Git, каждая проверка по сути является ветвью.

Перейдя от заблокированной модели к модели слияния, сделаю следующие наблюдения:

  • Большинство пользователей слияния, как правило, остаются довольно близкими к «головной» версии ветки, над которой они разрабатывают. Обычно это означает, что серьезные проблемы слияния встречаются нечасто.
  • За 10 или около того лет использования модели слияния я столкнулся только с парой действительно серьезных проблем слияния. В обоих случаях это произошло потому, что два человека решили одну и ту же проблему.
  • Обычно мы решаем проблемы слияния без связи с другой стороной;)
  • Модель «Lock» VC подходит, если система находится в стабильной фазе обслуживания с небольшими изменениями.
  • Модель блокировки ВК подойдет, если у вас небольшая команда (я бы сказал, 1-2 человека;)

Модель слияния IMHO намного лучше, потому что она дает мне свободу при работе с кодом. Возможно, это не лучшая модель для «потемнения» с кодом на 1 неделю, но опять же, для модели «блокировки» это не менее большая проблема. Никто не должен отказываться от кода в течение недели.

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

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

Блокировка является реактивной ... слияние проактивно ...

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

Adam Byrtek 12.11.2008 10:35

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

Maxam 12.11.2008 10:43

Я не могу понять, как слияние экономит время, учитывая ваш пример - «представьте, что оба программиста завершают рефакторинг одного и того же кода» - для меня это звучит так, как будто вы дублируете работу. Вы можете уточнить?

Gavin Miller 26.11.2008 19:27

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

MarkJ 30.12.2011 16:06

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

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

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

Распространенная жалоба на блокировку VCS заключается в том, что у вас возникает проблема, когда кто-то уезжает в отпуск или на конференцию, оставляя некоторые файлы заблокированными :)

А затем администратор снимает блокировку, и остальная команда продолжает. Человек, который не соблюдает правила этикета, должен иметь дело с приведением своей работы в норму.

Mark 30.07.2015 06:23

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

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

Кроме того, имейте в виду, что существует возможность сочетания обоих:

  • "lock": первый разработчик, изменивший файл, будет первым его зафиксировать. Любые другие разработчики также могут изменить тот же файл, но им придется подождать, пока первый из них зафиксируется, прежде чем начинать слияние своих собственных изменений.
  • «слияние»: когда разработчик фиксирует файл, уже измененный коллегой, он объединяет свои изменения.

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

Защитники блокировки ошибаются, если есть такой человек, который защищает это. Каждая команда, с которой я встречался, использующая старомодную систему блокировки, жаловалась на нее и с тоской смотрела на людей, использующих другие методы. Я работал над проектом для одного места, которое было вынуждено использовать систему блокировки, и решил вообще не использовать КОНТРОЛЬ (поэтому я создал ветку секрет SVN, хотя я предпочитаю Bzr или Git).

Итак, я подозреваю, что единственные «защитники блокировки» - это сотрудники отдела маркетинга системы запирания.

Не правда. Я работаю с несколькими из них. Я пытаюсь отключить нашу группу от SourceSafe, но одним большим камнем преткновения является то, что вся группа здесь привязана к модели заблокированных касс. Слияния здесь страшнее, чем талибы.

T.E.D. 26.11.2008 18:32

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

T.E.D. 26.11.2008 18:35

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

hendrixski 24.12.2009 01:53

Я сам очень боялся идеи слияния, имея воспоминания о кошмарах, пытающихся слить код еще в 80-х. Однако я загрузил Subversion и Git, немного поиграл с ними и впечатлен их обещаниями. Жаль, что я здесь единственный.

Я сделал одну вещь, которую вы можете попробовать: следить за собой. Поскольку модель блокировки более пессимистична, это легко сделать, если вы работаете в рамках этой модели. Каждый раз, когда у вас возникает конфликт блокировки с другим разработчиком, подойдите к нему и поговорите с ним. Следите за следующим:

  1. Сколько раз они не хотели проверять / забыли об этом / не знали, что это проверено.
  2. Сколько раз они недоступны (в отпуске, на больничном и т. д.).
  3. Сколько раз они законно проверяли его, но модифицируют совершенно несвязанные части файла на то, что вы хотели изменить.
  4. Сколько раз они изменяли часть файла, которая противоречила бы изменениям, которые вы хотели внести.

4 - единственная ситуация, когда можно утверждать, что блокировка вам помогла, и покрывает каждый такой случай. За последние 3 года я обнаружил, что почти все проблемы относятся к категории 1-3. Я думаю, что нашел 4 однажды. Но если я сложу все проигранное время до 1–3, это потрясающе.

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

Самые большие проблемы слияния, с которыми я когда-либо сталкивался, были на сайте, где у нас был блокируемый контроль версий (SCCS, если быть точным - это было некоторое время назад).

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

Это происходило по-разному. Иногда A возвращался, B вносил изменения, а затем A продолжал работать с рабочей копией A и стирал изменения B. Иногда B начинал работать с скопированной копией, поскольку время имело существенное значение, и изменения могли занять некоторое время, чтобы получить правильные и перезаписать изменения A. Иногда изменения B будут взаимодействовать с изменениями A, и некоторые изменения A будут искажены или потеряны. В последнем случае предупреждения не последовало.

При объединении VCS A и B вносят свои изменения, и система следит за тем, чтобы ничего не потерялось. В последнем случае VCS фиксирует конфликт, поэтому он не будет пропущен.

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

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

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

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

tishma 23.05.2012 19:52

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

Yauheni Sivukha 19.11.2012 04:27

@tishma Большой рефакторинг отлично работает без блокировок, если ваша VCS хорошо поддерживает ветвление и слияние. (Я прошел через рефакторинг нескольких кодовых баз с использованием Git, который не блокируется. Это не было проблемой.)

Marnen Laibow-Koser 13.06.2018 02:31

@ MarnenLaibow-Koser Верно. Дело в том, что слияние независимых изменений кода, подвергшегося серьезному рефакторингу, почти наверняка не окажется тривиальным. В определенной степени Git может помочь, и все зависит от того, насколько две ветки в конечном итоге расходятся друг от друга.

tishma 22.06.2018 13:55

Думаю, это зависит от случая. Вы бы взяли самолет, если бы знали, что файлы, управляющие самолетом, были одновременно изменены многими людьми, а затем объединены?

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

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

Marnen Laibow-Koser 19.01.2018 04:05

Другие вопросы по теме