Windows Git 2.20.0 Использование Bash (и Git командной строки Windows) оба одинаковых результата.
Есть ли приемлемый и БЕЗОПАСНЫЙ способ извлечь папку из большого репозитория и переместить ее в собственное РЕПО, сохранив при этом ссылку на большое хранилище для синхронизации с основной базой кода?
GROUP
Company1
Apps
SharedApp
Company2
Apps
Я хочу извлечь SharedApp из собственного репозитория, но, если возможно, сохранить связь с GROUP. так что если кто-то проверяет GROUP, он получает всю партию, но сторонний разработчик может проверить только папку «Приложения».
Я пробовал использовать:
git filter-branch --prune-empty --subdirectory-filter SharedApp
Но это просто возвращает "не нашел ничего переписать"
Я также пробовал:
git subtree -P SharedApp -b newbranch
Но это просто помещает всю структуру, установленную в новую ветку "newbranch", и ничего не фильтрует, как (я думал), как утверждают документы.
Рассматривал использование SubRepos, но я слышал, что они особенно хлопотно в будущем.
Любая помощь очень ценится.
Редактировать: в какой-то момент мне нужно сделать это для МНОГО папки и библиотек и связать их обратно в основной репозиторий. отсюда вопрос.
2 ответа
Я не понимаю вашего акцента на "БЕЗОПАСНО". Вы используете git - все, что вы делаете с клоном, влияет только на этот клон. Пока вы проверяете, что вы сделали локально, прежде чем воздействовать на пульт, вы не сможете ничего потерять. Какой риск вас беспокоит?
Если вы используете filter-branch, у вас не будет простого способа интегрировать будущие изменения между репозиториями. Не то чтобы нет способа сделать это, но это требует прыжков через значительные обручи, потому что результат не связан с оригиналом.
Тем не менее, если вы хотите использовать filter-branch: это может быть сделано по одной причине, если путь указан неверно. Убедитесь, что вы указываете полный путь от корня рабочего дерева, и в зависимости от вашей файловой системы может иметь значение заглавная буква. (В Windows это обычно не имеет значения; Mac или * nix это, вероятно, имеет.) Если существует каталог SharedApp с файлами в нем, зафиксированными непосредственно в корне репо, аргумент фильтра, как указано, должен быть в порядке.
Кроме того, вам, вероятно, нужно добавить аргумент --all (или одно или несколько имен веток), чтобы он знал, что переписать.
git filter-branch --prune-empty --subdirectory-filter SharedApp -- --all
На мой взгляд, подпункты - это самое близкое, что git предлагает к тому, что вы просите. Да, многим они не нравятся; опять же, многие другие люди используют их просто отлично. Вы должны уделить время, чтобы понять, как с ними работать, и не ожидать, что они будут работать иначе, чем они, или не использовать их.
Короче, я отвечаю: НЕТ, не используйте их, они опасны, как я и предполагал.
Просто Google "следует ли мне использовать subrepos в git" "безопасны ли модули git" "конфликт слияния подмодулей git" и т. Д.
Хотя совет состоял в том, что подмодули - это ответ, и что они безопасны, я не согласен; и так делают многие из интернет-блогов от некоторых довольно уважаемых людей.
Подмодули, казалось, работали некоторое время, но при объединении ветвей разработки, где подмодуль стареет, различные трещины начали показывать, что я не могу работать, и это меня беспокоит. У меня 10 и более лет TFS, 3 года SVN и 1 год GIT, так что я вполне способен работать с системами контроля версий. Но за свою жизнь я не мог этого понять и не мог «уверенно» объединить различия, так как несоответствия между ветвями увеличивались со временем - даже после того, как я синхронизировал и заставил оба субмодульных контейнера на всех машинах разработчиков быть тот же самый.
Я не смог найти ничего в GIT docs / blos / article, рекомендовавшего не размещать подмодули внутри репозиториев и ветвлений. Это то, что я и сделал, но при слиянии дочерней ветки функций возникли конфликты слияния в файлах, которые не были затронуты другими сторонами, и, что еще хуже, изменения кода, которые были намного старше, воспринимались как более новые, это действительно беспокоило как вы не можете доверять процессу слияния.
Я заметил, что это поведение было только в ветви подмодуля, фактическая ветка dev слилась просто отлично, независимо от странного поведения подмодуля.
В конце после многих потраченных впустую и мучительных ночей я очень тщательно слил субмодуль обратно в основные ветви и разочаровался в идее.
Если мне нужно GIT хорошо, то я боюсь, что у меня просто нет времени, чтобы присматривать за подмодулями, так что я возвращаюсь к тупому старому мерзавцу для меня.
Похожие вопросы
Новые вопросы
windows
Написание программного обеспечения, специфичного для операционной системы Microsoft Windows: API, поведения и т. д. ОБЩАЯ ПОДДЕРЖКА WINDOWS НЕ ПО ТЕМЕ. Вопросы поддержки можно задать на https://superuser.com