Перенос из SVN в GIT, слияние изменений рабочего процесса с SVN на GIT с совместно используемыми репозиториями

Question

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

Раньше мы использовали SVN с модифицированной версией модели git-flow/branching, представленной здесь: http://nvie.com/img/git-model@2x.png Где git-master - наш svn-trunk. Это работает-ish, но немного громоздко с SVN . Тем более, что мы используем два общих репозитории.

и здесь возникает проблема. Раньше мы использовали эти два общих репозитории как внешнеположенности, и все внешние ссылки были направлены на lib/a/branches/develop и lib/b/branches/develop. Это было громоздким для работы Wi го, если понадобилась функция/исправление/bugfix branche, потому что потребовалось создать три ветви, изменив суперпроект новыми ссылками и затем совершив указанные изменения.

После некоторого тщательного возижения мы переключились на использование ветвей библиотечных репозиториев. (так, superProject/lib/a является филиалом от lib/a/branches/develop), и будущие обновления (в обоих направлениях) потребуют слияния либо от superProject/lib/a до lib/a/branches/develop, либо наоборот.

Это, однако, все еще не решило нашу проблему полузавершенных коммитов после того, как релиз будет близок. (И, к сожалению, в компании, где я работаю, это может понадобиться через час). Таким образом, мы подумали немного больше и согласились начать использовать инструменты, предоставленные Atlassian немного больше, таким образом пробуя Bitbucket (ранее использующий Crucible/FishEye) и используя их специальный интегрированный рабочий процесс для git, где для каждой проблемы ветка может быть созданный и после завершения запроса на растяжение, может быть создан, чтобы наш менеджер выпуска контролировал, что происходит и что не входит в следующую версию. В /develop/ больше нет проблем с выпуском, поскольку все проблемы будут выполняться с использованием указанного рабочего процесса.

Проблема, с которой я столкнулась, заключается в том, как включить эти общие проекты (библиотеки a и b). Я читал в Интернете и обнаружил, что несколько сайтов говорят о git-подмодулях, git-subtree-merging-strategy, git-поддереве (скрипте) и ручном слиянии (это то же самое, что и сложение поддерева?). Но никто не отвечает на некоторые из моих вопросов, связанных с git-newbie. До сих пор я больше всего заинтригован git-поддеревом, но поддержка GUI кажется ужасной. Ни TortoiseGit, ни SourceTree не имеют хорошей поддержки GUI для git-поддерева, что потребует действий в командной строке и, зная большинства коллег, они не любят делать вещи в командной строке.

Что также беспокоит меня в том, что нет ничего хорошего, что я могу найти информацию о из которой хранилище/филиал был создан ГИТ-поддерево и тот факт, что клон из удаленного хранилища мерзавца делает не автоматически включить правильные удаленные ссылки для любого git-поддерева. Таким образом, если я wan't какой-либо из моих коллег-разработчиков, чтобы иметь возможность обновлять ГИТ-поддерево из их удаленного происхождения они должны вручную сделать git remote add -f libraryXXX http://repohere/lib-xxx.git (один раз), а затем сделать git subtree pull --prefix locationGoesHere libraryXXX master (--squash optional)

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

Некоторые ресурсы, которые я использовал:

• https://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/
• https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt
• https://developer.atlassian.com/blog/2015/05/the-power-of-git-subtree/?continue=https%3A%2F%2Fdeveloper.atlassian.com%2Fblog%2F2015%2F05%2Fthe-power-of-git-subtree&application=dac
• https://medium.com/@porteneuve/mastering-git-subtrees-943d29a798ec
• Git subtree -- sharing subtrees with contributors

Answer 1

Это Диффи культ, чтобы сделать много заявлений о вашей настройке, даже с подробным описанием, которое вы указали. Однако я могу сказать, что вы обнаружите, что ветвление в git будет практически безболезненным (особенно по сравнению с svn). Я рекомендую использовать подмодули для ваших зависимостей в библиотеке. Они не идеальны, но они работают. Когда вы создаете ветвь, эта ветка начнет работать с той же версией библиотек, что и ее родительская, и вы можете редактировать файл .gitmodules, чтобы использовать разные. Вам нужно помнить о создании нового клона с флагом --recursive (или использовать git submodule update после клонирования), но это намного проще, чем для поддеревьев.