GIT - клонирование в непустом каталоге с проверкой конфликтов слияния

Question

У меня есть каталог на сервере Debian.Я создал репозиторий git, в который я хотел бы клонировать. Это репозиторий git является чистой версией этого каталога, в которую не входят все ненужные файлы для хранения в моем репо.

Итак, я хотел бы клонировать файлы в этот каталог, НО я не хочу стирать файлы совместно без своего рода «конфликта слияния», если это необходимо.

Я видел это решение на этом посте :

git init
git remote add origin PATH/TO/REPO
git fetch
git reset origin/master  # this is required if files in the non-empty directory are in the repo
git checkout -t origin/master

Но я спрашиваю, будет ли это просто заменить существующие файлы (на сервере) версиейиз этих файлов из моего репо?Или это покажет мне, если есть конфликты?

Спасибо!

Answer 1

Эта процедура частично, но не полностью, подходит для вашего варианта использования.Рассмотрим следующий подход:

# ... in the local directory
git init

Вы упоминаете, что в вашем локальном хранилище есть файлы, которые не должны находиться в репо, и, вероятно, еще нет в репо.Поэтому создайте файл .gitignore, в котором перечислены эти файлы.Тогда

git add .
git commit

Теперь у вас есть локальный коммит с текущим состоянием рабочего дерева.

A <--(master)

Затем

git remote add origin URL/OF/REMOTE/REPO

(Обратите внимание, что URL / OF / REMOTE /REPO может быть PATH / TO / REPO, если REPO находится в локальной файловой системе, но даже тогда я обычно использую file:// URL.)

git fetch

Теперь у вас есть доступ к истории репо.Возможно, это выглядит как

x -- x -- x -- O <--(origin/master)

A <--(master)

Следующим шагом является объединение изменений с пульта.

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

Для файлов только в вашей локальной копии ... ну, вы помещаете их в .gitignore, поэтому они должны оставаться неотслеживаемыми.

Для файлов только в копии репо они будут добавлены в результат объединения.

Для файлов, идентичных в обоих местах, объединение будет выполнено автоматически.разрешить.

Во всем остальном вы получите стандартный конфликт слияния.

После того, как вы разрешите конфликты, у вас должно быть рабочее состояние дерева, подобное тому, что вы хотите.Чтобы у нас была четкая картина, давайте посмотрим, что произойдет, если вы завершите слияние.

git add .
git commit

Теперь у вас есть

x -- x -- x -- O <--(origin/master)
                \
            A -- M <--(master)

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

git reset --soft origin/master

Ваше локальное изменение все еще будет в индексе и рабочем дереве, но график фиксации теперь будет выглядеть как

x -- x -- x -- O <--(origin/master)(master)

A -- M 

Так что теперь вы можете перезапуститьвозьмут на.A и M будут в конечном итоге отброшены из вашего локального репо из-за gc и никогда не станут частью удаленной истории;но после повторной фиксации вы добавляете изменения на удаленный компьютер, чтобы синхронизировать его с вашим локальным каталогом (кроме игнорируемых файлов).