Предыдущий ролик Следующий ролик  

Видео урок: Получение старых версий

Git: обучение основам

В предыдущем ролике мы рассмотрели, как использовать опцию amend с коммитом, чтобы отредактировать самый последний коммит, коммит, на который указывает HEAD. Мы также видели, насколько это сложно - менять более старые коммиты, поскольку это идет в разрез с интеграцией данных, что является важной чертой в Git. Вместо этого, если нам нужно внести изменения в более старые коммиты, лучше всего сделать новые коммиты. Коммиты, которые отменяют то, чтобы было сделано в более старых. Не только это поддерживает связанность данных в Git, также и файл с логами отображает изменения, которые были сделаны. В нем показано, что было сделано изменение 1.1, а затем, несколькими коммитами позже, был сделан другой коммит.

Эта информация, на самом деле, может иметь некоторую важность, особенно если коммиты каким-то образом касаются этих изменений. Что Git нам не позволяет, так это прятать наши ошибки. Вместо этого вы записываете сделанную ошибку, а затем записываете исправление, которое идет вместе с ней. Есть много способов написать новые коммиты, которые отменяют сделанные изменения. Один заключается в том, что мы можем вручную сделать эти изменения, как мы и делали в первое время, а затем закоммитить результат. Но я хочу вам показать другой способ, и он немного быстрее.

Давайте взглянем на наш git log, и давайте посмотрим на последний коммит, который мы сделали. Мы можем просто использовать amend, чтобы отредактировать этот коммит. Но это тот коммит, когда мы меняли файл resources.html. Мы реорганизуем элементы, которые здесь перечислены. Допустим, мы сделали два или три коммита с тех пор, и мы хотим вернуться, переработать этот файл и вернуть его назад в старое состояние. Что мы сможем сделать, так это чекаут этого файла. Сделаем чекаут старой версии resources.html до того, как были сделаны изменения.

Таким образом, если изменение было сделано в этом коммите, тогда коммит предыдущей версии, нежели эта, является нужной нам версией, и возможно, иногда нам нужны какие-то более ранние версии. Но мы возьмем эту, которая идет непосредственно перед последней. Я копирую часть этого S-H-A. Вы можете взять весь номер, но это необязательно, эти числа довольно уникальны, так что вы можете взять только, например, первые 10, скопировать их и использовать для ссылки. А затем пишем git checkout, я использую ссылку на нужный коммит, затем два дефиса, и это те два дефиса, которые мы использовали ранее с чекаутом, чтобы Git знал, что мы не говорим о бранчах, а имеем в виду текущий бранч. Затем нужный файл, resources.html.

Таким образом, я сказал ему, сделать чекаут этого. Давайте посмотрим на git status, и вы увидите, что Git переместил его в буфер. Я сделал чекаут, и теперь его можно закоммитить. Это поведение немного другое. Ранее, когда я делал чекаут, Git выставлял мою рабочую директорию. Здесь он выставляет буфер. Если мы делаем чекаут из какой-то предыдущей ревизии, Git вставляет его в буфер. Теперь, если мы напишем git diff staged, мы можем увидеть сравнение. Мы видим, что это старый файл, старая версия, и если бы нам нужно было ее закоммитить, эти изменения были бы возвращены.

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

Так что другие люди могут посмотреть и понять, что именно вы пытались вернуть. Мы можем закоммитить это, но вместо этого я хочу снова посмотреть статус. Давайте напишем git reset HEAD для resources.html. Таким образом, он вернется в рабочую директорию, а затем мы пишем git check out дефис дефис resources.html. Вот он удаляется из нашей рабочей директории, так что теперь наша рабочая директория чиста. А причина того, что сейчас я не хочу этого делать, состоит в том, что в следующем ролике я покажу вам команду git revert, которая делает что-то очень похожее.