Revert commit android studio

Как отменить commit и не облажаться

Не только разработчикам-новичкам, но и ярым профессионалам приходится прибегать к отмене каких-либо изменений. И тогда, первое, что приходит на ум, — это команда git revert , как самый безопасный способ. И тут есть подводные камни, про которые я хочу рассказать.

Возьмем простую ситуацию: разработчик решает реализовать математические функции. Но на половине пути понимает, что данную задачу было бы хорошо декомпозировать, допустим, на две подзадачи:

• Реализовать арифметические операции (сложение, вычитание, деление и т.д.)
• Реализовать числовые операции (максимальное значение, минимальное значение, модуль числа и т.д.)

Проверять будет проще да и тестировать. Но он уже начал ее реализовывать, коммиты уже созданы, и что же делать? Не переписывать же!

Рассмотрим дерево коммитов. Видим, что наш разработчик создал ветку functions , класс Arithmetic, отвечающий за реализацию арифметических операций (коммит А), и класс Numerical, отвечающий за реализацию числовых операций (коммит N). Итого два класса и два коммита.

git revert

Решено, дабы ничего не переписывать, наследоваться от functions и создать две ветки numerical и arithmetic . И соответственно отменить ненужные коммиты. То есть выполнить git revert N в ветке arithmetic и git revert A в ветке numerical. Гениально и просто!

Работа кипит и осталось дело за малым — смерджить мастер с данными ветками.

И что же мы получили? Ни класса Arithmetic, ни класса Numerical!
А все дело в том, что команда git revert создает новый коммит с отменой изменений и не удаляет из истории коммиты. И в нашем случае после слияния веток получается 4 коммита:

То есть вариант с отменой изменений с помощью команды revert вышел нам боком.

git reset

И тут мы вспоминаем, что есть такая команда как reset , вот она в отличии от revert точно удаляет коммиты из истории. Но есть одно НО… она сбрасывает все коммиты до указанного. Такое поведение нам не подходит, так как мы хотим выбрать какие коммиты удалить.

git rebase

Есть еще одно решение — использовать команду git rebase для отмены изменений.
Вернемся к моменту создания двух веток numerical и arithmetic и выполним

Теперь на уровне каждого коммита, который мы хотим отменить заменим pick на drop. И тогда выбранные нами коммиты сбросятся из истории. Например в ветке numerical :

Тогда в истории у нас останутся только нужные нам коммиты.
Теперь при слиянии веток в master получим оба класса.

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

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

Источник

Полезные команды Git: безопасная отмена коммитов, добавление файла из другой ветки и другие

Авторизуйтесь

Полезные команды Git: безопасная отмена коммитов, добавление файла из другой ветки и другие

Git — это мощный, хотя и незамысловато выглядящий, инструмент, который при неосторожном использовании может устроить большой беспорядок. Поэтому, прежде чем пробовать выполнять различные фокусы с Git, я рекомендую ознакомиться с его основными командами (init, clone, push, pull, status, log и т.д.) и концептами (репозиторий, ветвь, коммит, и т.д.).

Итак, если вы уверенно чувствуете себя при работе с Git, вот несколько полезных трюков, о которых я знаю.

Reflog. Отмена операций

Я помню, что в начале знакомства с Git я боялся запускать команды. Я думал, что всё испорчу. Например, первое использование git rebase вызвало у меня несколько восклицаний наподобие «Вот *****! Что я только что сделал?!» из-за дублировавшихся или вообще исчезнувших коммитов. Вскоре после этого я понял, что нужно идти дальше.

Лично я не люблю использовать инструмент, не зная, что именно он делает для достижения результата. Это как вождение машины без руля: всё прекрасно до тех пор, пока не доедешь до поворота. А что потом? Ну, вы меня поняли.

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

Relictum Pro , Москва , От 200 000 ₽

Используя reflog , вы можете вернуться в прошлое, отменяя почти любые действия, сделанные в Git. Даже если это были rebase или reset . Кроме того, её легко использовать. Чтобы доказать это, приведу маленький пример.

Чтобы изменить нужное состояние, нужно запустить checkout , используя абсолютную ссылку:

или относительную ссылку:

и вы окажетесь в независимом (detached) состоянии HEAD, из которого можно создать новую ветвь.

Вот и всё. Все операции после вышеуказанного состояния отменены.

Revert. Отмена изменений коммита

Вы, должно быть, сталкивались с ситуацией, когда вам нужно было отменить некоторые изменения. На помощь придёт команда revert :

Что она делает? Она просто отменяет действия прошлых коммитов, создавая новый, содержащий все отменённые изменения. Зачем использовать её вместо других решений? Это — единственный безопасный способ, так как он не изменяет историю коммитов. Он обычно используется в публичных ветвях, где изменение истории нежелательно.

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

Rebase

Вы можете выполнить эту команду и просто убрать строки, относящиеся к ненужным коммитам. Это самое очевидное и простое решение, но у него есть недостаток, из-за которого его нельзя использовать в публичных ветвях: он изменяет историю коммитов. Поэтому после rebase’а у вас может возникнуть проблема с push’ем.

Reset

Эта команда удаляет все коммиты выше указанного. Она лучше предыдущей тем, что не добавляет новую информацию в историю, но тем не менее тоже ее меняет.

Checkout

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

Вывод таков, что git revert — самая безопасная операция для отмены действий. Кроме того, нужно заметить, что эти команды не взаимозаменяемы в 100% случаев.

Log. Более приятное форматирование

С git log всё просто. Вы вводите команду и видите историю коммитов в хронологическом порядке, и каждый пункт включает в себя хэш коммита, автора, дату и прикреплённое сообщение.

Давайте взглянем на вид лога по умолчанию:

Я думаю, что могло бы быть и лучше.

Я предпочитаю простые вещи. Поэтому я использую две опции:

• —oneline – показывает каждый коммит в одной строке. Кроме того, она показывает лишь префикс ID коммита.
• —decorate – печатает все относительные имена показанных коммитов.

Вот как это выглядит:

Опция —oneline сокращает количество занятых строк, а опция —decorate добавляет относительные имена (локальные/удалённые ветви + HEAD). Используя эти две опции, мы получаем более компактный и осмысленный git log . Да, мы теряем некоторые вещи, но они не особо важны. Так гораздо лучше, да?

Тем не менее, иногда нам нужно знать дату и автора коммита. В таких случаях я использую следующее:

Ничего себе! Давайте посмотрим, как это выглядит:

И всё-таки вводить эти команды каждый раз достаточно неудобно, так? Давайте создадим алиасы. Я считаю, что использование алиасов очень сильно повышает продуктивность. Чтобы зарегистрировать их, добавим следующие строки в «

/.bash_profile» (конечно, если вы используете *nix OS):

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

Еще один вариант украшения вывода лога приведен в этой статье.

Diff. Разница между коммитами

Простая команда, показывающая изменения между объектами в проекте — git diff . Один из основных сценариев её использования — сравнение двух коммитов:

Другой — вывод всех изменений, не внесённых в индекс. Для этого нужно выполнить следующее:

Branch. Проверка ветвей на слияние

Я думаю, вы уже знаете, что делает базовая команда git branch (без опций выводит список локальных веток — прим. перев.), поэтому перейдём к делу. Время от времени вам понадобится удалять старые или ненужные ветви из вашего «дерева» git.

вы получите список всех веток, соединённых с текущей.

Можно и наоборот:

Так вы получите список всех не соединённых с текущей веток.

Таким образом, вы всегда узнаете, безопасно ли удаление той или иной ветви.

Checkout. Получение файла из другой ветви

Вам наверняка приходилось искать конкретную версию файла, которая была в другой, ещё не присоединённой ветви. Помните команду checkout , приведённую выше? Она выглядит так:

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

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

Источник

Отмена коммитов — Введение в Git

Гит — система, в которой не нужно бояться совершать ошибки. Можно сказать, что это единственный способ научиться им пользоваться. В git практически всегда есть способ восстановить или изменить любые коммиты. На крайний случай спасет повторный git clone .

Что делать, если коммит уже сделан, но он нас по каким-то причинам не устраивает? Ситуаций может быть много, и все они возникают регулярно даже у профессиональных разработчиков:

• Забыли добавить в коммит нужные файлы
• Изменения нужно «откатить», чтобы доработать
• Изменения больше не актуальны, и их нужно удалить
• Изменения были сделаны по ошибке, и их нужно отменить

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

Несмотря на сказанное выше, внутри git существуют специальные команды, позволяющие упростить отмену, либо изменение коммита. С их помощью можно сделать историю коммитов понятной, а сам процесс «отката» быстрым.

Git revert

Самая простая ситуация — отмена изменений. Фактически она сводится к созданию ещё одного коммита, который выполняет изменения противоположные тому коммиту, который отменяется. Руками создавать подобный коммит довольно сложно, поэтому в git добавили команду, автоматизирующую откат. Эта команда называется git revert :

Команда revert может «отменять» не только последний коммит, но и любой другой коммит из истории проекта. Согласитесь, это очень круто. Без системы контроля версий о таком нельзя было и мечтать.

Git reset

Иногда удалить нужно только что сделанный по ошибке коммит. Конечно, и в этом случае подходит git revert , но так загрязняется история. Если этот коммит сделан был только сейчас и ещё не отправлялся на Github, то лучше сделать так, как будто бы этого коммита не существовало в принципе.

Git позволяет удалять коммиты. Это опасная операция, которую нужно делать только в том случае, если речь идет про новые коммиты, которых нет ни у кого, кроме вас.

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

Для удаления коммита используется команда git reset . Делается это так:

git reset — мощная команда, имеющая множество различных флагов и способов работы. С её помощью удаляются или отменяются (без удаления) коммиты, восстанавливаются файлы из истории и так далее. Работа с ней относится к продвинутому использованию git, здесь же мы затрагиваем только самую базу.

Флаг —hard означает полное удаление. Без него git reset отменит коммит, но не удалит его, а поместит все изменения этого коммита в рабочую директорию, так что с ними можно будет продолжить работать. HEAD

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

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

Если не указывать флаг —hard , то по умолчанию подразумевается флаг —mixed . В таком варианте reset отправляет изменения последнего коммита в рабочую директорию. Затем их можно исправить или отменить и выполнить новый коммит.

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

Самостоятельная работа

1. Выполните все шаги из урока
2. Измените добавленный текст на No code No pain и закоммитьте его с сообщением «update README.md»
3. Залейте изменения на Github

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты.

Нашли опечатку или неточность?

Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.

Что-то не получается или материал кажется сложным?

Загляните в раздел «Обсуждение»:

• задайте вопрос. Вы быстрее справитесь с трудностями и прокачаете навык постановки правильных вопросов, что пригодится и в учёбе, и в работе программистом;
• расскажите о своих впечатлениях. Если курс слишком сложный, подробный отзыв поможет нам сделать его лучше;
• изучите вопросы других учеников и ответы на них. Это база знаний, которой можно и нужно пользоваться.

Об обучении на Хекслете

• Статья «Как учиться и справляться с негативными мыслями»
• Статья «Ловушки обучения»
• Статья «Сложные простые задачи по программированию»
• Урок «Как эффективно учиться на Хекслете»
• Вебинар «Как самостоятельно учиться»

Открыть доступ

Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.

• 120 курсов, 2000+ часов теории
• 900 практических заданий в браузере
• 360 000 студентов

Наши выпускники работают в компаниях:

С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.

Источник