Правильно, поэтому мне поручено выяснить, будет ли GIT решением для предстоящей проблемы, с которой мы сталкиваемся. (Легко создавать ветви функций, ветви исправлений, ветви исправления ошибок, сохраняя чистоту соединительной линии и выполняя только завершенные проблемы (функция, исправление, исправление и т. Д.). Так что, как только релиз должен быть выполнен, не будут выпущены частично завершенные/исправленные проблемы .Перенос из SVN в GIT, слияние изменений рабочего процесса с SVN на GIT с совместно используемыми репозиториями
Раньше мы использовали SVN с модифицированной версией модели git-flow/branching, представленной здесь: http://nvie.com/img/[email protected] Где 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
Я немного читал о «подмодулях», однако то, что я смог заключить из всей информации о них, это то, что они являются аналогами 'svn: externals', которые мы использовали раньше, и хотели избавиться от плохого , По той простой причине, что мы хотим, чтобы каждый «супер» проект имел свою собственную копию библиотек, которые могут быть изменены без прерывания других «супер» проектов. Если это не так, я буду смотреть на подмодули еще немного. –
В этом случае вы должны просто проверить источник библиотек в том же репозитории git, что и проекты, которые их используют. Тем не менее это приводит к тому, что изменения в этих библиотеках возвращаются вверх по течению. Обратите внимание, что суперпроект может использовать ветвь библиотеки в качестве подмодуля; вы могли бы, чтобы каждый из ваших проектов указывал на другую ветвь библиотеки. – db48x
«мы хотим, чтобы каждый« супер »проект имел свою собственную копию библиотек, которые могут быть изменены без прерывания других« супер »проектов». Именно это и есть подмодули. Это локальные хранилища. Глобального состояния нет, есть только то, что отправляется. Вы можете поддерживать в них частные филиалы, это очень распространено. – jthill