Как правильно сбросить локальный репозиторий git без остатка

Question

Мы только начали использовать git на производстве в нашей компании, и у всех, похоже, одинаковые проблемы / проблемы. Так как мы все еще привыкли использовать git, мы часто портим наши локальные репозитории. (плохие слияния, неправильные команды и т. д.). То, что мы хотим сделать, это вернуть наши локальные репозитории обратно к данной ревизии и избавиться от всех остатков плохих изменений.

Я читал об этом, и я вижу, как я могу использовать 'git reset' с его различными опциями, чтобы перемещать голову и вообще возвращать мою рабочую область в правильное состояние, но мне неясно, что это оставляет в репозитории и как очистить это.

Например, если я выполняю неправильное слияние в локальном хранилище:

мастер проверки git git merge неправильный_отрасль

Я могу сбросить в master, чтобы вернуться к коммиту до этого, но коммит слияния все еще находится в базе данных объекта репозитория? Точно так же, если он находится там и я отправляю свою ветку в удаленный репозиторий, он передаст неверные данные слияния?

Есть ли какой-то способ полностью удалить неверную фиксацию слияния (или любую другую неверную ревизию) из моего локального репозитория, чтобы убедиться, что я не загрязняю публичный репозиторий данными, которые следует игнорировать, как если бы это никогда не происходило?

Answer 1

Прежде всего, если вы все еще изучаете git и работаете над проектом, создайте резервную копию (резервная копия хороша, даже если вы, конечно, эксперт)

Например, вызаявлено, что вы можете просто сделать:

git reset --hard ORIG_HEAD

, чтобы вернуться.

Коммиты слияния все еще будут там, но когда-нибудь они будут "зависать" и очищаться, и вам не нужно беспокоитьсяо них.Они не будут перенесены в другое хранилище.

Кроме того, git reflog - это то, что вы должны знать и с чем знакомы.

Answer 2

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

Пример слияния и сброса

$ git log --online
695d21b add some content
9aefcac initial commit

Теперь вы объединяетесь в ветке возможностей ..

$ git merge --no-ff feature-123
Merge made by the 'recursive' strategy.
feature-123.txt |    1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 feature-123.txt

Однако, посмотрев на изменения, вы понимаете, что не хотели объединяться в этой ветке в конце концов. Нет проблем. Выходные данные журнала показывают, что ветвь master была на 695d21b раньше - просто переместите туда указатель HEAD:

$ git reset --hard 695d21b

Рефлог

Теперь ваша рабочая копия выглядит так, как будто ее никогда не было. Но так как вам было интересно, есть ли что-то еще в хранилище после этого слияния - объект фиксации все еще остается в хранилище:

ec4b538 HEAD@{2}: merge feature-123: Merge made by the 'recursive' strategy.
695d21b HEAD@{6}: checkout: moving from feature-123 to master
c08056a HEAD@{7}: commit: add feature 123
695d21b HEAD@{8}: checkout: moving from master to feature-123
695d21b HEAD@{9}: commit: add some content
9aefcac HEAD@{10}: commit (initial): initial commit

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

Тестирование ..

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

Нажав ..

Если вы вернетесь назад в HEAD, как в примере выше, вам не нужно беспокоиться о переносе мусора в публичное репо: «git push» не будет выталкивать что-либо за пределы вашего текущего HEAD. Однако вам следует помнить, что после того, как вы отправили что-то в публичный репозиторий, вам больше не нужно возиться с историей локально.

Может быть, я слишком обдумал это - надеюсь, это помогло :) 1029 *

Answer 3

Gitx имеет лучший графический интерфейс для визуализации и сброса ветвей, которые я видел. Если вам нужно сбросить ветку на предыдущий коммит, вам просто нужно перетащить иконку ветки на тот коммит, который вы хотите видеть текущим Я делаю большую часть своей работы с Git в командной строке, но Gitx неоценим для визуализации вашей истории и очистки ваших веток.

только OS X.

Answer 4

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