На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
  
> SVN vs GIT и merge
    Наша организация использует очень давно SVN, но на одном из проектов очень большие проблемы с merge.
    Параллельно работает несколько разработчиков, которые комитят за раз изменения в 3-5 файлах сразу в 20-30 местах (файлы создаются автоматически, поэтому иногда куски кода меняют свое место).

    Часть команды говорит что GIT лучше мержит, но доводов они предоставить не могут. Очень интересует разница SVN vs GIT для процедуры мерджа, есть ли разница.

    Проблемных мест сейчас 2:
    1. мердж разных веток;
    2. конфликты, когда 2 разработчика комитят одновременно изменения в одном файле (это бывает редко).
      1. Мердж в SVN действительно не очень удобный. Может его и можно научиться делать, но такое ощущение, что те кто SVN сделал, как-то над этим особо не задумывались. Git, по словам Торвальдса, изначально ориентировался на удобство мерджей.
      2. Конфликты обычно разрешаются автоматически, но всё равно приходится проверять правильно ли файлы смержились.

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

      Среди бонусов Git - возможность коммитить изменения даже при отсутствии связи с сервером. Разработчик имеет собственную копию репозитория.
      Так ли уж важно уметь коммитить генерируемые программно файлы? Я лично вообще бы их из системы контроля версий исключил, при изменении исходных файлов генерил бы заново.
        Цитата amk @
        Так ли уж важно уметь коммитить генерируемые программно файлы?

        Это конфигурация нашей системы, которая сохраняется из базы данных. Из СВН разработчики, переносят эту конфигурацию себе локально, поэтому данные файлы обязательно должны быть в системе. Обмен конфигурациями в обе стороны, так как разработчик тоже может локально изменить конфигурацию и перенести ее в файлы проекта.
          Я к тому, что в большинстве случаев такой генерируемый файл проще сгенерировать самому, чем разбираться то ли что нужно взято репозитория.
          В любом случае какая бы система не использовалась, со слиянием таких файлов будут серьёзные проблемы.

          Поэтому в том же Git рекомендуется коммиты (в локальную ветку) редактируемых вручную файлов делать не один раз в конце дня, а после каждого законченного изменения (например, решил поменять имя переменной на более соответствующее её назначению, поменял его по всему проекту, возможно в точке объявления подправил описание, сделал коммит). Так проще эти изменения объединять. А вот ветки сливаются, когда полностью сделан кусок работы.
            Цитата amk @
            1. Мердж в SVN действительно не очень удобный. Может его и можно научиться делать, но такое ощущение, что те кто SVN сделал, как-то над этим особо не задумывались. Git, по словам Торвальдса, изначально ориентировался на удобство мерджей.

            Есть какие-то явные отличия Мерджа между этими системами? А еще лучше перечень различий.
              Главным для меня было, что в SVN я их так и не научился делать. Просто в подсказке так и не нашёл, как это делать.
              В Git и ветви и мержи делаются сами собой. Начинаешь вносить изменения в файле - для этих изменений автоматом создаётся неименованная ветка. Делаешь PULL, ветка автоматом мержится с основной ветвью. Специально ветки, с заданием им имени, делать приходится редко
                  Веточность один из плюсов таких как гит и т.п. Мерж несравнимо лучше SVN-а, гораздо меньше конфликтов.
                  Удобно для быстрого создания и удаления веток. Можно держать кучу веток и не потеряться. Отдельная фича - отдельная ветвь.
                  0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                  0 пользователей:


                  Рейтинг@Mail.ru
                  [ Script execution time: 0,0227 ]   [ 16 queries used ]   [ Generated: 19.04.24, 19:38 GMT ]