вытащить удаленного репо и толкая эти файлы

Question

Мы работаем над большим проектом здесь и работаем с функцией «связки» ( РЕДАКТИРОВАТЬ : «связка» - это просто термин, который мы внутренне используем для обозначения определенного пакета функций, а не подразумевается как термин git), распространяемый в нескольких различных репозиториях git. Я готовлюсь отправить пакет изменений в апстрим для проверки и тестирования, но столкнулся с трудностью, пытаясь заставить все хорошо играть вместе.

То, что я сделал до сих пор, - это clone из репозитория, содержащего пакет кода, в мой основной проект, который работает, поскольку получает файлы, куда им нужно идти. Однако, когда я перехожу к add/commit и push, файлы из репозитория "bundle" не идут вместе с ним, предположительно потому, что они являются частью другого репозитория git, чем тот, из которого я отправляю.

Это не совсем приемлемый вариант - просить всех других разработчиков в команде вставлять мой «пакет» каждый раз, когда он меняется (тем более, что он все еще находится в начале цикла разработки и видит много ревизий и рефакторинга), и я не хочу копировать файлы вручную каждый раз, когда мне нужно отправить их. Желательно, чтобы я мог настроить все так, чтобы я мог вытащить свое «связанное» репо в основное репо, а затем сдвинуть изменения в целом.

Есть ли способ сделать то, что я ищу, с помощью git?

Answer 1

Да, вы можете сделать это с помощью разветвления.

Вот несколько уроков о том, как разветвлять репозиторий и выполнять основные действия, которые вам нужны: http://help.github.com/fork-a-repo/ (справка GitHub)

А здесь вы можете найти кое-что еще о удаленных устройствах (эта функцияиспользуется для работы с вилками): http://help.github.com/remotes/

Answer 2

Я не получаю четкого представления о том, что вы хотите (использование словосочетания здесь кажется нестандартным?); Однако

1. man git-remote может быть то, что вам нужно
2. git push --mirror (возможно, начиная с git clone --mirror
3. Если вы хотите инвертировать (отслеживать все удаленные ветви в локальном репо), посмотрите мои недавние добавления здесь: "fetch --all" в репозитории git bare не синхронизирует локальные ветви с удаленными

Answer 3

Ваше описание все еще не совсем понятно для меня, но, похоже, вам может понадобиться использовать подмодуль , объединение поддеревьев или git subtree (сторонний инструмент).

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

---

Подмодули - это стандартный способ публикации ссылки из одного репозитория в другой (с использованием специальных записей дерева «gitlink» и данных в файле .gitmodules). Использование субмодулей позволяет другим пользователям восстанавливать настройки репозитория внутри репозитория, которые (похоже на) вы создали локально во время разработки.
Использование подмодулей потребует некоторых изменений рабочего процесса для любых других людей, которым необходим доступ к ним (например, git submodule update (с --init в первый раз), чтобы убедиться, что у них есть правильная фиксация субрепозиторного коммита после обновления (например, извлечение) «Основной» репозиторий).

A объединение поддеревьев - это способ прямого включения содержимого из несвязанного коммита (например, из хранилища библиотеки) в поддерево (подкаталог) вашего основного проекта. Только пользователи, которым нужно загружать (или выгружать) обновления контента в поддереве, на самом деле должны делать что-то иначе (например, они могут использовать git merge -s subtree для объединения обновлений в историю источника). Некоторым людям не нравятся слияния поддеревьев, поскольку они включают («загрязняет») историю основного проекта с копией истории поддерева.

Инструмент git subtree (сторонний инструмент) может помочь управлять обычными объединениями поддеревьев. Например, подкоманда git subtree split может принимать коммиты, сделанные поверх истории основного репозитория, и переписывать их так, чтобы они отображались поверх оригинальной истории поддерева. Это позволяет легко вносить «локальные» изменения в содержимое поддерева, а затем выдвигать их «вверх по течению». Он также имеет режим --squash, который дает большую часть преимуществ обычного слияния поддеревьев, предотвращая при этом «загрязнение» истории.
У автора git subtree есть , связанный с учебником , который кажется довольно полезным.