Git reset origin master hard: Undo a git reset —hard origin/master

В чем разница между «git reset —hard master» и «git reset —hard origin/master»?

master, HEAD, origin/something и, может быть, какой-то тег, почему бы и нет,мая все указывают на одну и ту же фиксацию, но они определенно не одно и то же.

origin обычно это имя пульт ДУ хранилище.

вы можете увидеть свои пульты и настроить новые с git remote -v.

попробуй (с -v) и это, вероятно, будет иметь смысл.

remote/somebranch указывает на голову некоторых ветки на удаленном репозитории.

origin/master указывает на главу master on origin.

это то же самое как master?

да и нет. Если вы потянете свою главную ветку, выполните некоторую работу, а тем временем кто-то другой совершит master и подталкивает к origin они будут отличаться.

когда вы git fetch origin, потом origin/master будет иметь дополнительные коммиты (будет вперед).

HEAD просто «the текущая фиксация».
Думайте об этом как ..

посмотреть этот вопрос

еще раз, это мог бы быть таким же, как master, но если вы проверяете другую ветку или фиксацию или находитесь в середине ребаза, ну, это не так.

поэтому попробуйте это на новом репозитории, над которым никто больше не работает:

$ git checkout master
$ git log -1 --format="%H" HEAD
123abc
$ git log -1 --format="%H" origin/master
123abc

они одинаковые!

$ git diff origin/master

конечно их содержание тот же.

$ echo "foo" > foo
$ git add foo
$ git commit -m "Foo the thingy"
$ git log -1 --format="%H" HEAD
321bca
$ git log -1 --format="%H" origin/master
123abc

Ах, смотрите, теперь они разные!

$ git push origin master
$ git log -1 --format="%H" HEAD
321bca
$ git log -1 --format="%H" origin/master
321bca

а теперь их нет! мы подтолкнули нашу последнюю приверженность, и они оба указывают на то же самое.

$ git checkout -b newbranch
$ echo "baz" > baz
$ git add baz
$ git commit -m "Baz the thingy with the stuff"
$ git branch -a
  master
* new_branch
  origin/master
$ git log -1 --format="%H"
789def
$ git log -1 --format="%H" master
321bca
git log -1 --format="%H" origin/master
321bca
git log -1 --format="%H" origin/new_branch
unknown revision or path not in the working tree.

конечно, нет. Мы не давили new_branch to origin, это только на локальной машине

git checkout 123abc

мы только что проверили 123abc старые главы master. Это не глава филиала, но мы можем это проверить только тот же.

Note: checking out 123abc. You are in 'detached HEAD' state, etc
$ git checkout -b old_master
$ git branch -a
  master
* new_branch
  origin/master
  old_master

теперь угадайте, что их SHA1 будет соответственно?

—soft, —mixed(по умолчанию), —hard / Хабр

К моему удивлению на целом хабрахабре нет ни одного поста где бы было понятно написано про 3 вида

git reset

. Например, во

второй по релевантности статье

по запросу «git reset» автор пишет что «данное действие может быть двух видов: мягкого(soft reset) и жесткого(hard reset)». Режим

--mixed

, используемый по умолчанию, почему-то не удостоился упоминания.

Ничего удивительного, что часто видишь непонимание работы этой команды. Под катом коротко и ясно расскажу о всех трёх режимах git reset, после прочтения топика неясностей остаться не должно.

Сделанные изменения в репозитории по умолчанию имеют статус unstaged. Для того чтобы их закоммитить сначала вы должны добавить изменения в индекс, выполнив git add. Когда вы делаете git commit, в репозиторий будет закоммичено только то, что было в индексе.

git reset —soft

Возьмем для примера ветку:

- A - B - C (master)
HEAD

указывает на

C

и индекс совпадает с

C

.

После выполнения

git reset --soft B

HEAD

будет указывать на

B

и изменения из коммита

C

будут в индексе, как будто вы их добавили командой

git add

. Если вы сейчас выполните

git commit

вы получите коммит полностью идентичный

C

.

git reset —mixed (по умолчанию)

Режим

--mixed

используется по умолчанию, т.е.

git reset --mixed = git reset

Вернемся к тем же начальным условиям:
- A - B - C (master)

Выполнив

git reset --mixed B

или

git reset B

HEAD

опять же будет указывать на

B

, но на этот раз изменения из

С

не будут в индексе и если вы запустите здесь

git commit

ничего не произойдет т.к. ничего нет в индексе. У нас есть все изменения из

С

, но если запустить

git status

то вы увидите, что все изменения not staged. Чтобы их закоммитить нужно сначала добавить их в индекс командой

git add

и только после этого

git commit

.

git reset —hard

Те же самые начальные условия:

- A - B - C (master)

Последний режим --hard также как и --mixed переместит HEAD на В и очистит индекс, но в отличие от --mixed жесткий reset изменит файлы в вашей рабочей директории. Если выполнить

git reset --hard B

то изменения из

С

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

B

. Учитывая то, что этот режим подразумевает потерю изменений, вы

всегда

должны проверять

git status

перед тем как выполнить жесткий reset чтобы убедиться что нет незакоммиченных изменений(или они не нужны).

Сравнительную таблицу режимов git reset:

Ну и напоследок картинкой: (thx to

VBauer

)

Доходчивое объяснение Git Reset | Techrocks

Перевод статьи «Git Reset Explained – How to Save the Day with the Reset Command».

«Помогите! Я закоммитил не в ту ветку!» «Ну вот, опять… Где мой коммит?» Знакомые ситуации, правда?

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

Со временем я стал кем-то вроде «того парня, который разбирается в Git».

Мы используем git постоянно, и обычно он помогает нам в работе. Но порой (и куда чаще, чем нам хотелось бы!) что-то идет не так.

Бывает, мы отправляем коммит не в ту ветку. Бывает, теряем часть написанного кода. А можем и добавить в коммит что-то лишнее.

Source: xkcd.com

По git есть много онлайн-ресурсов, и часть из них (например, вот эта статья) фокусируется на том, что делать в таких вот нежелательных ситуациях.

Но мне всегда казалось, что в этих ресурсах не хватает объяснений, почему нужно делать так, а не иначе. Когда приводится набор команд, что делает каждая из них? И вообще, как вы пришли к этим командам?

В прошлом посте я рассказывал о внутреннем устройстве Git. И хотя понимать его полезно, читая теория практически всегда недостаточна. Как применить свои знания внутреннего устройства git и использовать их для решения возникающих проблем?

В этом посте я хотел бы построить мост между теорией и практикой и рассказать о команде git reset. Мы разберем, что делает эта команда, что происходит за кулисами, а также применим эти знания в различных сценариях.

Исходные условия — рабочая директория, индекс и репозиторий

Чтобы разобраться во внутренних механизмах git reset, важно понимать процесс записи изменений внутри git. В частности, я имею в виду записи в рабочей директории, индексе и репозитории.

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

Когда мы работаем над кодом своего проекта, мы делаем это в рабочей директории. Ею может быть любая директория в нашей файловой системе, имеющая привязанный к ней репозиторий. В ней хранятся папки и файлы нашего проекта, а также директория под названием .git.

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

Давайте создадим в рабочей директории какой-нибудь файл и запустим команду git status:

Да, git не записал (не закоммитил) изменения, сделанные в рабочей директории, напрямую в репозиторий.

Вместо этого изменения сначала регистрируются в индексе (или в стейджинге). Оба эти термина означают одно и то же, и оба часто используются в документации git. В этой статье мы тоже будем пользоваться обоими, так как они полностью взаимозаменяемы.

Когда мы применяем git add, мы добавляем файлы (или изменения внутри файлов) в стейджинг. Давайте попробуем использовать эту команду для только что созданного файла:

Как показывает git status, наш файл теперь в стейджинге и готов к коммиту. Да, он еще не является частью никакого коммита. Другими словами, сейчас он находится в рабочей директории, а также в индексе, но не в репозитории.

Если мы теперь выполним git commit, мы создадим коммит на основе состояния индекса. Таким образом новый коммит (в примере — commit 3) будет включать файл, который мы чуть ранее добавили в стейджинг.

Рабочая директория находится в точно таком же состоянии, как индекс и репозиторий.

При выполнении git commit текущая ветка master начинает указывать на только что созданный объект commit.

Внутренняя работа git reset

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

У git reset есть три режима: --soft, --mixed и --hard. Я рассматриваю их как три стадии:

• Стадия 1. Обновление HEAD — git reset --soft
• Стадия 2. Обновление индекса — git reset --mixed
• Стадия 3. Обновление рабочей директории — git reset --hard

Стадия 1. Обновление HEAD — git reset —soft

Прежде всего, git reset меняет то, на что указывает HEAD. Если мы выполним git reset --hard HEAD~1, HEAD будет указывать не на master, а на HEAD~1. Если использовать флаг --soft, git reset на этом и остановится.

Если вернуться к нашему примеру, HEAD будет указывать на commit 2, и таким образом new_file.txt не будет частью дерева текущего коммита. Но он будет частью индекса и рабочей директории.

Если посмотреть git status, мы увидим, что этот файл определенно в стейджинге, но не закоммичен.

Иными словами, мы вернули процесс на стадию, где мы уже применили git add, но еще не применяли git commit.

Стадия 2. Обновление индекса — git reset —mixed

Если мы используем git reset --mixed HEAD~1, git не остановится на обновлении того, на что указывает HEAD. Помимо этого обновится еще и индекс (до состояния уже обновленного HEAD).

В нашем примере это значит, что индекс будет в том же виде, что и commit 2:

Таким образом мы вернули процесс на стадию до выполнения команды git add. Новосозданный файл является частью рабочей директории, но не индекса и не репозитория.

Стадия 3. Обновление рабочей директории — git reset —hard

Если использовать git reset  -- hard HEAD~1, то после перевода указателя HEAD (на что бы он ни указывал раньше) на HEAD~1, а также обновления индекса до (уже обновленного) HEAD, git пойдет еще дальше и обновит рабочую директорию до состояния индекса.

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

Собственно, мы вернули весь процесс на этап до создания файла my_file.txt.

Применяем наши знания в реальных сценариях

Теперь, когда мы разобрались с тем, как работает git reset, давайте применим эти знания, чтобы спасти какую-нибудь ситуацию!

1. Упс! Я закоммитил что-то по ошибке

Рассмотрим следующий сценарий. Мы создали файл со строкой «This is very importnt», отправили его в стейджинг, а после — в коммит.

А затем — ой! — обнаружили, что в предложении у нас опечатка.

Ну, теперь-то мы знаем, что это можно легко исправить. Мы можем отменить наш последний коммит и вернуть файл в рабочую директорию, используя git reset --mixed HEAD~1. Теперь моно отредактировать содержимое файла и сделать коммит еще раз.

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

2. Упс! Я сделал коммит не в ту ветку, а эти изменения мне нужны в новой ветке

Со всеми нами такое случалось. Сделал что-то, закоммитил…

О нет, мы сделали коммит в ветку master, а надо было создать новую и затем сделать пул-реквест.

Я считаю, что здесь будет полезно визуализировать наше положение и то положение, в котором мы хотели бы оказаться.

Собственно, от желаемого состояния нас отделяют три изменения.

1. Ветка new должна указывать на наш недавно добавленный коммит.
2. Ветка master должна указывать на предыдущий коммит.
3. HEAD должен указывать на new.

Мы можем достичь желаемого положения в три шага:

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

Во-вторых, нужно сделать так, чтобы master указывала на предыдущий коммит (иными словами, на HEAD~1). Достичь этого можно при помощи команды git reset --hard HEAD~1. Таким образом мы достигаем следующего состояния:

Наконец, мы хотели бы оказаться в ветке new, т. е. сделать так, чтобы HEAD указывал на new. Это легко достижимо путем выполнения команды git checkout new.

Итого:

• git branch new
• git reset --hard HEAD~1
• git checkout new

3. Упс! Я отправил коммит не в ту ветку, а он мне нужен в другой (уже существующей) ветке

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

О нет, мы отправили коммит в ветку master, а нужно было отправить в совсем другую.

Давайте снова изобразим текущее и желаемое положение:

У нас опять же есть три отличия.

Нам нужно, чтобы самый последний коммит оказался в ветке existing. Поскольку в настоящее время на этот коммит указывает master, мы можем попросить git взять последний коммит из ветки master и применить его к ветке existing:

• git checkout existing — переключение на ветку existing,
• git cherry-pick master — применение последнего коммита в ветке master к текущей ветке (existing).

Теперь наше положение следующее:

Все, что нам нужно, это сделать так, чтобы master указывала на предыдущий коммит, а не на самый последний. Для этого:

• git checkout master  —  смена активной ветки на master,
• git reset --hard HEAD~1 —  теперь мы вернулись к изначальному состоянию этой ветки.

Таким образом мы достигли желаемого положения:

Итоги

В этой статье мы изучили, как работает git reset, а также разобрали три разных режима этой команды: --soft, --mixed и --hard.

Также мы применили свои новые знания для решения жизненных задач.

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

Git-команды для исправления ошибок | Techrocks

Если вы ошиблись в Git’е, разобраться, что происходит и как это исправить, — непростая задача. Документация Git — это кроличья нора, из которой вы вылезете только зная конкретное название команды, которая решит вашу проблему. Сайт tproger.ru в своем переводе статьи «Oh Shit, Git!?!» рассказал о командах, которые помогут вам выбраться из проблемных ситуаций.

Вот блин, я сделал что-то не то… У Git ведь есть машина времени?!

git reflog
# Тут вы увидите всё, что вы делали
# в Git во всех ветках.
# У каждого элемента есть индекс HEAD@{index}.
# Найдите тот, после которого всё сломалось.
git reset HEAD@{index}
# Машина времени к вашим услугам.

Так вы можете восстановить то, что случайно удалили, и откатить слияние, после которого всё сломалось. reflog используется очень часто — давайте поблагодарим того, кто предложил добавить его в Git.

Я только что сделал коммит и заметил, что нужно кое-что поправить!

# Внесите изменения
git add . # или добавьте файлы по отдельности.
git commit --amend --no-edit
# Теперь последний коммит содержит ваши изменения.
# ВНИМАНИЕ! Никогда не изменяйте опубликованные коммиты.

Обычно эта команда нужна если вы что-то закоммитили, а потом заметили какую-то мелочь, например отсутствующий пробел после знака =. Конечно вы можете внести изменения новым коммитом, а потом объединить коммиты с помощью rebase -i, но это гораздо дольше.

Внимание! Никогда не изменяйте коммиты в публичной ветке. Используйте эту команду только для коммитов в локальной ветке, иначе вам конец.

Мне нужно изменить сообщение последнего коммита!

git commit --amend
# Открывает редактор сообщений коммита.

Тупые требования к оформлению сообщений…

Я случайно закоммитил что-то в мастер, хотя должен был в новую ветку!

# Эта команда создаст новую ветку из текущего состояния мастера.
git branch some-new-branch-name
# А эта — удалит последний коммит из мастер-ветки.
git reset HEAD~ --hard
git checkout some-new-branch-name
# Теперь ваш коммит полностью независим :)

Команды не сработают, если вы уже закоммитили в публичную ветку. В таком случае может помочь git reset HEAD@{какое-то-количество-коммитов-назад} вместо HEAD~.

Ну отлично. Я закоммитил не в ту ветку!

# Отменяет последний коммит, но оставляет изменения доступными.
git reset HEAD~ --soft
git stash
# Переключаемся на нужную ветку.
git checkout name-of-the-correct-branch
git stash pop
# Добавьте конкретные файл или не парьтесь и закиньте все сразу.
git add .
git commit -m «Тут будет ваше сообщение»
# Теперь ваши изменения в нужной ветке.

Многие в такой ситуации предлагают использовать cherry-pick, так что можете выбрать, что вам больше по душе.

git checkout name-of-the-correct-branch
# Берём последний коммит из мастера.
git cherry-pick master
# Удаляем его из мастера.
git checkout master
git reset HEAD~ --hard

Я пытаюсь запустить diff, но ничего не происходит

Если вы знаете, что изменения были внесены, но diff пуст, то возможно вы индексировали изменения (через add). Поэтому вам нужно использовать специальный флаг.

git diff --staged

Конечно, «это не баг, а фича», но с первого взгляда это чертовски неоднозначно.

Мне нужно каким-то образом отменить коммит, который был сделан 5 коммитов назад

# Найдите коммит, который нужно отменить.
git log
# Можно использовать стрелочки, чтобы прокручивать список вверх и вниз.
# Сохраните хэш нужного коммита.
git revert  [тот хэш]
# Git создаст новый коммит, отменяющий выбранный.
# Отредактируйте сообщение коммита или просто сохраните его.

Вам не обязательно откатываться назад и копипастить старые файлы, замещая ими новые. Если вы закоммитили баг, то коммит можно отменить с помощью revert.

Помимо этого, откатить можно не целый коммит, а отдельный файл. Но следуя канону Git’а, это будут уже совсем другие команды…

Мне нужно отменить изменения в файле

# Найдите хэш коммита, до которого нужно откатиться.
git log
# Сохраните хэш нужного коммита.
git checkout [тот хэш] --path/to/file
# Теперь в индексе окажется старая версия файла.
git commit -m «О май гадбл, вы даже не использовали копипаст»

Именно поэтому checkout — лучший инструмент для отката изменений в файлах.

Давай по новой, Миша, всё х**ня

cd ..
sudo rm -r fucking-git-repo-dir
git clone https://some.github.url/fucking-git-repo-dir.git
cd fucking-git-repo-di

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

Будьте осторожны, эти команды разрушительны и необратимы.

# Получить последнее состояние origin.
git fetch origin
git checkout master
git reset --hard origin/master
# Удалить неиндексированные файлы и папки.
git clean -d --force
# Повторить checkout/reset/clean для каждой испорченной ветки.

Различные способы удаления локальных изменений Git

причина для добавления ответа в данный момент:

до сих пор я добавлял заключение и «ответы» к самому моему первоначальному вопросу, делая вопрос очень длинным, следовательно, переходя к отдельному ответу.

я также добавил больше часто используемые команды git это помогает мне на git, чтобы помочь кому-то еще тоже.

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

#задает имя, которое вы хотите прикрепить к вашим транзакциям фиксации

$ git config --global user.name "[name]"

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

$ git config --global user.email "[email address]"

#список глобальной конфигурации

$ git config --list

#проверка статуса

git status

#Список всех локальных и удаленных филиалов

git branch -a

#создать новый локальный филиал и начать работать на этой ветке

git checkout -b "branchname" 

или, это может быть сделано в два этапа

создать ветку: git branch branchname
работа над этой веткой:git checkout branchname

#совершают локальные изменения [двухэтапный процесс: — Добавить файл в индекс, что означает добавление в промежуточную область. Затем зафиксируйте файлы, которые присутствуют в этой промежуточной области]

git add <path to file>

git commit -m "commit message"

#checkout некоторые другие местные ветка

git checkout "local branch name"

#удалить все изменения в местное отделение [Предположим, вы внесли некоторые изменения в локальную ветвь, такие как добавление нового файла или изменение существующего файла, или создание локальной фиксации, но больше не нужно этого]
git clean -d -f и git reset --hard [очистить все локальные изменения, внесенные в локальную ветвь, за исключением локальной фиксации]

git stash -u также удаляет все изменения

Примечание:
Ясно, что мы можем использовать либо
(1) комбинация git clean –d –f и git reset --hard
ИЛИ
(2) git stash -u
для достижения желаемого результата.

Примечание 1: тайник, так как слово означает » хранить (что-то) безопасно и тайно в указанном месте.- Это всегда можно восстановить с помощью git stash pop. Поэтому выбор между указанными выше двумя вариантами является вызовом разработчика.

примечание 2: git reset --hard удалит изменения рабочего каталога. Перед выполнением этой команды обязательно сохраните все локальные изменения, которые вы хотите сохранить.

# переключатель в главную ветвь и убедитесь, что вы не в курсе.

git checkout master

git fetch [это может быть необходимо (в зависимости от конфигурации git) для получения обновлений на origin / master ]

git pull

# слить ветку в ветку master.

git merge feature_branch

# сброс главной ветви в исходное состояние.

git reset origin/master

#случайно удалил файл из локального, как его восстановить назад?
Сделай git status чтобы получить полный путь к файлу удаленных ресурсов

git checkout branchname <file path name>

вот именно!

#объединить главную ветвь с какой-то другой ветвью

git checkout master
git merge someotherbranchname

#переименовать местного отделения

git branch -m old-branch-name new-branch-name

#удалить локальную ветку

git branch -D branch-name

#удалить удаленную ветку

git push origin --delete branchname

или

git push origin :branch-name

#revert a фиксация уже перенесена в удаленный репозиторий

git revert hgytyz4567

#ответвление от предыдущей фиксации с помощью GIT

git branch branchname <sha1-of-commit>

#изменить сообщение фиксации самого последнего фиксации, который уже был отправлен на удаленный

git commit --amend -m "new commit message"
git push --force origin <branch-name>

# отбрасывание всех локальных коммитов на этой ветке[удаление локальных коммитов]

чтобы отбросить все локальные коммиты на этой ветке, чтобы сделать локальная ветвь идентична «вверх по течению» этой ветви, просто запустите

git reset --hard @{u}

ссылка:http://sethrobertson.github.io/GitFixUm/fixup.html
или сделать git reset --hard origin/master [если локальная ветвь является главной]

# отменить фиксацию, уже переданную в удаленный репозиторий?

$ git revert ab12cd15

#удалить предыдущую фиксацию из локальной ветви и удаленной ветви

Use-Case: вы только что совершили переходите в свою локальную ветку и сразу же нажимаете на удаленную ветку, вдруг поняли, о нет! Мне не нужны эти изменения. И что теперь делать?

git reset --hard HEAD~1 [для удаления этой фиксации из локальной ветви. 1 обозначает тот коммит, который вы сделали]

git push origin HEAD --force [обе команды должны быть выполнены. Для удаления из удаленной ветки]. В настоящее время извлеченная ветвь будет называться ветвью, в которой вы выполняете эту операцию.

#удалить некоторые из последних фиксация из локального и удаленного РЕПО и сохранение до фиксации, которую вы хотите. (своего рода возврат коммитов из локального и удаленного)

предположим, у вас есть 3 коммита, которые вы нажали на удаленную ветку с именем ‘develop‘

commitid-1 done at 9am
commitid-2 done at 10am
commitid-3 done at 11am. // latest commit. HEAD is current here.

вернуться к старой фиксации (чтобы изменить состояние ветви)

git log --oneline --decorate --graph //, чтобы увидеть все ваши commitids

git clean -d -f // очистить все локальные изменения

git reset --hard commitid-1 // локально возвращаясь к этому commitid

git push -u origin +develop // Нажмите это состояние на пульт. + делать силу толчка

# удалить локальное слияние git:
Случай:
Я нахожусь на главной ветви и объединил главную ветвь с новой рабочей ветвью phase2

$ git status

на ветке мастер

$ git merge phase2
$ git status

на ветке мастер

ваша ветвь опережает «origin / master» по 8 совершает.

Q:Как избавиться от этого локального слияния git? пробовал git reset --hard и git clean -d -f оба не сработали.
Единственное, что работала являются ли какие-либо из приведенных ниже:

$ git reset —hard origin / master

или

$ git reset —hard HEAD~8

или

$ git reset --hard 9a88396f51e2a068bb7 [sha commit code — это тот, который присутствовал до всех ваших коммитов слияния случилось]

#создать файл gitignore

touch .gitignore // создать файл в Mac или unix пользователей

образец .содержание пример:

.project
*.py
.settings

ссылка на шпаргалку GIT: https://services.github.com/on-demand/downloads/github-git-cheat-sheet.pdf

Шпаргалка по коммандам GIT

Игнорируем изменения прав файлов (chmod)

git config core.fileMode false

Используем флаг —global чтобы настройка применялась для всех репозиториев(использует ~/.gitconfig вместо .git/config)

git config --global core.fileMode false

error: The following untracked working tree files would be overwritten by merge

git fetch --all
git reset --hard origin/master

Локальный git ignore

.gitignore для всех проектов:

git config --global core.excludesfile ~/.gitexcludes
nano ~/.gitexcludes

.gitignore для конкретного проекта:

nano .git/info/exclude

Удаляем тег на удаленном репозитории

Удаляем тег с remote:

git push --delete origin tagname

Удаляем тег локально:

git tag --delete tagname

Слияние ветки в master

git checkout master
git merge some-branch
git push

Прячем правки (сохраняем на потом)

git stash
git stash list
git checkout -b some-branch
git stash pop (git stash apply stash@{0})

Откатываем последний комит в remote

Ситуация

git add .
git commit -m "comment"
git push origin master

А надо было выполнить:

git push origin some-branch

Решение

Пушим изменения в правильную ветку:

git push origin some-branch

Потом на мастере получим изменения из удалённой репы:

git checkout master
git fetch --all
git rebase origin/master

Сбрасываем изменения на один шаг назад, и принудительно пушим в мастер:

git reset --hard HEAD~1
git push origin master -f 

Смотрим изменения перед пушем

Только файлы:

git diff --stat --cached origin/master

 composer.lock | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

Содержимое:

git diff --cached origin/master

Создание и применение патча

Создание патча

git diff --no-prefix > some-fix.patch

Применение патча:

git apply some-fix.patch

Тоже самое без git:

Создание патча

diff -Naru test.old.txt test.txt > some-fix.patch

Применение патча

patch -p0 < some-fix.patch

33. Сброс Мастер ветки

Голы

• Сбросить главную ветвь до точки до конфликтующей фиксации.

01 Сброс главной ветви

Интерактивный режим, который мы добавили в главную ветку, стал изменением, противоречащим изменениям в ветке стиля. Давайте вернем изменения в основной ветке до момента, когда было внесено изменение конфликта.Это позволяет нам продемонстрировать команду rebase, не беспокоясь о конфликтах.

Пробег:

 мастер проверки git
git hist 

Результат:

 $ git hist
* 454ec68 09.03.2011 | Жизнь замечательна! (РУКОВОДИТЕЛЬ, мастер) [Александр Швец]
* 6c0f848 09.03.2011 | Добавлен README [Александр Швец]
* 8029c07 09.03.2011 | Добавлен index.html. [Александр Швец]
* 567948a 09.03.2011 | Файл hello.html перенесен в библиотеку [Александр Швец]
* 6a78635 09.03.2011 | Добавить комментарий автора / адрес электронной почты [Александр Швец]
* fa3c141 09.03.2011 | Добавлен HTML-заголовок (v1) [Александр Швец]
* 8c32287 09.03.2011 | Добавлены стандартные теги HTML-страницы (v1-beta) [Александр Швец]
* 43628f7 09.03.2011 | Добавлен тег h2 [Александр Швец]
* 911e8c9 09.03.2011 | Первый коммит [Александр Швец] 

Фиксация «Добавлен README» идет непосредственно перед добавленным конфликтующим интерактивным режимом.Прямо сейчас нам нужно сбросить основную ветку на ветку «Добавлен README».

Пробег:

 git reset --hard <хэш>
git hist --all 

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

Результат:

 $ git reset --hard 6c0f848
HEAD теперь на 6c0f848 Добавлен README
$ git hist --all
* 6c0f848 09.03.2011 | Добавлен README (HEAD, master) [Александр Швец]
| * 07a2a46 09.03.2011 | Обновленный index.html (стиль) [Александр Швец]
| * 649d26c 09.03.2011 | Hello использует style.css [Александр Швец]
| * 1f3cbd2 09.03.2011 | Добавлена ​​таблица стилей css [Александр Швец]
| /
* 8029c07 09.03.2011 | Добавлен index.html. [Александр Швец]
* 567948a 09.03.2011 | Файл hello.html перенесен в библиотеку [Александр Швец]
* 6a78635 09.03.2011 | Добавить комментарий автора / адрес электронной почты [Александр Швец]
* fa3c141 09.03.2011 | Добавлен HTML-заголовок (v1) [Александр Швец]
* 8c32287 09.03.2011 | Добавлены стандартные теги HTML-страницы (v1-beta) [Александр Швец]
* 43628f7 09.03.2011 | Добавлен тег h2 [Александр Швец]
* 911e8c9 09.03.2011 | Первый коммит [Александр Швец] 

Как отменить (почти) что угодно с помощью Git

Одна из самых полезных функций любой системы контроля версий — это возможность «исправлять» ваши ошибки.В Git «отменить» может означать много разных вещей.

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

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

Отменить «публичное» изменение

Сценарий: Вы только что запустили git push , отправив свои изменения на GitHub, теперь вы понимаете, что есть проблема с одним из этих коммитов.Вы хотите отменить эту фиксацию.

Отменить с помощью: git revert

Что происходит: git revert создаст новую фиксацию, противоположную (или инверсную) заданному SHA. Если старая фиксация является «материей», новая фиксация — «анти-материей» — все, что удалено в старой фиксации, будет добавлено в новую фиксацию, а все, что добавлено в старой фиксации, будет удалено в новой фиксации.

Это самый безопасный и базовый сценарий «отмены» Git, поскольку он не изменяет историю , поэтому теперь вы можете git нажать на новую «обратную» фиксацию, чтобы отменить ошибочную фиксацию.

Исправить последнее сообщение фиксации

Сценарий: Вы только что опечатали последнее сообщение коммита, вы выполнили git commit -m "Fxies bug # 42" , но до git push вы поняли, что действительно должны сказать: «Fixes bug # 42».

Отменить с помощью: git commit --amend или git commit --amend -m "Исправляет ошибку № 42"

Что происходит: git commit --amend обновит и заменит самую последнюю фиксацию на новую фиксацию, которая объединяет любые поэтапные изменения с содержимым предыдущей фиксации.Пока ничего не поставлено, это просто перезаписывает предыдущее сообщение фиксации.

Отменить «локальные» изменения

Сценарий: Кот прошел по клавиатуре и каким-то образом сохранил изменения, затем вылетел редактор. Однако вы не зафиксировали эти изменения. Вы хотите отменить все в этом файле — просто вернитесь к тому, как это выглядело при последней фиксации.

Отменить с помощью: git checkout - <плохое имя файла>

Что происходит: git checkout изменяет файлы в рабочем каталоге до состояния, ранее известного Git.Вы можете указать имя ветки или конкретный SHA, к которому вы хотите вернуться, или, по умолчанию, Git будет предполагать, что вы хотите проверить HEAD , последнюю фиксацию в текущей проверенной ветке.

Имейте в виду: любые изменения, которые вы «отменяете» таким образом, на самом деле , пропали. Они никогда не были зафиксированы, поэтому Git не сможет помочь нам восстановить их позже. Убедитесь, что вы знаете, что здесь выбрасываете! (Возможно, для подтверждения используйте git diff .)

Сброс «локальных» изменений

Сценарий: Вы сделали несколько коммитов локально (еще не отправили), но все ужасно, вы хотите отменить последние три коммита — как будто их никогда не было.

Отменить с помощью: git reset <последний хороший SHA> или git reset --hard <последний хороший SHA>

Что происходит: git reset полностью перематывает историю вашего репозитория до указанного SHA. Как будто этих коммитов никогда не было. По умолчанию git reset сохраняет рабочий каталог. Коммиты удалены, но содержимое все еще находится на диске. Это самый безопасный вариант, но часто вам нужно «отменить» коммиты и изменений за один ход — это то, что делает --hard .

Повторить после отмены «локально»

Сценарий: Вы сделали несколько коммитов, выполнили git reset --hard , чтобы «отменить» эти изменения (см. Выше), и , затем понял: вы хотите вернуть эти изменения!

Отменить с помощью: git reflog и git reset или git checkout

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

Вы, вероятно, знакомы с командой git log , которая показывает список коммитов. git reflog аналогичен, но вместо этого показывает список раз, когда HEAD менялись.

Некоторые предостережения:

• ГОЛОВА меняет только . HEAD изменяется, когда вы переключаете ветки, делаете коммиты с помощью git commit и отменяете коммиты с помощью git reset , но HEAD меняет , а не , когда вы git checkout - <плохое имя файла> (от более ранний сценарий — как упоминалось ранее, эти изменения никогда не фиксировались, поэтому рефлог не может помочь нам их восстановить.
• git reflog не вечен. Git будет периодически очищать «недоступные» объекты. Не ждите, что в рефлоге вечно валяются коммиты месячной давности.
• Ваш журнал ссылок ваш и только ваш. Вы не можете использовать git reflog для восстановления не отправленных коммитов другого разработчика.

Итак … как использовать журнал ссылок для «повторения» ранее «отмененного» коммита или коммитов? Зависит от того, чего именно вы хотите добиться:

• Если вы хотите восстановить историю проекта в том виде, в котором она была на тот момент времени, используйте git reset --hard
• Если вы хотите воссоздать один или несколько файлов в своем рабочем каталоге в том виде, в котором они были в тот момент, без изменения истории, используйте git checkout -
• Если вы хотите воспроизвести ровно один из этих коммитов в вашем репозитории, используйте git cherry-pick

Еще раз, с разветвлением

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

Отменить с: функция ветки git , git reset --hard origin / master и функция проверки git

Что происходит: Возможно, вы привыкли создавать новые ветки с помощью git checkout -b — это популярный ярлык для создания новой ветки и немедленной проверки ее, но вы не хотите переключить ветки пока что. Здесь функция git branch создает новую ветку с именем feature , указывающую на ваш последний коммит, но оставляет вас проверенным на master .

Затем, git reset --hard перематывает master обратно на origin / master перед любым из ваших новых коммитов. Не волнуйтесь, они по-прежнему доступны на , функция .

Наконец, git checkout переключается на новую ветку feature со всей вашей недавней работой.

Филиал вовремя спасает девять

Сценарий: Вы запустили новую ветку feature на основе master , но master довольно сильно отставал от origin / master .Теперь, когда ветвь master синхронизирована с origin / master , вы хотите, чтобы коммиты для функции начинались с сейчас , а не так сильно отставали.

Отменить с помощью: git checkout feature и git rebase master

Что происходит: Вы могли бы сделать это с помощью git reset (нет --hard , намеренно сохраняя изменения на диске), затем git checkout -b <новое имя ветки> и затем повторно зафиксировать изменения, но так вы потеряете историю коммитов.Есть способ получше.

git rebase master делает пару вещей:

• Сначала он находит общего предка между вашей проверенной веткой и master .
• Затем он сбрасывает текущую извлеченную ветвь на этого предка, удерживая все последующие фиксации во временной области хранения.
• Затем он продвигает ветвь с текущим извлечением к концу master и воспроизводит фиксации из области хранения после последней фиксации master .

Массовая отмена / повтор

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

Отменить с помощью: git rebase -i <ранний SHA>

Что происходит: -i переводит rebase в «интерактивный режим». Он начинается так же, как описанная выше перебазировка, но перед воспроизведением любых коммитов она приостанавливается и позволяет вам аккуратно изменять каждую фиксацию по мере ее воспроизведения.

rebase -i откроется в текстовом редакторе по умолчанию со списком применяемых коммитов, например:

Первые два столбца являются ключевыми: первая — это выбранная команда для фиксации, идентифицированная SHA во втором столбце. По умолчанию rebase -i предполагает, что каждая фиксация применяется с помощью команды pick .

Чтобы отказаться от фиксации, просто удалите эту строку в своем редакторе. Если вам больше не нужны плохие коммиты в вашем проекте, вы можете удалить строки 1 и 3-4 выше.

Если вы хотите сохранить содержимое фиксации, но отредактировать сообщение фиксации , используйте команду reword . Просто замените слово выберите в первом столбце на слово переделайте (или просто r ). Может возникнуть соблазн переписать сообщение коммита прямо сейчас, но это не сработает — rebase -i игнорирует все, что находится после столбца SHA. Текст после этого просто помогает нам вспомнить, что такое 0835fe2 .Когда вы закончите с rebase -i , вам будет предложено ввести все новые сообщения о фиксации, которые вам нужно написать.

Если вы хотите объединить два коммита вместе, вы можете использовать команды squash или fixup , например:

squash и fixup объединить «вверх» — фиксация с командой «объединить» будет объединена с фиксацией непосредственно перед ней. В этом сценарии 0835fe2 и 6943e85 будут объединены в одну фиксацию, а затем 38f5e4e и af67f82 будут объединены в другую.

Когда вы выбираете squash , Git предложит нам дать новому комбинированному коммиту новое сообщение коммита; Исправление даст новому коммиту сообщение из первого коммита в списке. Здесь вы знаете, что af67f82 является фиксацией «ooops», поэтому вы просто будете использовать сообщение фиксации от 38f5e4e как есть, но вы напишете новое сообщение для новой фиксации, полученной при объединении 0835fe2 и 6943e85 .

Когда вы сохраните и закроете редактор, Git применит ваши коммиты в порядке сверху вниз.Вы можете изменить порядок применения коммитов, изменив порядок коммитов перед сохранением. Если бы вы хотели, вы могли бы объединить af67f82 с 0835fe2 , расположив вещи следующим образом:

Исправить более раннюю фиксацию

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

Отменить с помощью: git commit --squash и git rebase --autosquash -i <еще более ранний SHA>

Что происходит: git commit --squash создаст новую фиксацию с сообщением о фиксации, например squash! Ранее коммит . (Вы можете вручную создать фиксацию с таким сообщением, но commit --squash избавит вас от необходимости печатать.)

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

rebase --autosquash -i запустит интерактивный редактор rebase , но редактор откроется с любым сквошем ! Исправление и ! коммиты уже связаны с целью коммита в списке коммитов, например:

При использовании --squash и --fixup вы можете не вспомнить SHA фиксации, которую хотите исправить — только то, что она была сделана один или пять коммитов назад. — это одна фиксация до HEAD . HEAD ~ 4 — это четыре коммита перед HEAD — или всего пять коммитов назад.

Остановить отслеживание отслеживаемого файла

Сценарий: Вы случайно добавили application.log в репозиторий, теперь каждый раз, когда вы запускаете приложение, Git сообщает о неустановленных изменениях в application.log . Вы поместили * .log в файл .gitignore , но он все еще там — как вы скажете git «отменить» отслеживание изменений в этом файле?

Отменить с помощью: git rm --cached application.журнал

Что происходит: Хотя .gitignore не позволяет Git отслеживать изменения в файлах или даже замечать существование файлов, которые он никогда ранее не отслеживал, после того, как файл был добавлен и зафиксирован, Git продолжит замечать изменения в этом файле. Точно так же, если вы использовали git add -f для «принудительного» или переопределения .gitignore , Git будет отслеживать изменения. 3 上 上 上 一个

git reset HEAD

git reset HEAD 用于 取消 已 缓存 的 内容。

我们 先 改动 文件 README 文件 ， 内容 如下 ：

# Runoob Git 测试
# 菜鸟 教程
 

hello.php 文件 修改 为 ：

现在 两个 文件 修改 后 ， 都 提交 到 了 缓存 区 ， 我们 现在 要 取消 其中 一个 的 缓存 ， 操作 如下 ：

$ git status -s
    M README
    M hello.php
$ git add.$ git status -s
M README
M hello.php
$ git сбросить HEAD hello.php
Неустановленные изменения после сброса:
M hello.php
$ git status -s
M README
    M hello.php
 

你 执行 git commit ， 只会 将 README 文件 的 改动 提交 ， hello.php 是 的。

$ git commit -m '修改'
[master f50cfda] 修改
    1 файл изменен, 1 вставка (+)
$ git status -s
    M hello.php
 

看到 hello.php 文件 的 修改 并未 提交。

这时 我们 可以 使用 以下 命令 将 привет.php 的 修改 提交 ：

$ git commit -am '修改 hello.php 文件'
[master 760f74d] 修改 hello.php 文件
    1 файл изменен, 1 вставка (+)
$ git status
О мастере филиала
ничего не фиксировать, рабочий каталог чист
 

， git reset HEAD 以 取消 之前 git add 添加 ， 但 不 希望 包含 在 下一 中 的 缓存。

Git 基本 操作

狀況 題】 不 小心 使用 hard 模式 Reset 了 某個 Commit ， 救 得 回來 嗎？ — 為 你 自己 學 Git

← 上一章 ： 【狀況】 剛才 ， 想要 拆掉 重做…
下一章 ： 【冷 知識】 ГОЛОВА 是 什麼 東西？ →

借用 一下 上 個 章節 的 例子 ：

  $ git журнал --oneline
e12d8ef (HEAD -> master) добавить базу данных.yml в папке конфигурации
85e7e30 добавить привет
657fce7 добавить контейнер
abb4f43 обновить страницу индекса
cef6e40 создать индексную страницу
cc797cd init коммит
  

共計 有 Commit。 首先 要先 建立 一個 觀念 不管 是 用 什麼 模式 進行 Reset ， Commit 就是 Commit ， 並 不會 因為 Reset 它 然後 就 假設 我們 先 reset 倒退2 步 ：

這 時候 Commit 看起來 就會 少 兩個 ， 同時 拆 出來 的 檔案 會 被 放置 在 工作 目錄 ：

  $ git журнал --oneline
657fce7 (HEAD -> master) добавить контейнер
abb4f43 обновить страницу индекса
cef6e40 создать индексную страницу
cc797cd init коммит
  

退回 Reset 的 這個 步驟 ， Reset 回到 一 開始 Commit 的 SHA-1 e12d8ef 就 行 了 ：

  $ git reset e12d8ef --hard
  

看起來 拆掉 的 Commit 就 又 接 回來 了。 這裡 使用 --hard 參數 可以 強迫 Reset 之後 修改 的 檔案。

使用 Рефлог

: Commit, SHA-1, Git, reflog , 指令 的 保留 一些 紀錄 的 例子 ， 但 --hard 模式 來сброс ：

  $ git reset HEAD ~ 2 --hard
HEAD теперь на 657fce7 добавить контейнер
  

不僅 Фиксация 看起來 不見了 ， 檔案 也 消失 了。 接著 可 使用 reflog 指令 來看 一下 紀錄 ：

  $ git reflog
657fce7 (HEAD -> master) [электронная почта защищена] {0}: reset: переход к HEAD ~ 2
e12d8ef (origin / master, origin / HEAD, cat) [email protected] {1}: checkout: переход от кота к хозяину
e12d8ef (origin / master, origin / HEAD, cat) [email protected] {2}: checkout: переход от мастера к коту
  

當 HEAD 移動 的 時候 （例如 切換 分支 reset 都會 造成 HEAD 移動） ， Git 就會 在 Reflog 裡 的 的 這 三 筆 記錄 大概 可以 最近 三次 HEAD而 最後 的 動作 這次 Reset Reset 的 那個 Commit 」（很像 饒）。 在 這個 例 就是

  $ git reset e12d8ef --hard
  

就 可以 把 аппаратный сброс 的 東西 再次 撿回 來 了。

小 提示

git log 如果 加上 -g 參數 ， 也 可以 看到 Reflog 喔！

← 上一章 ： 【狀況 題】 剛才 的 Commit 後悔 了 ， 想要 拆掉 重做…
下一章 ： 【冷 知識】 ГОЛОВА 是 什麼 東西？ →

Git 总结 — 书

версий 即 用 即 补 ， 一些 常用 的 问题 操作 都 汇总 到 这里 了。

英文 文档
https: // git-scm.com / docs /
https://www.atlassian.com/git/tutorials/

Git 仓库 压缩

  git reflog expire --all --expire = сейчас
git gc --prune = now --aggressive
  

单一 文件 修改 记录

  git log -p test.html

  

删除 文件 ， github 根据 不同 情况 给出 不同 方法 ：

使用 git фильтр-ответвление 或者 BFG Repo-Cleaner

查看 совершить 修改 内容

  git show #CommitID
  

git 删除 本地 未 提交 的 更改
git 有 什么 命令 可以 清除 的 文件

git 处理 冲突
Разрешение конфликта слияния из командной строки

github 官方 提供 例子: 冲突 部分 在 <<< >>> 之间

• <<< 之后 ， === 之前 ， 为 目前 分支 内容
• === 之后 ， >>> 之前 ， 为 待 合并 分支 内容
  接下来 就是 处理 <<< 和 >>> 之间 需要 保留 的 内容 ， 执行 git add -A 保存, 之后 提交 即可。

  количество планет
<<<<<<< ГОЛОВА
девять
=======
8
>>>>>>> ветка - а
  

Git 提交 到 多个 远程 仓库
github-help

  git удаленное добавление источника https: // github.com / * пользователь * / * репо * .git

// 提交 多个 仓库
git push - все
  

запрос на вытягивание 流程
链接 这里

git rp 流程 - 乎

单一 文件 回 退到 某个 本 ：
Сбросить или вернуть конкретный файл к определенной ревизии с помощью Git?

  # Предполагая, что вам нужен коммит abcde
git checkout abcde файл / в / восстановить
  

强制 远程 分支 覆盖 本地 分支
Как заставить команду «git pull» перезаписать локальные файлы?

  git fetch - все
git reset --hard origin / master
git reset --hard origin / ваша_ветка
  

git 标签

  # git 列表
git tag

# 打 标签
git tag v0.1.1

# 补 打 标签
git тег v0.1.1 6224937

# 创建 轻 量 标签 - 轻 量 标签 是 指向 提交 对象 的 引用 (暂时 没用 到)
git тег v0.1.2-свет

# 附注 标签 则 是 仓库 中 的 一个 独立 对象。 建议 使用 附注 标签
git tag -a v0.1.2 -m "Версия 0.1.2"

# 给 指定 的 commit 打 标签 （即 补 打 标签）
git tag -a v0.1.1 9fbc3d0

# 切换 标签
git checkou [тэг]

# 删除 标签
git tag -d v0.1.2

# 删除 远程 标签 (需要 先 删除 本地 标签)
git push origin: ссылки / теги / v0.9

# 标签 发布
git push origin v0.1.2 // 提交 单一 标签
git push origin --tags // 提交 所有 标签

# 查看 标签 内容
git show v1.2.5
  

删除 所有 теги
удалить все теги

  # Удалить локальные теги.git tag -l | xargs git tag -d
# Получить удаленные теги.
git fetch
# Удалить удаленные теги.
git tag -l | xargs -n 1 git push --delete origin
# Удалить локальный файл tasg.
git tag -l | xargs git tag -d
  

替换 某一 分支 内容
git @ Osc 当中 怎么 把 一个 分支 的 内容 替换 另一个 分支 的 内容 呢？

  …… [@Zoker] (http://my.oschina.net/silentboy) 的 答案 确实 能 解决 你 的 问题 ， 但是 你 的 问题 ， 但是 你 本地 的 的 ， 来说 应该 在 本地 做好 修改 再去 нажмите 到 远端 ， 所以 我 推荐 如下 操作
мастер проверки git
git reset --hard develop // 本地 的 master 分支 重置 develop
git push origin master --force // 再推 送到 远程 仓库
  

强行 覆盖 远程 分支 方法

  git push origin master --force
  

git 回滚 远程 本 后 强制 提交

  git push -f
  

安全 方法 见 Git 回滚 远程 本

中文 阮一峰
Git 远程 操作 详解

本地 仓库 名 与 远程 分支 名字 不同 ， 如何 提交
办法 Как я могу легко передать локальную ветку Git на удаленный компьютер с другим именем?
如 不 设置 ， 每次 提交 需要 按照 以下 方式

  // 本地 ： 远程
git push origin ГОЛОВА: liuyk-2016-7-27
  

git 2.0 默认 git push 为 simple
Предупреждение: push.default не задан; его неявное значение изменяется в Git 2.0
Git 2.0 更改 push default 为 ‘simple’

  поток: ‘matching’ 参数 Git 1.x 的 默认 行为 ， 其 意 是 如果 你 git push 但 没有 指定 分支 ， push 所有 你 本地 的 分支 到 远程 中 对应 匹配 的 分支。

просто: 而 Git 2.x 默认 的 是 simple ， 意味着 执行 git push 没有 指定 分支 时 ， 只有 当前 分支 push 到 你 使用 git pull 获取 的 代码。

поток: 只 关联 git pull 本 分支 获取 的 代码 ， 此处 是 解决 办法
  

查看 所有 别名

  git config -l
  

查看 所有 的 alias : Список псевдонимов Git

  $ git config --get-regexp псевдоним
  

取消 工作 区 修改

  git checkout -. 

修改 远程 仓库 地址
修改 仓库 名 后 ， 是否 需要 更改 clone 地址。
官方 的 是 可以 不用 换 但是 还是 强烈 建议 地址
Переименование репозитория

В дополнение к перенаправлению веб-трафика все операции git clone, git fetch или git push, нацеленные на предыдущее местоположение, будут продолжать работать, как если бы они были выполнены в новом местоположении. Однако, чтобы избежать путаницы, мы настоятельно рекомендуем обновить все существующие локальные клоны, чтобы они указывали на новый URL-адрес репозитория. Вы можете сделать это с помощью git remote в командной строке:

  git удаленный источник set-url * new_url *
  

查看 分支 关联

  ветка git -vv
  

本地 新建 分支 与 远程 分支 关联

  git checkout -b release origin / release
  

получить , объединить

  git fetch // 获取 所有 分支 最新
git fetch origin master // 拉 取 远程 origin master 分支 最新
git log -p master..origin / master // 比较 不同
git merge origin / master // 合并
  

单个 文件 修改 记录

 
git log --patch - [имя файла] // 修改 的 内容
// 以上 简写 为
git log -p [имя файла]
git log - [имя файла] // 历史
  

显示 哪些 文件 被 改动

  git log --name-status // 仅 显示 哪些 文件 被 改动
  

恢复 单个 文件 到 某个 记录 节点

  git checkout   // 文件 存入 缓存 区
git commit -m "~~~~"
  

git 初始化 设置, 个人 信息

  git config --global user.name "your_username"
git config --global user.email "[email protected]"

  

初始化 本地 仓库

  git init
  

加载 文件 至 临时 缓存

  git add. // 加载 所有 文件
git add my_file, my_other_file // 制定 文件 夹
  

取消

  git сбросить
  

撤销

  git checkout - имя файла 撤销 提交 // 工作 区 file 文件 的 修改 ， 或者 误 删 也 可以 找回
git checkout filename // 也 可 撤销 文件 在 工作 区 的 修改
git reset HEAD readme.txt // 暂存 区 readme.txt
git reset // 暂存 区 的 修改
  

撤销 工作 区 untrack 文件

  git clean -f [параметры: имя файла] // 直接 撤销 untrack 文件
git clean -nf // 撤销 前 查看 提示
git clean -f xx.txt // 删除 xx.txt 文件

git clean -fd // 文件 夹 一块 撤销 删除
git clean -nfd // 前 查看 提示

  

删除 文件 (不好 用 ， 删除)

  git rm файл
  

创建 切换 分支

  git checkout -b new_feature // 创建 切换 分支
git branch new_feature // 创建 分支
git checkout new_feature // 分支

git checkout -b local_branch origin / remote_branch // 用法 舒服
  

参考 链接 Клонировать все удаленные ветки с помощью Git?

合并 分支, 切换 到 最终 的 分支 ， 然后 执行

  git merge new_feature // 原 new_feature 上 的 内容
  

删除

  git branch -d новая_функция
  

查看

  $ git diff --name-status master 分支..branchName 其他 分支 // 查看 分支 不同
$ [Git] (http://lib.csdn.net/base/28) diff 工作 区 与 提交 任务 （提交 暂存 区 stage） 中 相比 的 差异
$ git diff HEAD 工作 区 和 HEAD （当前 工作 分支） 相比 的 差异
$ git diff --cached （或 --staged） 提交 暂存 区 （提交 任务 ， stage） 和 大本 库 中 文件 的 差异
  

参考 链接 Показывает, какие файлы были изменены между двумя версиями
Git 学习 笔记 （三） Git 暂存 区

回滚

  git журнал // 查看 提交 记录
git log --pretty = oneline // одна строка для отображения журнала
git checkout 085bbxx // 回滚
  

推 送到 远程

  git удаленное добавление источника https: // your_username @ bitbucket.org / your_username / name_of_remote_repository.git // 第 一次
git push origin master
  

别名

  git config --global alias.c 'commit -m'
git config --global alias.c 'commit -m'
git config --global alias.co 'checkout'
git config --global alias.cob 'checkout -b'
git config --global alias.br 'ветка'
git config --global alias.m 'слияние'
git config --global alias.a 'add.'
git config --global alias.s 'status'
git config --global alias.dbr 'ветка -d'
  

， 通过 --global 的 ， 均 在 主 目录 下 有 一个 .

穿梭 到 某个 本

  git reset --hard VersionID
  

查看 之前 纪录

  git reflog
  

删除

  git branch -d [имя-ветки]
  

不同

  # 显示 暂存 区 和 工作 区 的 差异
$ git diff
# 显示 暂存 区 和 上 一个 commit 的 差异
$ git diff --cached [файл]
  

增加 一个 新 的 远程 仓库 （本地 操作 远程）

  # 增加 一个 新 的 远程 仓库 ， 并 命名
$ git удаленное добавление [короткое имя] [URL]
  

远程 仓库 改名

  git удаленное переименование <原 主机 名> <新 主机 名>
  

查找.ssh 文件

  / Пользователи/liwei/.ssh
  

生成 .ssh

  $ ssh-keygen -t rsa -C "[email protected]"
  

本地 连接 远程 空 仓库

  $ git удаленное добавление источника [email protected]: michaelliao / Learngit.git // 关联
$ git push -u origin master // 我们 第 一次 master 分支 时 ， 加上 了 -u 参数 ， Git 不但 会把 本地 的 master 分支 内容 推送 的 远程 新 的 master 分支 ， 还会 把 本地远程 的 master 分支 关联 起来 ， 在 以后 的 推送 或者 拉 取 时 就 可以 简化 命令。
  

查看 远程 库 的 信息

  $ git удаленный
  

新建 远程 分支

  方法: 直接 提交 到 新 分支
git push origin '新 分支 名'
＃ 完整 的 命令 应 如下:
git push origin '本地 分支 名': '远程 分支 名'

＃ 本地 与 远程 关联 ， 这样 以后 直接 输入 git push 即可
git push origin '远程 分支 名'
  

参考 链接 Как создать удаленную ветку Git?

有关 远程 分支 关联 疑问

  ветка git --set-upstream my_branch origin / my_branch
  

链接 Почему мне нужно постоянно выполнять --set-upstream ?

删除 远程 分支

  git push origin: dev // 删除 远程 dev 分支
  

常用

git 代码 库 回滚 - 远程 仓库 分支

远程 分支
git checkout -b [分支 名] [远程 名] / [分支 名]。 如果 你 有 1.6.2 的 的 Git ， 还 可以 用 --track
选项 简化 ：
$ git checkout --track origin / serverfix
Исправление сервера филиала, настроенное для отслеживания исправления сервера удаленного филиала из источника. Переключено на 'serverfix' нового филиала

为 本地 分支 设定 不同于 远程 分支 的 名字 ， 只需 在 第 的本 的 命令 里 换个 名字

  $ git checkout -b sf origin / serverfix
Branch sf настроен для отслеживания удаленного исправления сервера ответвления от источника. Переключен на новую ветку sf
  

git 协作 流程
Git 协作 流程

выпуск на github
выпуск

的 问题
git rest 与 git checkout log 区别
git diff 更多 使用 说明
git pull 和 git fetch 区别, 如何 一次 获得 仓库 的 更新 并 合并

参考 链接
15 学会 使用 Git 和 远程 代码 库
Book
廖雪峰
常用 Git 命令 清单
git 命令 大全

Как сбросить, вернуться и вернуться к предыдущим состояниям в Git

Перейти к навигации

• Войти
• Зарегистрироваться

Форма поиска

Поиск

Главное меню

• Статьи
  • Контейнеры
  • DevOps
  • Игры
  • Правительство
  • Аппаратное обеспечение
    • 3D-печать
    • Arduino
    • Raspberry Pi
  • Kubernetes

  000

  • 000
  • 000 Linux
  • Командная строка
• OpenStack
• Программирование
  • Go
  • JavaScript
  • Python
• SysAdmin