GIT: Как синхронизировать существующую удаленную ветку с существующим локальным каталогом

#git #version-control

#git #контроль версий

Вопрос:

Итак, у меня есть локальный каталог, очень упрощенный пример:

 repo/
  foo/
    bar.txt (newer version)
    somefile.txt
    ...
    anotherfile.txt
 

Также у меня есть удаленный репозиторий, например

 repo/
  foo/
    bar.txt (older version)
    importantfile.txt
    
 

Эти папки никогда не синхронизировались.

Я хочу синхронизировать файлы, которые уже существовали только в удаленном репозитории (bar.txt amp; importantfile.txt в примере выше).
Итак, проблема в том, что если я это сделаю

 git init
git git remote add origin [url]
git fetch origin
git add .
 

затем git add для фиксации всех локальных файлов, но я хочу отслеживать файлы, которые уже существовали на удаленном.

Уже пытался найти какое-либо решение в других потоках, но безуспешно.

Пожалуйста, помогите. P.S. я новичок в git.

Комментарии:

1. » отслеживание файлов, которые уже существовали на удаленном » git fetch , делает это автоматически. Что еще вам нужно?

2. @phd после git fetch того, как локальная папка foo остается «неотслеживаемой»

Ответ №1:

Хорошо, я думаю, вы уже на правильном пути. Вот как, я думаю, это должно работать.

Рекомендация: Сделайте резервную копию, прежде чем пытаться это сделать!

Вы начинаете с каталога, в котором находятся все ваши файлы. Это хорошая идея — «очистить» каталог (чтобы в нем не было файлов, которые вас не интересуют); но это не обязательно на 100%.

Затем:

 git init .
git add .
git commit -m "my files"
git remote add rmt <URL to remote repository>
git fetch rmt
git branch -r    // look at the remote branches
git merge -Xours --allow-unrelated-histories  rmt/master
 

Вот краткое объяснение того, что это делает.

  • Первые три команды (вплоть до включения git commit ): Поместите все ваши локальные файлы в ваш собственный локальный репозиторий git
  • следующие две команды (вплоть до включения git fetch ): сообщите git, где находится ваш удаленный репозиторий, и извлеките содержимое; в этом примере я называю это «rmt»; вы можете выбрать здесь любое имя. Просто моя рекомендация: НЕ называйте его «origin»; потому что это имя обычно зарезервировано для репозитория, из которого вы клонировали свой собственный локальный репозиторий. Но это не то, что вы здесь делаете.
  • git branch -r Это делается для того, чтобы получить представление о том, какие ветки доступны в удаленном репозитории под названием «rmt». В следующей строке я просто предполагаю, что вас интересует ветка «master» в удаленном репозитории
  • git merge Теперь начинается волшебство 🙂

Важной частью здесь являются варианты merge :

  • -Xours сообщает git, чтобы он не перезаписывал ни один из ваших файлов файлами из удаленного репозитория. Таким образом, ваши уже существующие файлы остаются нетронутыми. Из описания я не уверен на 100%, что это то, что вы хотите. Если вы оставите эту опцию, git попытается объединить файлы с разным содержимым; но это может быть проблематично. (Вы должны прочитать о стратегиях слияния git, если хотите что-то еще здесь).
  • --allow-unrelated-histories Вот что вы должны понять: то, как это делается здесь, означает, что ваш репозиторий в настоящее время не имеет абсолютно никакого отношения к удаленному репозиторию. Чтобы понять это: git хранит снимки каталога. Вы создали моментальный снимок своего каталога (с помощью первых трех команд). Также есть еще один снимок каталога в удаленном репозитории, который вы скопировали в свой собственный репозиторий git fetch . В дополнение к снимку, git хранит историю в том смысле, что он запоминает, какой снимок был сгенерирован из какого другого снимка (ов); это «предки» снимка. Но ваш снимок был «начальным» снимком без каких-либо предков. Таким образом, он не имеет абсолютно никакой связи с любым другим моментальным снимком из удаленного репозитория. Конечно, по тому, как вы это описываете, я предполагаю, что в какой-то момент вы скопировали удаленный репозиторий, но, по крайней мере, git об этом не знает. В результате git обычно не соглашается на объединение этих двух снимков, потому что в представлении gits эти два снимка совершенно не связаны. Используя эту опцию здесь, вы говорите git просто игнорировать эту несвязанную историю и просто объединить два снимка в любом случае.

затем вы можете посмотреть, что вы сделали с. git log Вы должны увидеть что-то вроде

 commit ... (HEAD -> master)
Merge: ... ...
Author: ...
Date:   Sat Dec 5 02:08:55 2020  0100

    Merge remote-tracking branch 'rmt/master'

commit ...
Author: ...
Date:   Sat Dec 5 02:03:24 2020  0100

    my files
 

Вы можете посмотреть, с какими файлами были добавлены git show HEAD .

Вы можете проверить различия между вашим свежесгенерированным снимком и удаленной веткой с помощью git diff rmt/master..HEAD . Это показывает, что вам нужно изменить в «rmt / master», чтобы получить ваш снимок после слияния.

Ответ №2:

git add . сообщает git добавить (создать) все в текущую папку.

Обычно git не используется таким образом. В большинстве случаев фактически выбирается, какие изменения должны быть внесены в следующий коммит. git add bar.txt будет отображаться только один файл.

Вы также можете создавать несколько файлов с git add bar.txt importantfile.txt

git add -u . будут отображаться все файлы, которые были изменены и уже отслежены.

Редактировать: git на самом деле не заботится о синхронизации папки. Вы всегда можете удалить все и записать файлы новыми. В git фиксация всегда представляет собой снимок полных файлов, которые вы создали, а не набор изменений.

Edit2: извините, я не заметил этого раньше, но ваш рабочий процесс по-прежнему имеет master, указывающий в никуда. Это работает с моей стороны.

 git init
git git remote add origin [url]
git fetch origin
git reset origin/master
git add -u
 

Комментарии:

1. У меня около 10 тысяч файлов на удаленном компьютере и гораздо больше на локальном. Невозможно добавить каждый файл вручную

2. Я не знаю, что вы делаете. Но с файлами 10k, я бы предположил, что вы не пишете их вручную. Как правило, сгенерированные файлы thump не являются хорошими кандидатами для добавления в git. У Git есть свои ограничения, и для вашего варианта использования могут быть лучшие решения. В противном git add -u . случае сделаю то, о чем вы просили.

3. Я уже пробовал это. Но после git add -u . «foo» папка остается «неотслеживаемой»

4. согласно документам git -u должен добавить все отслеживаемые файлы. Вы пробовали git add -u без папки?

5. Конечно. ... git fetch origin amp;amp; git add -u и все еще не отслеживается.

Ответ №3:

Насколько я понимаю, вы ищете git add -u ( git add --update ).

Это обновит индекс (то есть те файлы, которые уже находятся на удаленном компьютере, будут обновлены)

важно: сделайте резервную копию как вашего локального, так и удаленного репозитория, потому что это обновит индекс

И

  • компакт-диск во временную папку
  • сделать git clone <your-remote-repp-url>
  • скопируйте каталог .git из вновь созданного клона
  • замените каталог .git в вашем локальном каталоге на скопированный
  • затем выполните git add -u из локального каталога
  • наконец git commit , и git push