17. Видалення комміттов з гілки

Цілі

  • Навчитися видаляти найостанніші коміти з гілки

Revert з попереднього розділу є потужною командою, яка дозволяє скасувати будь-які коміти у репозиторій. Однак, і оригінальний і «скасований» коміти видно в історії гілки (при використанні команди git log).

Часто ми робимо коміт, і відразу розуміємо, що це була помилка. Було б непогано мати команду «повернення», яка дозволила б нам зробити вигляд, що неправильного коміту ніколи й не було. Команда «повернення» навіть запобігла б появі небажаного коміту в історії git log.

01 Команда reset

Ми вже бачили команду reset і використовували її для узгодження буферної зони і вибраного коміту (ми використовували коміт HEAD у нашому попередньому уроці).

При отриманні посилання на коміт (тобто хеш, гілка або ім'я тега), команда reset

  1. перепише поточну гілку, щоб вона вказувала на потрібний коміт
  2. опціонально скине буферну зону для відповідності із зазначеним комітом
  3. опціонально скине робочий каталог для відповідності із зазначеним комітом

02 Перевірте нашу історію

Давайте зробимо швидку перевірку нашої історії коммітов.

Виконайте:

git hist

Результат:

$ git hist
* 45fa96b 2011-03-09 | Revert "Oops, we didn't want this commit" (HEAD, master) [Alexander Shvets]
* 846b90c 2011-03-09 | Oops, we didn't want this commit [Alexander Shvets]
* fa3c141 2011-03-09 | Added HTML header (v1) [Alexander Shvets]
* 8c32287 2011-03-09 | Added standard HTML page tags (v1-beta) [Alexander Shvets]
* 43628f7 2011-03-09 | Added h1 tag [Alexander Shvets]
* 911e8c9 2011-03-09 | First Commit [Alexander Shvets]

Ми бачимо, що два останніх коммітов в цій гілці - «Oops» і «Revert Oops». Давайте видалимо їх за допомогою скидання.

03 Для початку позначте цю гілку

Але перш ніж видалити коміт, давайте позначимо останній коміт тегом, щоб потім можна було його знайти.

Виконайте:

git tag oops

04 Скидання коммітов до попередніх коммітов Oops

Дивлячись на історію логу (див. вище), ми бачимо, що коміт з тегом «v1» є комітом, попереднім до помилкового коміту. Давайте скинемо гілку до цієї точки. Оскільки гілка має тег, ми можемо використовувати ім'я тегу в команді скидання (якщо вона не має тега, ми можемо використовувати хеш-значення).

Виконайте:

git reset --hard v1
git hist

Результат:

$ git reset --hard v1
HEAD is now at fa3c141 Added HTML header
$ git hist
* fa3c141 2011-03-09 | Added HTML header (HEAD, v1, master) [Alexander Shvets]
* 8c32287 2011-03-09 | Added standard HTML page tags (v1-beta) [Alexander Shvets]
* 43628f7 2011-03-09 | Added h1 tag [Alexander Shvets]
* 911e8c9 2011-03-09 | First Commit [Alexander Shvets]

Наша гілка master тепер вказує на Комміт v1, а коммітов Oops і Revert Oops в гілці вже немає. Параметр --hard вказує, що робочий каталог повинен бути оновлений відповідно до нового head гілки.

05 Нічого ніколи не губиться

Що ж трапляється з помилковими комітами? Виявляється, що коміти все ще знаходяться в репозиторію. Насправді, ми все ще можемо на них посилатися. Пам'ятаєте, на початку цього уроку ми створили для скасованого коміту тег «oops». Давайте подивимося на всі коміти.

Виконайте:

git hist --all

Результат:

$ git hist --all
* 45fa96b 2011-03-09 | Revert "Oops, we didn't want this commit" (oops) [Alexander Shvets]
* 846b90c 2011-03-09 | Oops, we didn't want this commit [Alexander Shvets]
* fa3c141 2011-03-09 | Added HTML header (HEAD, v1, master) [Alexander Shvets]
* 8c32287 2011-03-09 | Added standard HTML page tags (v1-beta) [Alexander Shvets]
* 43628f7 2011-03-09 | Added h1 tag [Alexander Shvets]
* 911e8c9 2011-03-09 | First Commit [Alexander Shvets]

Ми бачимо, що помилкові коміти не зникли. Вони все ще знаходяться в репозиторію. Просто вони відсутні в гілці master . Якби ми не позначили їх тегами, вони як і раніше перебували б у репозиторію, але не було б ніякої можливості посилатися на них, окрім як за допомогою їх хеш імен. Коміти, на які немає посилань, залишаються в репозиторії до тих пір, поки не буде запущений збирач сміття.

06 Небезпека скидання

Скидання в локальних гілках, як правило, безпечний. Наслідки будь-який «аварії», як правило, можна відновити простим скиданням за допомогою потрібного коміту.

Однак, якщо гілку «розшарено» на віддалені репозиторії, скидання може збити з пантелику інших користувачів гілки.