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

Немного фона

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

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

Проблема

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

Я предполагаю, что есть способ зашифровать файлы сборки в ветке customer_a, а затем проверить customer_b, изменить, построить, протестировать, зафиксировать. Затем снова запустите файлы сборки и checkout customer_a и введите stash 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 и запустите, чтобы попытаться связать их с бинарниками, созданными с помощью branch1 (lib_1.o), поскольку они все еще существуют в каталогах, встроенных в предыдущей ветки. Чтобы этого избежать, я должен делать чистую сборку каждый раз, когда я переключаю ветки (что занимает несколько часов).

Ответ 1

Хорошо

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

Самый лучший, с которым я столкнулся, - использовать pre-amd post checkoout hooks.

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

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

Задумывались ли вы о рабочих вагонах?

$ git worktree add ../branch2 branch2

Это создаст контрольную таблицу рабочего дерева в branch2

$ cd ../branch2
$ git branch
* branch2

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

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