Почему git лучше, чем subversion?

И, кстати, Subversion все еще отстой…

В централизованной системе, такой как Subversion, виртуальные каталоги отстой. Зачем? Потому что у всех есть доступ, чтобы просмотреть их … даже мусорные экспериментальные. Ветвление хорошо, если вы хотите экспериментировать , но вы не хотите видеть эксперименты со всеми и их тетями . Это серьезный когнитивный шум. Чем больше веток вы добавите, тем больше дерьма вы увидите.

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

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

SVN (Apache Subversion)

SVN довольно проста в использовании. Если вы используете WordPress, это плагин вы будете, вероятно, использовать. Ваше хранилище поставляется в виде центрального сервера с трех основополагающих областях: туловище, ветви и теги.

магистральные

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

ветви

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

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

Теги

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

Метки, как правило, используется, когда код готов к развертыванию. После того, как она была завершена, и объединены в багажник, испытано, то оно будет испытываться — то вы бы помечать багажник. Как раз перед выпуском. Затем вы отпустите развитие на вашем рабочем сервере. Если выпуск не работает должным образом, вы можете пометить этот тег как неработающую и вернуться к предыдущей метке, чтобы решить эту проблему.

Работа с файлами в SVN

В служебный каталог .svn рабочей копии для каждого файла SVN записывает свойства.

Свойства файла:

• Рабочая ревизия файла — номер ревизии, на которой основан файл в рабочей копии.
• Дата и время последнего обновления локальной копии файла из хранилища.

Назначение свойств — определить состояние файла рабочей копии.

Состояния файла рабочей копии:

• Не изменялся и не устарел.

  В хранилище не фиксировались изменения файла со времени его рабочей ревизии. При попытке его обновить или зафиксировать не будет выполнено никаких действий.

• Изменен локально и не устарел.

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

• Не изменялся и устарел.

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

• Изменен локально и устарел.

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

Использование систем контроля версий Получение справочной информации Subversion (SVN)

Справочная информация по командам svn может быть получена обращением к самой утилите svn через команду svn help. Введя эту команду в консоли, вы получите полный список всех команд поддерживаемых текущей версией утилиты svn. Для получения информации по конкретной команде надо добавить ее после help. Например:

Subversion (SVN)

Продумаем размещение и выберем имя для директории будущего репозитория SVN. При этом подумайте о правах доступа, если репозиторий будет разделяемый. Для простоты я
сделаю репозиторий в своем домашнем каталоге /home/knz с именем 0-svn-repository. Имя начинающееся с нуля предоставит дополнительный приоритет для данной директории для
многих типов сортировок при выводе списка директорий и такая директория не затеряется в окружении многих других директорий домашнего каталога.

Находясь в домашней директории выполним команду.

svnadmin create 0-svn-repository

Репозиторий создан. Пустой репозиторий имеет нулевой номер ревизии. Теперь в него можно добавлять проекты для управления. Дальнейшая последовательность действий может быть такая.

1. Создадим где-нибудь начальный оригинал будущего проекта.
2. Выполним импорт этого оригинала проекта в репозиторий SVN с помощью команды svn import.
3. Оригинал проекта теперь стратегического смысла не имеет и его можно удалить.
4. Создаем рабочую копию проекта из репозитория SVN с помощью команды svn checkout.
5. Работаем с рабочей копией, вносим в нее изменения. Чтобы зафиксировать изменения необходимо передать их в репозиторий SVN с помощью команды svn commit. При
   этом, в репозитории проекта, будет создана очередная по счету ревизия.

Игнорирование файлов SVN
Сделать файл list с именами или масками, разделённые переводом строки
$ svn propset ‘svn:ignore’ -F list

Преобразование исходного SVN-репозитория в локальный репозиторий Git

Цель этого шага — преобразовать источник репозитория Subversion в локальный репозиторий исходного кода Git. Репозиторий исходного Git не имеет локального рабочего извлечения файлов, которые можно изменить, вместо этого он содержит только журнал репозитория и метаданные самого репозитория. Это рекомендуемый формат для предоставления общего доступа к репозиторию Git через удаленный репозиторий, размещенный в службе, например Azure Repos.

Совет

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

Получение списка всех авторов Subversion

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

Пользователи Subversion

Пользователи Git

Чтобы извлечь список всех пользователей SVN из корневого каталога извлечения локальных версий, выполните следующую команду PowerShell:

Эта команда извлекает все сообщения журнала, извлекают имена пользователей, исключает все дублирующиеся имена пользователей, сортирует имена пользователей и помещает их в файл «authors-transform.txt». Затем можно отредактировать каждую строку в файле, чтобы создать сопоставление пользователей SVN с хорошо отформатированным пользователем Git. Например, можно выполнить соотнесение к .

Примечание

Кодировку можно изменить, добавив параметр -Encoding в приведенную выше команду, например .

Клонирование репозитория Subversion с помощью git-svn

Следующая команда выполняет стандартное преобразование git-svn с помощью файла authors-transform.txt, созданного на предыдущем шаге. Репозиторий Git будет размещен в папке на локальном компьютере.

Примечание

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

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

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

Примечание

Эта команда может занять от нескольких минут до нескольких часов в зависимости от размера репозитория SVN. После завершения вы получите извлечение репозитория из Git.

Преобразование конфигураций, относящихся к системе управления версиями

Если репозиторий SVN использует свойства svn: ignore, можно преобразовать в gitignore -файл с помощью:

Совет

Дополнительные сведения о . gitignore: Игнорировать изменения файлов с помощью Git

Принудительная отправка репозитория в репозиторий исходного Git

На этом шаге вы создадите исходное репозиторий и сделаете его ветвь по умолчанию, совпадающее с именем магистральной ветви SVN.

1. Создание исходного репозитория Git

2. Отправка локального репозитория Git в новый репозиторий исходного Git

3. Переименуйте ветвь «магистраль» на «Master». основная ветвь разработки будет называться «магистральной», что соответствует имени, которое было в подсистеме. Его нужно переименовать в стандартную главную ветвь Git с помощью:

4. Очистка ветвей и тегов git-svn делает все теги Subversion в очень короткие ветви в Git в формате «Tags/имя». Все эти ветви необходимо преобразовать в фактические Теги Git или удалить.

Так как насчет того, чтобы показать мне пример с вещественным слиянием?

Следует признать, что приведенный выше пример очень прост, поэтому давайте сделаем гораздо более скрученный, хотя и более распространенный пример. Помните, что начинался с трех ревизий? Ну, парень, который их сделал, давайте назовем его Боб , работал сам и сделал коммит в своем собственном репозитории:

Теперь Боб не может отправить свои изменения непосредственно в репозиторий . Система обнаруживает это, проверяя, происходит ли ревизия Боба непосредственно от , что в данном случае не происходит. Любая попытка Push приведет к тому, что система скажет что-то похожее на » э-э … боюсь, я не могу позволить вам сделать это, Боб «.

Таким образом, Боб должен вставить и затем объединить изменения (с git ; или hg’s и ; или bzr ). Это двухступенчатый процесс. Сначала Боб должен получить новые ревизии, которые будут копировать их из репозитория . Теперь мы можем видеть, что график расходится:

Второй шаг процесса извлечения — объединить расходящиеся подсказки и зафиксировать результат:

Надеемся, что слияние не приведет к конфликтам (если вы предвидите их, вы можете выполнить два шага вручную в git с помощью и ). Что нужно сделать позже, это снова вставить эти изменения в , что приведет к ускоренному слиянию, поскольку коммит слияния является прямым потомком последнего из репозитория :

Есть еще одна опция для слияния в git и hg, называемая rebase , которая будет перемещать изменения Боба после последних изменений. Поскольку я не хочу, чтобы этот ответ был более подробным, я позволю вам прочитать git , или документы об этом вместо ,.

В качестве упражнения для читателя попробуйте нарисовать, как это будет работать с другим пользователем. Это делается так же, как в примере выше с Бобом. Объединение между репозиториями проще, чем вы думаете, потому что все ревизии/коммиты однозначно идентифицируются.

Существует также проблема отправки патчей между каждым разработчиком, что было огромной проблемой в Subversion, которая смягчается в git, hg и bzr уникальными идентифицируемыми ревизиями. После того, как кто-то слил свои изменения (т.е. сделал коммит слияния) и отправил его всем остальным в команде для использования путем отправки в центральный репозиторий или отправки исправлений, ему не нужно беспокоиться о слиянии, потому что это уже произошло , Мартин Фаулер называет этот способ работы неразборчивая интеграция .

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

Несколько ветвей

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

• Отключить релизы. Когда вы выпускаете новую версию своего проекта более широкой публике, вы хотели бы пометить (отметить) выпущенную версию. Таким образом, когда кто-то скажет вам, что версия X.Y вашего проекта имеет ошибку, вы сможете проверить эту версию и проверить, можете ли вы воспроизвести эту ошибку (и, возможно, найти ошибку через bisection, см. Выше). Это может быть полезно, даже если вы не выпускаете свой проект, если используете разные версии, развернутые в разных местах.

  

  

  

  

  

  

  

  

  

  

  Для этого теги должны быть неизменными (конечно).

• Долгоживущие ветки, Предположим, что вы выпустили свой проект, а кто-то нашел ошибку. Вы, вероятно, захотите быть ebale, чтобы поставить (освободить) исправленную версию, не останавливая работу над новыми функциями, и не отправляя версию от разработки, которая может быть нестабильной и содержать несколько других ошибок. Также вы хотите, чтобы исправление было также в версии, над которой вы работаете (если она не была установлена ​​независимо).

  Для этого вы будете использовать долгоживущие ветки: ветвь обслуживание, в которой вы будете использовать только исправления и ветвь разработка (или trunk). где вы будете делать новую работу, внедрять новые функции и т.д. Может быть больше ветвей с изменяющейся стабильностью. Например, проект Git имеет четыре таких ветки: “maint” для исправлений, “мастер” для изменений, которые достаточно стабильны; “next; для работ по развитию, а также для ветки” pu “или” предлагаемых обновлений”. В других рабочих процессах у вас есть отдельная ветвь обслуживания (исправления ошибок) для каждой версии.

  Процитировать Joel Spolsky: “Сохранение стабильного и dev-кода в отдельности – это именно то, что позволяет вам контролировать исходный код”.

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

  Этот рабочий процесс особенно важен, если вы работаете с несколькими разработчиками, см. ниже.

Справочные сведения

• Выбор правильного контроля версий для проекта
• Сведения о Git
• Игнорировать изменения файлов с помощью Git
• Переход с TFVC на Git

(c) корпорация Майкрософт (Microsoft Corporation), 2017. Все права защищены. Этот документ предоставляется «как есть». Сведения и представления, представленные в этом документе, включая URL-адреса и другие ссылки на веб-сайты, могут измениться без предварительного уведомления. Вы принимаете на себя весь риск, связанный с его использованием.

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

Git — это инструмент совместного создания кода

Часто бывает так: разработчики отделяются от master-ветки и работают над частью проекта самостоятельно — например, чтобы протестировать дополнительные функции. Но не могут продолжить, пока кто-то из команды не допишет код.

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

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

Одиночный разработчик, единственная ветвь

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

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

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

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

• Аннотировать файл/просмотр истории. Если у вас нет идеальной памяти, иногда вам нужно знать, почему (и когда, и в случае, когда есть несколько разработчиков, и кто), вы написали заданный набор строк. Комментарии не всегда достаточно. Для этого вы можете использовать (если ваша система управления версиями предоставляет) линейные аннотации истории файлов ( или ) или другие аналогичные инструменты, такие как так называемый поиск “pickaxe” в Git, где вы выполняете поиск/просмотреть историю для коммитов, которые ввели или удалили заданную строку.

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

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

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

Сколько GIT работ

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

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

Git Индивидуальные Хранилища

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

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

На шаге 1, вы можете работать в основном как вы бы с SVN: создание филиалов и теги, используя клонированный мастера, как ствол. Разработчики предпочитают Git, потому что каждый из них имеет свой собственный репозиторий для работы, и нет необходимости совершать какие-либо код, пока они не проверили его полностью в их клоном.

Еще одно преимущество, что многие Git нравится то, что у них есть нет необходимости быть подключены в Интернете. Они могут хранить клон главного репозитория на своем компьютере и работать оттуда. Поэтому они могут работать над проектами без необходимости искать подключения или беспроводной точки доступа.

Общего и частного пользования Хранилища

Git позволяет получать государственные и частные местные репозиториев. Другие разработчики могут вытянуть изменения из ваших локальных хранилищ; следовательно, потребность в частном хранилище, чтобы предотвратить это происходит. Вы также можете нажать изменения из вашего публичного хранилища через SSH. Это в значительной степени из-за способности Git, чтобы вы могли использовать клонированы и локальных репозиториев, что многие разработчики предпочитают его SVN.

Разветвление Repo: когда использовать его

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

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

Чтобы создать вилку, сначала найдите хранилище быть раздвоенной. Для этого вы можете использовать поиск » объекта в строке меню Bitbucket. Перейдите в хранилище, а затем нажмите кнопку «Вилка». После этого вы увидите опции вилка, которые вы должны определить. Они включают в себя такие параметры, как владелец, описание, права доступа и т.д.

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

git fetch upstream
git merge upstream/master

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

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

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

Модели версионирования

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

Типы моделей версионирования:

• Модель «Блокирование-Изменение-Разблокирование».
• Модель «Копирование-Изменение-Слияние».

Модель «Блокирование-Изменение-Разблокирование»

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

Особенности модели:

• Блокирование может вызвать проблемы администрирования.

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

• Блокирование может вызвать излишнюю пошаговость.

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

• Блокирование может вызвать ложное чувство безопасности.

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

Эту модель необходимо использовать, если выполняется работа над файлами, не поддающимися слиянию. Например, если хранилище содержит изображения, и пользователи изменяют их в одно и то же время, то нет возможности выполнить слияние эти изменения.

Модель «Копирование-Изменение-Слияние»

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

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

Чтобы разрешить конфликт необходимо:

1. Обсудить изменения, которые вызвали конфликт, с пользователем, выполняющим предыдущую фиксацию файлов.
2. Вручную выбрать, какие изменения из набора конфликтующих изменений необходимо зафиксировать.
3. Зафиксировать в хранилище объединенный файл.

Решающим фактором при использовании этой модели является взаимодействие между пользователями.