Выделение подпроекта в отдельный репозиторий на github

    Недавно я столкнулся с задачей переноса папки с проектом из одного репозитория в другой на github. Звучит примитивно, но если рассмотреть то, что дано и то, что необходимо получить, могут возникнуть некоторые нюансы.


    Итак, что дано:


    • Есть большой репозиторий, содержащий множество папок. Каждая папка – это отдельный проект.

    Что необходимо сделать:


    • Одну из папок перенести в отдельный репозиторий с сохранением ее истории коммитов.

    В теории можно было бы просто скопировать весь репозиторий со всем содержимым в новое место, а потом просто удалить те папки, которые не нужны. Но такой способ довольно неоптимален и не особо мне понравился, так что я решил поступить иначе.


    Я использовал стандартный гитовый filter-branch. За основу я взял следующие статьи:



    В этом посте я хочу немного адаптировать процесс для лучшего восприятия.


    Предположим для примера, что наш репозиторий называется movement-example, а та единственная папка, которую мы хотим перенести в отдельный репозиторий – folder-to-move. Тогда шаги, которые необходимо выполнить для подготовки переноса, выглядят следующим образом:


    1. git clone git@github.com:<user_or_organization>/movement-example.git
      Лучше сделать новый клон репозитория, даже если он у вас уже скачан. А еще лучше делать клон из локального репозитория: git clone <path-to-movement-example> – это гораздо быстрее (спасибо ZyXI за подсказку).
    2. cd movement-example
    3. git remote rm origin
      Это именно тот момент, ради которого мы делали новый клон – теперь мы не боимся поломать оригинальный репозиторий.
    4. git filter-branch --subdirectory-filter folder-to-move -- --all
      После выполнения этого шага в вашем локальном репозитории останется только контент папки folder-to-move, причем самой папки больше нет – все содержащиеся в ней файлы теперь лежат в текущей директории (в movement_example).
    5. mkdir folder-to-move
      mv * folder-to-move
      Это опциональный шаг – если вы хотите иметь все файлы внутри той же папки, что и раньше, а не в корне нового репозитория.
    6. git add .
    7. git commit -m “Preparing to extract folder”

    Первая часть готова, а вторая заключается в том, чтобы совершить фактический перенос. Предположим, что новый репозиторий называется просто new-repo, тогда необходимые шаги выглядят следующим образом:


    1. git clone git@github.com:<user_or_organization>/new-repo.git
      Клонируем себе новый репозиторий, если, конечно, все еще не сделали этого.
    2. cd new-repo
    3. git remote add old-repo-branch <path-to-movement-example-folder>
      Добавляем новый remote. Если ваши папки new-repo и movement-example лежат на одном уровне в файловой системе, то path-to-movement-example-folder выглядел бы как ../movement-example
    4. git pull old-repo-branch master
      После выполнения этого шага цель будет практически достигнута – у вас уже будет весь контент folder-to-move в локальном репозитории new-repo, останется только сделать push. Но сначала нужно сделать кое-что еще.
    5. git remote rm old-repo-branch
      Вам же больше не нужен второй remote, верно?
    6. git push origin master

    Готово! Теперь в вашем новом репозитории есть только интересующая вас папка вместе со всей историей коммитов. Например, сразу после вышеописанных шагов я увидел следующее в своем новом репозитории:


    810 коммитов!


    Кстати, вы увидите только 1 бранч – master. Процедура переносит только один бранч за раз. Если вы хотите перенести dev, то вам нужно просто сделать git checkout dev и git pull origin dev после второго шага на обоих этапах.


    Если вам нужно перенести все 50 (60? 100?) бранчей, то данное решение не будет удачным из-за слишком большого количества рутинной работы. Но я считаю, что для переноса достаточно лишь сохранить master и dev бранчи, потому что все feature branches уже должны быть в dev, а новые бранчи вы будете ветвить уже в новом репозитории.


    UPDATE

    Спасибо fstep за подсказку. Можно просто воспользоваться другой гитовой утилитой – subtree. Для этого нужно всего ничего:


    1. git clone <path-to-movement-example>
    2. git remote rm origin
      Обратите внимание – эти 2 шага опциональны, вы можете выполнять следующие шаги напрямую из вашего "боевого" локального репозитория. Иметь клон с удаленным origin – мое личное предпочтение, чтобы даже не иметь шанса как-то сломать оригинальный репозиторий.
    3. git subtree split --prefix folder-to-move master
      Или любой другой бранч, кроме master. Эта команда будет долго вычислять значения, но в итоге вернет вам что-то вроде 253f8a5edd9a4dbbb1d72e5837243e93c92ebfcd
    4. git push git@github.com:<user_or_organization>/new-repo.git 253f8a5edd9a4dbbb1d72e5837243e93c92ebfcd:master --force
      Здесь мы пушим с флагом --force, потому что new-repo наверняка будет иметь как минимум readme файл, который вы (вероятно) не захотите пуллить.

    Ну, а если new-repo является совсем свежим и не содержит даже readme файла – другими словами, вообще не содержит файлов, то все еще проще:


    git subtree push --prefix folder-to-move git@github.com:<user_or_organization>/new-repo.git master

    Поделиться публикацией

    Похожие публикации

    Комментарии 23
      0
      Если вам нужно перенести все 50 (60? 100?) бранчей, то данное решение...

      автоматизируется скриптом :)
        +3
        А разве команда
        git subtree push --prefix folder-to-move remote-name branch-name 
        
        не сделает то же самое?
          0
          Попробовал – делает то, что надо, спасибо! Укажу это в посте
            0
            Часто использую эту команду, чтобы задеплоить сборку веба на продакшн.
            Не уверен, подтягивается ли история коммитов?
              0
              Да, подтянулась
          0

          Могу порекомендовать тулзу BFG, она может удалять файлы из истории типа случайно закоммиченных паролей или просто огромных файлов, которые стали не нужны, но занимают место в истории. Она, к сожалению, не умеет выпиливать по правилу "все, кроме", но можно написать простенький скрипт, чтобы из git'а вытащить список всех файлов во всех бранчах, отсортировать, выбрав уникальные, вычеркнуть sed'ом те, которые планируется оставить, а потом скормить результат bfg.

            0

            А зачем в новом репозитории делать git remote add+git remote rm? Git спокойно принимает вместо названия remote значение, на которое это название ссылается.


            К тому же, кажется, вы чего‐то накосячили при клонировании или pull’е: в документации filter-branch ясно сказано, что -- --all переписывает все тёги и ветки, вам нужно просто их все склонировать а потом так же все затянуть в новом репозитории, а не заниматься скриптописательством или рутинной работой.


            И clone в первом шаге лучше делать локального репозитория — это быстрее, а git не будет что‐то в оригинале менять, хотя и воспользуется по возможности жёсткими ссылками. Ещё при желании можно cp -r локальные клоны делать, хотя лучше не надо — притянет мусорные изменения. Но все ветки и тёги, с которыми вы работали будут на месте точно.

              0

              Хотя я вижу: вы точно накосячили при pull и push: тянете только master, явно. Git даёт затянуть всё сразу:


              1. В new-repo делаете git checkout -b xxx-temporary-branch-xxx — вам нужна ветка, которой нет нигде, чтобы git не вопил, что он не может затянуть что‐то в текущую ветку.
              2. git fetch path/to/movement-example '*:*': затягиваете всё, но ничего не переименовывается.
              3. git checkout master: чтобы удалить ветку нужно перейти куда‐то ещё, не важно куда
              4. git branch -D xxx-temporary-branch-xxx
              5. git push origin '*:*': отправляете всё, что затянули при fetch.
                0

                Если не ошибаюсь, то с голыми репозиториями (git clone --bare) 1, 3 и 4 не нужны.

                  0

                  И вообще вы занимаетесь фигнёй: делайте git push 'git@github.com:<user_or_organization>/new-repo.git' '*:*' прямо из movement-example. Новый клон не нужен, создавать remote не нужно, временная ветка не нужна, push’ити всё сразу; потом сделаете себе клон для работы уже с нужными изменениями или сделаете pull с github из имеющегося.

                    0
                    С таким же успехом можно просто через github UI сделать то же самое – полная копия. Мне нужна одна конкретная папка
                      0

                      Какая ещё полная копия?! После filter-branch там уже только нужные коммиты. Или вы думаете, что изменения в ветке master магическим образом изменятся во время pull, из‐за чего мой вариант не эквивалентен использованию промежуточного репозитория?

                        0

                        Хотя одну вещь в моих советах нужно изменить: везде, где одна команда с '*:*' нужно использовать две: 'refs/heads/*:refs/heads/*' и 'refs/tags/*:refs/tags/*'. Иначе получите дополнительно всю оригинальную историю, т.к. filter-branch сохраняет её в refs/original.

                  0
                  Да, спасибо – это оптимальнее будет. Я попробую это все и обновлю пост
                0

                Серьёзно думаю над обратным процессом. Как-то не стрельнула идея в SOA-приложении выделить каждый сервис в отдельный репозиторий, объединив их через submodule.

                  +1
                  Попробуйте такой подход: https://habrahabr.ru/post/326132/#comment_10165486

                  Зависимые сервисы смогут пользоваться маленькими пакетами с кусочками вашего кода, а вы сможете коммитить в монолит.
                    +3

                    Если нужно слить проекты в один монолитный репозиторий, может помочь моя давнишняя статья. Если предварительно потренироваться на кошках фейковых репозиториях или клонах, то всё достаточно просто получается.

                    0
                    Спасибо, нужная вещь. Ну и раз уж пошла тема спрошу свое, может подскажет кто.
                    Не так давно хотелось сделать в репе submodule, но что бы в него затягивался не весь целевой репозиторий, а одна папка, к примеру include из большого С/С++ проекта, пусть только в read-only, но с сохранением возможности обновления как обычный submodule. Возможно ли такое?
                      0
                      Гит в такое не играет, смотрите ниже как можно выкрутиться.
                      +1
                      Git Subsplit

                      # This utility uses `git-subsplit`. If you don't have one, run this:
                      # pusd /tmp/ && git clone git@github.com:dflydev/git-subsplit.git && cd git-subsplit && ./instal.sh && popd
                      #
                      # This utility also uses linux "parallel"
                      # To install a fresh version, run:
                      # Ubuntu:
                      # apt-get -y install bzip2 make && (wget -O - pi.dk/3 || curl pi.dk/3/ || fetch -o - http://pi.dk/3) | bash
                      #
                      # MacOS:
                      # brew install parallel
                      
                      git subsplit init git@github.com:your/big-project.git
                      
                      modules_array=(
                          'your/subfolder/to/split:git@github.com:your/new_microservice.git',
                          'your/another/subfolder/to/split:git@github.com:your/other_microservice.git',
                      )
                      
                      printf '%s\n' "${modules_array[@]}" | parallel "git subsplit publish --heads='master staging development' --no-tags"
                      
                      rm -rf .subsplit/
                      


                      Делаете other_microservice.git проектом с READ-ONLY доступом и можете спокойно коммитить в основной проект, запуская утилиту в CI-процессе автоматически. В --heads можно подставлять текущую ветку с помощью чего-то вроде

                      ```$(git symbolic-ref --short HEAD)```

                      Пример аналогичного подхода: https://github.com/laravel/framework как основной код и https://github.com/illuminate/queue как пакет, автоматически вырезаемый из основного (наряду с другими)
                        0
                        Не раскрыта тема куда девается передвигаемая папка из первоначального репозитория. — Удаляется?
                          0
                          Нет, с ней ничего не происходит – остается на месте :)
                            0

                            А что с ней станет? С клоном же работаете, push в origin не просто не делается — origin вообще удалён на третьем шаге.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое