У мене є проект, який покладається на два репозиторії в github для функціонування. Коли я подаю свій проект на github, як мені зв’язати ці два репозиторії? Чи слід дублювати файли у моєму власному репо чи посилатися на інше репо при певній редакції, оскільки я не хочу, щоб воно оновлювалось і спричиняло несумісність. Я вже створив своє репозиторій github, що мені робити?
github-зв'язок з іншими репозиторіями
Відповіді:
Ви можете використовувати підмодулі git для "посилання" на інші проекти. Дивіться тут - http://help.github.com/submodules/
4
Що робити, якщо мій проект не має нічого спільного з початковим репо, від якого я залежаю? Наприклад, я використовую синтаксичний аналізатор XML для свого сценарію, але це не є нічим, щоб зробити внесок у цей проект, чи слід мені все-таки використовувати підмодулі?
—
user391986
@ user391986 Так, мова йде не лише про внесок у інший проект.
—
manojlds
Останнє питання, коли ви оновлюєте файли всередині цього підмодуля, якщо натискаєте зміни, чи оновлює це моє або пов'язане репо?
—
user391986
@ user391986 - Ви сказали, що не додаєте до цього внеску. Якщо натиснути, він (спробує) оновити пов'язане репо.
—
manojlds
GitHub також дозволить вам посилатися на інше сховище в коментарі на GitHub або у коміті. Наприклад:
We should probably handle this with github/enterprise#59
Це додасть оновлення до проблеми github/enterprise#59із посиланням на ваш коментар / коміт.
Посилання на випуски між сховищами
Звичайно, GitHub - це все про соціальне кодування, але ви також можете мати соціальні сховища. Ви можете посилатися на проблеми між репозиторіями, згадуючи номер користувача / репозиторію у випуску. Як тільки ми побачимо щось подібне - скажімо, github / enterprise # 59 - ми обов’язково оновимо випуск No 59 у корпоративному сховищі github і повідомимо вам, звідки на нього посилалися. Це частина GitHub Flavored Markdown , яка також має кілька власних прийомів.
Детальніше: https://github.com/blog/967-github-secrets
Існує альтернатива підмодулям, яку я виявив більш практичною: піддерево .
Згідно з цим посиланням, перевагами є:
- Управління простим робочим процесом є простим.
- Підтримуються старіші версії git (навіть до версії 1.5.2).
- Код підпроекту доступний відразу після завершення клонування суперпроекту.
- subtree не вимагає від користувачів вашого сховища дізнаватися щось нове, вони можуть ігнорувати той факт, що ви використовуєте піддерево для управління залежностями.
- піддерево не додає нових файлів метаданих, таких як підмодулі doe (тобто .gitmodule).
- Зміст модуля можна змінювати, не маючи де-небудь окремого репозиторію копії залежності.