Как восстановить файл, удаление которого было отправлено? - PullRequest
0 голосов
/ 25 марта 2020

Я удалил файл и отправил эти изменения. Мне интересно, как лучше всего восстановить этот файл.

Я думаю о добавлении файла обратно и внесении изменений. Является ли это лучшим способом go об этом?

Редактировать:

После пу sh были другие нажатия кода, но я не хочу отменять эти нажатия.

Я использую GitHub

Ответы [ 2 ]

2 голосов
/ 25 марта 2020

У вас есть разные опции и разные методы в зависимости от того, был ли файл единственным измененным в этом коммите или нет.

  1. Переместить ветку в коммит до того, как файл был удален, и принудительно-пу sh это на расстоянии. Это нормально, если вы единственный, кто работает с хранилищем, или в любом случае вы уверены, что никто не извлек изменения из удаленного хранилища, потому что в этом случае это создаст для них локальные конфликты. Это удаляет все следы удаления из истории, так как коммит, который удалил файл, будет потерян при принудительном нажатии.

    Если плохой коммит - последний коммит, вы можете сделать это с помощью:

    git reset HEAD~1
    git push --force
    

    Если это не последний коммит, я бы не советовал использовать этот метод, так как он будет перезаписывать каждый коммит после изменения его га sh (и это приводит к проблемам при работе с большим количеством соавторов), но это может все еще будет сделано с интерактивной перебазировкой:

    git rebase --interactive <hash_of_bad_commit>~1
    # choose "delete" on the bad commit
    git push --force
    

    Когда спросит git rebase в всплывающем редакторе, измените строку плохого коммита на d (или delete) и сохраните. Возврат должен быть автоматическим c, и вы можете принудительно вызвать pu sh. Вы можете получить ха sh плохого коммита, взглянув на результат git log.

    Если это был , а не единственный файл, измененный при фиксации, то в rebase вам нужно будет выбрать e (или edit) для плохой фиксации, разрешите самостоятельно, а затем зафиксируйте и продолжите перебазирование:

    git rebase --interactive <hash_of_bad_commit>~1
    # choose "edit" on the bad commit
    git checkout HEAD~1 <path_to_deleted_file>
    git commit
    git rebase --continue
    git push --force
    
  2. Создайте отмененный коммит, который отменяет действие плохого, когда вы удалили файл, а затем pu sh для дистанционный пульт. Это самый простой и безопасный вариант. Вы можете сделать это с помощью:

    git revert <hash_of_bad_commit>
    git push
    

    Опять же, вы можете получить га sh плохого коммита, просто взглянув на git log.

    Если это было не единственный файл, затронутый плохим коммитом, вы можете выборочно отменить изменения этого указанного c файла, используя git reset, например:

    git reset <bad_commit_hash> <path_to_deleted_file>
    git commit
    git push
    
  3. Вручную добавьте верните файл назад и создайте новый коммит. Это будет иметь тот же эффект, что и второй вариант, но выполняется вручную.

Я бы порекомендовал вариант 1, если вы хотите очистить историю и работаете в одиночку, вариант 2, если вы не не волнует история коммитов или если вы работаете с репозиторием с несколькими участниками. На самом деле нет никаких оснований для go с опцией 3, поскольку данные уже доступны в истории GIT, вам не нужно повторно добавлять файл вручную, и это может вызвать проблемы, если вы добавите неправильный / другой версия этого.


Обращаясь к вашему редактированию:

После pu sh были другие толчки кода, но я не хочу отменять эти толчки.

Я бы определенно предложил вам go с вариантом 2 выше.

1 голос
/ 25 марта 2020

Изменить: Обратите внимание, что ОП добавил ключевую информацию к вопросу; первая часть этого ответа предполагает что-то не так.


Каждый коммит имеет полный и полный снимок каждого файла (ну, каждый файл, который находится в этом коммите).

Это означает, что у вас есть ряд снимков:

...--F--G--H   <-- somebranch, origin/somebranch

, где H содержит снимок последний , содержащий некоторый набор файлов. Поскольку вы удалили файл, H имеет на один меньше файлов, чем моментальный снимок G.

Если вы сделаете новый снимок с файлом снова, вы получите:

...--F--G--H   <-- origin/somebranch
            \
             I   <-- somebranch

, где снимок в I совпадает с снимком в H, за исключением того, что файл, отсутствующий в H, присутствует в I. Когда вы git push делаете этот коммит для другого Git, другой Git должен принять его и добавить к своим somebranch, чтобы у вас теперь было:

...--F--G--H--I   <-- somebranch, origin/somebranch

Commit H продолжает существовать и ему по-прежнему не хватает файла. Пока это нормально, это нормально.

Вы не можете изменить совершить H, вообще когда-либо, поэтому, если это не хорошо, у вас будет убедить другого Git в сбросить его копию commit H. В общем случае, вы также можете отказаться от своего, сделав новый и улучшенный коммит H, который заменит H:

          H   <-- origin/somebranch
         /
...--F--G--H'  <-- somebranch

, где H' делает есть файл. Затем вы используете Force-Pu sh вариант git push, чтобы сообщить другим Git, что вы знаете, что этот запрос заставит их выбросить их коммит H и заменить его новым и улучшил H', и да, вы хотите, чтобы они это делали.

Если кто-то еще сделал свой коммит, который зависит от существующего коммита H, это не очень хорошо кому-то еще. Убедитесь, что никто не зависит от каких-либо коммитов, которые вы удалите таким образом. Если вы единственный, кто использует репозиторий other Git, это означает, что вам просто нужно согласиться с самим собой. Если другие люди также используют другое хранилище Git, сначала получите свое согласие.

(Если можно оставить H на месте, это почти всегда проще и лучше.)


Re your edit: Эта информация очень важна . Это означает, что уже есть некоторые другие коммиты I, J, et c., Которые приходят после H, в котором отсутствует файл. Принимает I, J, et c., Предположительно также пропускает файл. Если вы создаете новый и улучшенный заменитель H', вы также должны создать новый и улучшенный заменитель I', J', et c.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...