объединить изменения двух репозиториев с несвязанными историями - PullRequest
0 голосов
/ 11 июня 2018

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

Моя идея состояла в том, чтобы предоставить этот новый репозиторий с текущим состоянием файлов дляновые разработчики, но с пустой историей, попросите их поработать там, а затем объединитесь из (нового) репозитория с моим исходным (основным) репозиторием.

Мне нужно было бы также сделать другой путь, япотребуется объединить изменения из моего (основного) репозитория в (новый).

Моя первая попытка состояла в том, чтобы добавить (новый) репозиторий в качестве удаленного в папку, где находится основной репозиторий, а затем объединитьв (основной) с помощью:

git merge --allow-unrelated-histories evisa_clone/master

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

Какая у меня альтернатива?

1 Ответ

0 голосов
/ 11 июня 2018

Вы хотите принять изменения в хранилище, не передавая другим людям всю историю, но они могут использовать текущее состояние файлов.Это просто делается с помощью отдельного клона, но только клонирование с depth=1

Steps

  • git clone <repo> --depth=1 --branch=<dev or whatever>

  • другие разработчики (TOD) будут работать над этим новым клоном, который не будет иметь более старой истории, но будет иметь действительный идентификатор SHA, который коррелирует с вашим репозиторием.

  • TOD должны отделяться от этого нового хранилища и создавать ветки для всей своей работы.

  • Чтобы продвинуться в своей работе, они, по сути, будут выполнять запросы на вытягивание своих ветвей до глубины = 1 ветвь.

  • Чтобы они могли получать обновления для хранилища, вам необходимо поддерживать оригинальную ветку репозитория глубины = 1 в актуальном состоянии с исходным хранилищем, и они просто продолжат свою работу: извлечение,ветвление, передача, PRing

Альтернатива

  • git clone <repo> --depth=1 --branch=<dev or whatever>
  • Вы рассматриваете этот новый репозиторий как тот, с которым нужно работать.
    • История может быть важна, но если она не нужна, она не нужна.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...