Відкоч коммітів на GitHub

Корисні статті про верстку для верстальників

Квітень 7, 2015

І ось одного разу в репозиторій було внесено зміну, яка потім була закоммічена і відправлена ​​на GitHub. Однак, цієї зміни потрібно позбутися - воно помилкове.

Але як це зробити, якщо коміт вже перебуває на GitHub? В інтерфейсі сервісу GitHub я не знайшов потрібної кнопки, щоб видаляти конкретний коміт і повертати репозиторій до потрібного стану.

Це тому, що керування коммітами на GitHub здійснюється через локальний репозиторій. Нижче наведу три нескладні кроки для того, щоб показати, як це виконується.

Крок перший

Перше – необхідно отримати список hash-сум останніх коммітів репозиторію. Це і зрозуміло – треба мати перед собою дерево коммітів, щоб бачити – куди рухатись. У дереві коммітів hash-суми є опорними точками, ідентифікаційними номерами кожного з коммітів:

Нижче показаний короткий висновок команди git log - чотири найпізніші коміти репозиторію:

Мені потрібно повернути репозиторій зі стану, описаного в коміті ee3a2ae6888fb87d, у стан, зафіксований у коміті 6d92268e42eace0c.

Крок другий

Для цього я скористаюся командою reset, з ключем -hard. Ця команда мені підходить тому, що я не збираюся зберігати зміни, зафіксовані в коміті ee3a2ae6888fb87d , тому що вони помилкові.

Як докладно описується у статті Скасування змін до Git, таке завдання можна виконати командою:

де 6d92268e42eace0c - початкові 16 символів hash-суми комміта, на який я хочу "перестрибнути". Повний вигляд hash-суми в 40 символів можна не використовувати - достатньо 16 символів для надійної ідентифікації конкретного комміту.

Післявиконання цієї команди локальний репозиторій буде скинутий до стану, зафіксованого в коміті 6d92268e42eace0c. Іншими словами, я позбувся останніх помилкових змін і повернув репозиторій до попереднього його стану.

Проте, це лише половина справи, оскільки відкат торкнувся лише локального репозиторію. У цій статті йдеться насамперед про віддалений репозиторій, розміщений на GitHub. Як добитися внесення аналогічних змін на GitHub?

Здавалося б – просто! Достатньо виконати команду:

Але насправді це не вдасться зробити - Git не дозволить це виконати. З тієї причини, що стан локального репозиторію має більш ранню версію, ніж стан віддаленого репозиторію.

Натомість Git запропонує виконати кімнату git pull , щоб привести локальний репозиторій до віддаленого.

Крок третій

Щоб змусити Git виконати обернене завдання - привести віддалений репозиторій до локального, необхідно використовувати ключ -f .

Тобто, форсувати внесення змін і тим самим “сказати” Git – синхронізувати віддалений репозиторій з локальним репозиторієм, незважаючи на те, що останній має більш ранню версію:

Висновок

Тепер, якщо перевірити стан віддаленого репозиторію на сервері GitHub, то побачимо, що воно ідентичне стану локального репозиторію. Але найголовніше - видалено останній помилковий коміт, чого я й домагався.

---