Git - Как мне управлять встроенными файлами в разных ветках? - PullRequest
15 голосов
/ 14 мая 2010

Немного фона

Я уже некоторое время пользуюсь Git. Проекты, над которыми я работал, не были слишком сложными в отношении веток / тегов.

Я решил использовать git-svn на работе. Репозиторий SVN имеет много разных веток. Многие из этих веток являются версиями магистрали, настроенными для клиентов.

Проблема

Я часто работаю над проблемами для разных клиентов в разное время. Поэтому я постоянно переключаюсь между ветвями. Проблема в том, что для тестирования продуктов мне приходится перестраивать проект каждый раз, когда я переключаюсь между ветками. Сборка занимает> 2 часа (с нуля): (

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

Это работает, только если файлы сборки отслеживаются (т. Е. Добавляются или фиксируются). Я не хочу отслеживать файлы сборки и определенно не хочу их регистрировать. Есть ли способ сохранить (или сделать что-то подобное) для неотслеживаемых файлов? Или обычная практика, которую люди используют для достижения того же типа вещей?

Обратите внимание, что при сборке нашего проекта каждая библиотека (из которых тысячи) собирает файлы, локальные для папки библиотеки, т.е. они не перемещаются в папку сборки в корне проекта. Все встроенные файлы распределены повсюду.

Обновление ...

Итак, основываясь на некоторых комментариях, я думаю, что мне нужно привести пример моей проблемы

Вот моя структура папок.

branch1/
      src/
         component1/
                    c1.c
         component2/
                    c2.c
      libsrc/
          library1/
                    lib_1.c
          library2/
                    lib_2.c

branch2/
      src/
         component1/
                    c1.c
         component2/
                    c2.c
      libsrc/
          library1/
                    lib_1.c
          library2/
                    lib_2.c

Итак, проблема в том, что branch1 и branch2 имеют одинаковую родословную, но значительно разошлись. Поэтому, если я проверю branch1 и соберу его, я получу двоичные файлы (например, lib_1.o), с которыми я буду ссылаться в моем Makefile для создания окончательных двоичных файлов компонента.

Если я затем извлекаю branch2, внесите изменения в c1.c и запустите make, он попытается связать двоичные файлы, созданные branch1 (lib_1.o), поскольку они все еще существуют в каталогах, как встроенные в предыдущая ветка. Чтобы избежать этого, мне нужно делать чистую сборку каждый раз, когда я переключаю ветки (это занимает часы).

Ответы [ 5 ]

5 голосов
/ 07 июля 2010

Хорошо

Таким образом, этот вопрос остался без ответа некоторое время, и я просто пробовал разные решения локально.

Лучшее, что я придумал, это использовать крючки до и после проверки.

Вот что я сделал

  1. Создайте папку .binaries на верхнем уровне своего хранилища и добавьте ее в файл .gitignore.

  2. Добавьте также форматы двоичных файлов в ваш файл .gitignore.

  3. написать сценарий на вашем любимом языке сценариев, чтобы найти все файлы указанного формата, который перемещает их в папку .binaries/<BRANCH>/ с такой же структурой пути, например, src/library1/lib1.o должно быть ПЕРЕМЕЩЕНО на .binaries/<BRANCH>/src/library1/lib1.o - это должно быть вызвано предварительной проверкой

  4. Напишите скрипт для перемещения файлов из папки .binaries в текущую ветку, например. .binaries/<BRANCH>/src/library1/lib1.o должно быть ПЕРЕМЕЩЕНО на src/library1/lib1.o - это должно быть вызвано после проверки

Теперь переключение между ветвями вернется к двоичным файлам, которые были собраны во время только для этой ветви, и у вас будет чистая проверка при создании новой ветви.

1 голос
/ 14 мая 2010

Возможно, я упускаю что-то очевидное, но при переключении веток Git не будет касаться неотслеживаемых или игнорируемых файлов, поэтому, если вы создаете продукт в одной ветви, а затем переключаетесь на другую, собранные продукты должны остаться.

0 голосов
/ 12 сентября 2017

Думали ли вы о рабочих деревьях?

$ git worktree add ../branch2 branch2

Это создаст извлечение рабочего дерева для ветки2

$ cd ../branch2
$ git branch
* branch2

У вас есть только 1 локальное репо, но 2 разные рабочие зоны, одна для мастера, а другая для филиала 2.

Таким образом, вы также можете хранить объектные файлы отдельно.

0 голосов
/ 22 сентября 2011

Обычно я решаю подобные проблемы, создавая 2 клона репо в 2 отдельные папки (называемые customer_a и customer_b) и извлекая branch1 в одной папке и branch2 в другой папке.

0 голосов
/ 29 мая 2010

Проблема в том, что вам нужно вернуть нужные двоичные файлы:

  • нужна не только для правой ветки,
  • но и для правильной версии

Последний пункт не слишком важен, если вы продолжаете разрабатывать последние версии своих 2 веток (и соглашаетесь восстанавливать все, если извлекаете старый тег и ветку оттуда).
Но все же, если после сборки вы автоматически публикуете эти файлы .o в репозиторий, созданный для управления двоичными файлами, это решит вашу проблему аккуратно.
Например, локальный репозиторий Nexus подойдет.

...