GIT удалить плохую фиксацию и Pu sh в удаленный репозиторий - PullRequest
0 голосов
/ 06 августа 2020

Создается репозиторий, и проект калькулятора клонируется в Python.

Файл newfile.py содержит код. Этот код написан в виде различных коммитов. В предыдущих коммитах код калькулятора работал хорошо. Однако после некоторых фиксаций код калькулятора отображает исключение деления на ноль. Это связано с изменением в строке 2 файла newfile.py.

Используйте cat newfile.py для чтения содержимого файла

Используйте git log для проверки предыдущих коммитов .

Используйте Git Bisect, чтобы найти фиксацию, в которой строка 2 изменена с 'b = 20' на 'b = 0.00000'.

Удалите ошибочную фиксацию, используя Git Вернуть. Оставьте сообщение фиксации как есть.

Pu sh в удаленный репозиторий.

Мой подход:

Я определил плохую фиксацию, используя:

git начало пополам git хорошее биссект git плохое биссект

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

Я выполнил следующие шаги чтобы удалить ошибочную фиксацию:

  1. git revert <>
  2. git bisect reset
  3. Нужна помощь на последнем шаге [Pu sh to удаленный репозиторий] ????? Как сделать этот последний шаг Примечание: я прикрепил репозиторий, показанный во вложении.

[Git консоль показывает ветку]

1 Ответ

0 голосов
/ 06 августа 2020

Когда вы используете git revert, вы не удаляете фиксацию. 1 Вместо этого вы добавляете новую фиксацию , особенно ту, чей эффект отменить эффект предыдущей фиксации. 2 Следствием этого является то, что нет необходимости форсировать ваш pu sh вообще. Ваш новый коммит может быть отправлен с обычным, не принудительным git push.

Помните, что git push работает, когда ваш Git вызывает другой Git. Ваш Git и их Git затем проводят своего рода беседу, где ваш Git объявляет своим Git, что ваш Git имеет для них новую фиксацию. Если они никогда раньше не видели эту фиксацию 3 , они попросят ваш Git отправить его.

Затем, отправив им новую фиксацию отката, ваш Git попросит их Git, чтобы установить одно из их имен веток - то, которое вы используете в своей git push команде - для записи этой новой фиксации как последней фиксации в их ветке . Другими словами, их master, develop или любое другое имя, которое вы здесь используете, это их имя, которым они могут управлять, как им нравится. У вас просто есть Git и попросите их установить свое имя, чтобы запомнить ваш новый коммит, вместо того, что он запомнил прямо сейчас.

Если они согласны установить это имя как вы запрашиваете, ваш git push успешно. Если они отклонят этот запрос по какой-то причине, , тогда вы должны изучить , почему они отклонили его, и выяснить, что они хотят вместо этого.

1 Как правило, все коммиты доступны как только для чтения, так и постоянны. - это возможность отбросить существующие коммиты, но это сложно и обычно не рекомендуется, с одним конкретным набором исключений: любые сделанные вами коммиты, но не отправленные кому-либо еще - это То есть, вы не использовали git push по publi sh их для использования другими - ваши и только ваши, поэтому вы можете удалить их без каких-либо последствий. Проблема с удалением опубликованных коммитов заключается в том, что коммиты немного похожи на вирусы: свяжите свой Git с другим Git, у которого есть этот коммит, и вы получите его снова. Итак, если вы опубликовали какую-то фиксацию, вы удаляете ее, затем подключаетесь к любому Git, который где-либо видел опубликованную фиксацию, ну, теперь она у вас снова.

(Обратите внимание, что все фиксации полностью доступен только для чтения. Уникальный идентификатор ha sh для некоторого коммита на самом деле является криптографической c контрольной суммой содержимого этого коммита, поэтому, если вы извлечете коммит из репозитория Git, измените его содержимое и вернете его обратно , вы получите новую фиксацию с новым и другим идентификатором ha sh. Существующая фиксация остается в репозитории со своим существующим идентификатором ha sh.)

2 Обратите внимание, что отмена коммита merge не отменяет того факта, что слияние действительно произошло. Он только отменяет изменения кода.

3 Каждая фиксация имеет уникальный номер - ha sh ID - который зарезервирован для этой конкретной фиксации, и каждый Git везде соглашается, что , что ha sh ID соответствует , что коммит. Таким образом, ваш Git должен только предоставить свой номер фиксации другому Git. Другой Git проверяет свою базу данных всех коммитов, и, если у него нет этого коммита, говорит да, пришлите мне этот коммит . Если у него уже есть этот коммит, он говорит: нет необходимости, у меня уже есть этот коммит . Вот как ваш Git и их Git могут определить, какие коммиты у вас есть, какие нет (git push), какие у них есть, а какие нет (git fetch).

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