Я использую Dynamics NAV и Git, но не одновременно.Позвольте мне объяснить, почему.
Сам Git классный (с GitHub он становится еще лучше), но порт Windows оставляет желать лучшего, если только вы не любите придерживаться unix-likeкомандной строки, так как это рекомендуемый способ установки msysGit .Инструменты с графическим интерфейсом в Windows, к сожалению, не годятся.
Мне было трудно заставить моего босса понять, почему использование распределенного контроля версий лучше, чем обычный TFS.Для бизнес-ориентированных ребят один большой центральный репозиторий чувствует себя более безопасным (потому что я плачу за свой собственный сервер, я контролирую доступ) и более надежным (я нанял системного администратора, который будет выполнять процедуры обслуживания).
Я решил не бороться с этой волей.Мы используем распределенный контроль версий в качестве промежуточной области.Все нестабильные изменения хранятся в этой области, и мы проводим тестирование в нашей команде.После окончания стабилизации объекты объединяются в центральном хранилище.Все выглядят счастливыми.
Относительно Git: Недавно я переключился на другой распределенный контроль версий - ископаемый по следующим причинам:
- Он может делать все, что может Git;
- Он выглядит, ощущается и действует как родной в Windows;
- Он имеет встроенный веб-интерфейс, и я легко могу запустить его как собственную службу Windows;
- В него встроено отслеживание ошибок, поэтому мне больше не нужны сторонние инструменты;
- Репозиторий представляет собой один файл, поэтому я могу взять его с собой на перьевой диск везде, где захочу;
Относительно нашего решения NAV.Это более 1000 объектов, размер которых превышает 20 МБ.
РЕДАКТИРОВАТЬ: Некоторые обновления после более чем полугодового кодирования.
Мы вернулись к git.Так как его автоматическое слияние - УДИВИТЕЛЬНЫЙ .Просто чтобы выиграть ставку, я перенес решение (модифицированные стандартные объекты и новые) с NAV7CTP3 на NAV7CTP5 за 4 часа.Хотя команда из четырех разработчиков достигла того же результата, требуя почти трех недель ежедневной работы.
Git действительно имеет значение.Я полагаю, что те же результаты возможны с другими распределенными системами контроля версий.
Причина в том, что Git и другие распределенные системы сохраняют намного больше информации во время фиксации, чем, например, TFS и SVN.Это не так важно во время обычной разработки, но когда дело доходит до слияния, вся эта «избыточная» информация из Git имеет значение.
Во время слияния Git находит общую ревизию, которая запустила ветку, а затем применяет измененияиз обеих ветвей шаг за шагом - так же, как разработчик изменил код - для всех файлов в решении.
Если в обеих ветвях была изменена одна и та же строка, это показывает конфликт.Если нет, он просто сохраняет файлы в рабочую папку, готовую к фиксации.
Вот некоторые статистические данные:
- Общее количество файлов, обработанных как в кодовых базах CTP3, так и в CTP3, составляет около четырех тысяч.каждый;
- Общее количество объединенных объектов решения - 1170;
- Общее количество конфликтующих файлов - 140;
- Коэффициент успешного автоматического объединения составляет около 88%.(1170 - 140) / 1170 * 100 = 88%;
- Большинство конфликтов - это изменения в версиях объекта - тривиальные;
- Нетривиальные конфликты в примерно 20 файлах;
- Тривиальный поиск и замена были выполнены для всех объединенных объектов (для исправления RunFormOnRec -> RunPageOnRec и т.1065 * Количество ошибок компиляции после импорта составляет около 50;
- Большинство этих ошибок относятся к изменениям в стандартных объектах с CTP3 на CTP5;
- Частота ошибочных объектов iоколо 4% (50/1170 * 100% = 4%);