Отмена коммитов — Введение в Git
Что делать, если коммит уже сделан, но он нас по каким-то причинам не устраивает? Ситуаций может быть много, и все они возникают регулярно даже у профессиональных разработчиков:
Git по большей части система «только вперёд». Правильный подход при работе с гитом — создание нового, а не изменение старого. Все ситуации, описанные выше, можно решить новым коммитом, изменяющим код в нужном направлении. Это не только удобно, но и безопасно. Изменение истории коммитов — операция опасная и чревата проблемами при синхронизации с удалёнными репозиториями. Об этом мы поговорим позже.
Несмотря на сказанное выше, внутри git существуют специальные команды, позволяющие упростить отмену, либо изменение коммита. С их помощью можно сделать историю коммитов понятной, а сам процесс «отката» быстрым.
Git revert
Самая простая ситуация — отмена изменений. Фактически она сводится к созданию ещё одного коммита, который выполняет изменения противоположные тому коммиту, который отменяется. Руками создавать подобный коммит довольно сложно, поэтому в git добавили команду, автоматизирующую откат. Эта команда называется git revert :
Команда revert может «отменять» не только последний коммит, но и любой другой коммит из истории проекта. Согласитесь, это очень круто. Без системы контроля версий о таком нельзя было и мечтать.
Git reset
Git позволяет удалять коммиты. Это опасная операция, которую нужно делать только в том случае, если речь идет про новые коммиты, которых нет ни у кого, кроме вас.
Если коммит был отправлен во внешний репозиторий, например, на Github, то менять историю ни в коем случае нельзя, это сломает работу у тех, кто работает с вами над проектом.
git reset — мощная команда, имеющая множество различных флагов и способов работы. С её помощью удаляются или отменяются (без удаления) коммиты, восстанавливаются файлы из истории и так далее. Работа с ней относится к продвинутому использованию git, здесь же мы затрагиваем только самую базу.
означает «один коммит от последнего коммита». Если бы мы хотели удалить два последних коммита, то могли бы написать HEAD
HEAD (голова) — так обозначается последний сделанный коммит. Подробнее эту терминологию мы разберем в уроке, посвященном внутреннему устройству git.
Последнего коммита больше не существует, но изменения, сделанные в нём, не пропали. Они находятся в рабочей директории для дальнейшей доработки.
Самостоятельная работа
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты.
Нашли опечатку или неточность?
Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.
Что-то не получается или материал кажется сложным?
Загляните в раздел «Обсуждение»:
Об обучении на Хекслете
Открыть доступ
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.
Наши выпускники работают в компаниях:
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
git revert
Можно сказать, что команда git revert представляет собой типичную команду отмены. Однако принцип ее действия отличается от привычной отмены изменений. Вместо удаления коммита из истории проекта эта команда отменяет внесенные в нем изменения и добавляет новый коммит с полученным содержимым. В результате история в Git не теряется, что важно для обеспечения целостной истории версий и надежной совместной работы.
Отмена с помощью команды revert необходима, когда нужно обратить изменения, внесенные в некоем коммите из истории проекта. Это может быть полезно, если баг появился в проекте из-за конкретного коммита. Вам не потребуется вручную переходить к этому коммиту, исправлять его и выполнять коммит нового снимка состояния — команда git revert сделает это автоматически.
.svg)
Порядок действий
Для наглядности создадим тестовый репозиторий и напишем в командной строке следующее:
Обратите внимание, что после операции отмены третий коммит по-прежнему содержится в истории проекта. Вместо его удаления команда git revert добавила новый коммит для отмены изменений. В результате второй и четвертый коммиты представляют собой одну и ту же базу кода, а третий коммит хранится в истории на случай, если в дальнейшем нам понадобится к нему вернуться.
Распространенные опции
Это параметр по умолчанию, указывать его необязательно. Он открывает настроенный системный редактор, в котором вам будет предложено изменить комментарий к коммиту перед выполнением отмены
Разница между командами git reset и git revert
Важно понимать, что команда git revert отменяет одиночный коммит, но не возвращает проект в предшествовавшее состояние с удалением всех последующих коммитов. Такой результат в Git дает команда reset, а не revert.
.svg)
У команды revert есть два серьезных преимущества перед командой reset. Во-первых, она не изменяет историю проекта и, соответственно, безопасна для коммитов, которые уже опубликованы в общем репозитории. Подробнее о том, почему изменять общую историю опасно, см. на странице команды git reset.
Резюме
Готовы изучить команду git revert?
Ознакомьтесь с этим интерактивным обучающим руководством.
Полезные команды Git: безопасная отмена коммитов, добавление файла из другой ветки и другие
Авторизуйтесь
Полезные команды Git: безопасная отмена коммитов, добавление файла из другой ветки и другие
Git — это мощный, хотя и незамысловато выглядящий, инструмент, который при неосторожном использовании может устроить большой беспорядок. Поэтому, прежде чем пробовать выполнять различные фокусы с Git, я рекомендую ознакомиться с его основными командами (init, clone, push, pull, status, log и т.д.) и концептами (репозиторий, ветвь, коммит, и т.д.).
Итак, если вы уверенно чувствуете себя при работе с Git, вот несколько полезных трюков, о которых я знаю.
Reflog. Отмена операций
Я помню, что в начале знакомства с Git я боялся запускать команды. Я думал, что всё испорчу. Например, первое использование git rebase вызвало у меня несколько восклицаний наподобие «Вот *****! Что я только что сделал?!» из-за дублировавшихся или вообще исчезнувших коммитов. Вскоре после этого я понял, что нужно идти дальше.
Лично я не люблю использовать инструмент, не зная, что именно он делает для достижения результата. Это как вождение машины без руля: всё прекрасно до тех пор, пока не доедешь до поворота. А что потом? Ну, вы меня поняли.
или относительную ссылку:
и вы окажетесь в независимом (detached) состоянии HEAD, из которого можно создать новую ветвь.
Вот и всё. Все операции после вышеуказанного состояния отменены.
Revert. Отмена изменений коммита
Вы, должно быть, сталкивались с ситуацией, когда вам нужно было отменить некоторые изменения. На помощь придёт команда revert :
Что она делает? Она просто отменяет действия прошлых коммитов, создавая новый, содержащий все отменённые изменения. Зачем использовать её вместо других решений? Это — единственный безопасный способ, так как он не изменяет историю коммитов. Он обычно используется в публичных ветвях, где изменение истории нежелательно.
Давайте взглянем на другие команды, способные отменять действия.
Rebase
Вы можете выполнить эту команду и просто убрать строки, относящиеся к ненужным коммитам. Это самое очевидное и простое решение, но у него есть недостаток, из-за которого его нельзя использовать в публичных ветвях: он изменяет историю коммитов. Поэтому после rebase’а у вас может возникнуть проблема с push’ем.
Reset
Эта команда удаляет все коммиты выше указанного. Она лучше предыдущей тем, что не добавляет новую информацию в историю, но тем не менее тоже ее меняет.
Checkout
Эта команда откатывает выбранный файл к состоянию в более ранней версии указанного коммита. Отменённые изменения будут в рабочей директории, и их можно будет закоммитить как угодно.
Вывод таков, что git revert — самая безопасная операция для отмены действий. Кроме того, нужно заметить, что эти команды не взаимозаменяемы в 100% случаев.
Log. Более приятное форматирование
С git log всё просто. Вы вводите команду и видите историю коммитов в хронологическом порядке, и каждый пункт включает в себя хэш коммита, автора, дату и прикреплённое сообщение.
Давайте взглянем на вид лога по умолчанию:
Я думаю, что могло бы быть и лучше.
Я предпочитаю простые вещи. Поэтому я использую две опции:
Вот как это выглядит:
Тем не менее, иногда нам нужно знать дату и автора коммита. В таких случаях я использую следующее:
Ничего себе! Давайте посмотрим, как это выглядит:
И всё-таки вводить эти команды каждый раз достаточно неудобно, так? Давайте создадим алиасы. Я считаю, что использование алиасов очень сильно повышает продуктивность. Чтобы зарегистрировать их, добавим следующие строки в «
/.bash_profile» (конечно, если вы используете *nix OS):
Еще один вариант украшения вывода лога приведен в этой статье.
Diff. Разница между коммитами
Другой — вывод всех изменений, не внесённых в индекс. Для этого нужно выполнить следующее:
Branch. Проверка ветвей на слияние
Я думаю, вы уже знаете, что делает базовая команда git branch (без опций выводит список локальных веток — прим. перев.), поэтому перейдём к делу. Время от времени вам понадобится удалять старые или ненужные ветви из вашего «дерева» git.
вы получите список всех веток, соединённых с текущей.
Так вы получите список всех не соединённых с текущей веток.
Таким образом, вы всегда узнаете, безопасно ли удаление той или иной ветви.
Checkout. Получение файла из другой ветви
Указанный файл будет приведен к версии, указанной в заданном коммите. Раньше мы использовали это для отмены изменений файла. Удобно то, что этот коммит необязательно должен находиться в той же ветви, что и наш файл. Поэтому мы можем задать любому файлу любую версию из любого коммита или ветви.
Надеюсь, вы нашли здесь для себя что-то полезное. Прошу заметить, что все вышеуказанные моменты субъективны, поскольку я подгонял их под свои нужды.
Что такое Git?
Git — абсолютный лидер по популярности среди современных систем управления версиями. Это развитый проект с активной поддержкой и открытым исходным кодом. Система Git была изначально разработана в 2005 году Линусом Торвальдсом — создателем ядра операционной системы Linux. Git применяется для управления версиями в рамках колоссального количества проектов по разработке ПО, как коммерческих, так и с открытым исходным кодом. Система используется множеством профессиональных разработчиков программного обеспечения. Она превосходно работает под управлением различных операционных систем и может применяться со множеством интегрированных сред разработки (IDE).
Git — система управления версиями с распределенной архитектурой. В отличие от некогда популярных систем вроде CVS и Subversion (SVN), где полная история версий проекта доступна лишь в одном месте, в Git каждая рабочая копия кода сама по себе является репозиторием. Это позволяет всем разработчикам хранить историю изменений в полном объеме.
Разработка в Git ориентирована на обеспечение высокой производительности, безопасности и гибкости распределенной системы.
Производительность
Git показывает очень высокую производительность в сравнении со множеством альтернатив. Это возможно благодаря оптимизации процедур фиксации коммитов, создания веток, слияния и сравнения предыдущих версий. Алгоритмы Git разработаны с учетом глубокого знания атрибутов, характерных для реальных деревьев файлов исходного кода, а также типичной динамики их изменений и последовательностей доступа.
Некоторые системы управления версиями руководствуются именами файлов при работе с деревом файлов и ведении истории версий. Вместо обработки названий система Git анализирует содержимое. Это важно, поскольку файлы исходного кода часто переименовывают, разделяют и меняют местами. Объектные файлы репозитория Git формируются с помощью дельта‑кодирования (фиксации отличий содержимого) и компрессии. Кроме того, такие файлы в чистом виде хранят объекты с содержимым каталога и метаданными версий.
Вместе с тем распределенная архитектура системы сама по себе обеспечивает существенный прирост производительности.
Рассмотрим пример: разработчик Элис меняет исходный код. Она добавляет функцию для будущей версии 2.0, после чего делает коммит и сопровождает изменения описанием. Затем она разрабатывает другую функцию и делает еще один коммит. Разумеется, эти изменения сохраняются в истории в виде отдельных рабочих элементов. Затем Элис переключается на ветку, соответствующую версии 1.3 того же ПО — так она сможет исправить баг, затрагивающий эту конкретную версию. Это нужно, чтобы команда Элис могла выпустить версию 1.3.1 с исправлениями до завершения работы над версией 2.0. Затем Элис вернется к ветке для версии 2.0 и продолжит работу над соответствующими функциями. Все перечисленные действия можно выполнить без доступа к сети, поэтому система Git отличается быстротой и надежностью, даже если работать в самолете. Когда Элис будет готова отправить все внесенные изменения в удаленный репозиторий, ей останется лишь выполнить команду push.
Безопасность
При разработке в Git прежде всего обеспечивается целостность исходного кода под управлением системы. Содержимое файлов, а также объекты репозитория, фиксирующие взаимосвязи между файлами, каталогами, версиями, тегами и коммитами, защищены при помощи криптографически стойкого алгоритма хеширования SHA1. Он защищает код и историю изменений от случайных и злонамеренных модификаций, а также позволяет проследить историю в полном объеме.
Использование Git гарантирует подлинность истории изменений исходного кода.
В некоторых других системах управления версиями отсутствует защита от тайного внесения изменений. Это может стать серьезной угрозой информационной безопасности в любой организации, занимающейся разработкой ПО.
Гибкость
Гибкость — одна из основных характеристик Git. Она проявляется в поддержке различных нелинейных циклов разработки, эффективности использования с малыми и крупными проектами, а также совместимости со многими системами и протоколами.
В отличие от SVN, система Git рассчитана прежде всего на создание веток и использование тегов. Поэтому процедуры с участием веток и тегов (например, объединение и возврат к предыдущей версии) сохраняются в истории изменений. Не все системы управления версиями обладают настолько широкими возможностями отслеживания.
Контроль версий с помощью Git
Git — это лучшее решение для большинства команд разработки ПО. Разумеется, оценку следует проводить с учетом конкретных требований. Мы лишь хотим перечислить основные причины, по которым команды предпочитают использовать Git.
Превосходные характеристики
Функциональность, производительность, безопасность и гибкость Git удовлетворяют требованиям большинства команд и разработчиков. Эти качества системы подробно описаны выше. При сравнении системы с большинством альтернатив многие команды приходят к выводу, что Git обладает значительными преимуществами.
Git — признанный стандарт
Git является самым популярным инструментом своего класса и поэтому привлекателен по ряду причин. В Atlassian управление исходным кодом проектов практически всегда осуществляется в Git.
Великое множество профессиональных разработчиков уже получили опыт использования Git, а выпускники высших учебных заведений зачастую знакомы только с этой системой. В некоторых организациях работникам требуется обучение при переходе на Git с других систем управления версиями, однако многие разработчики (как штатные, так будущие сотрудники) уже обладают необходимыми знаниями.
Однако привлекательность Git обусловлена не только высокой популярностью среди разработчиков. В системе также предусмотрена интеграция различных инструментов и сервисов, включая интегрированные среды разработки и собственные инструменты Atlassian. В число последних входит настольный клиент для распределенных систем управления версиями Sourcetree, система отслеживания задач и проектов Jira, а также сервис размещения кода Bitbucket.
Начинающим разработчикам, которые хотят приобрести ценные навыки работы с инструментами разработки ПО, следует изучить Git как одну из систем управления версиями.
Git — это качественный проект с открытым кодом
Проект Git имеет открытый исходный код, а также активно поддерживается и непрерывно развивается уже более 10 лет. Кураторы проекта продемонстрировали взвешенный и продуманный подход к выполнению требований пользователей, регулярно выпуская релизы для повышения удобства и расширения функциональных возможностей системы. Качество ПО с открытым исходным кодом легко проверяется, и многие организации всецело доверяют таким продуктам.
Вокруг Git сформировалось многочисленное сообщество пользователей, а сам проект получает активную поддержку со стороны сообщества. Система обладает подробной и качественной документацией: всем желающим в числе прочего доступны книги, учебные руководства, специализированные веб‑сайты, подкасты и обучающие видеоролики.
Git — это система с открытым исходным кодом, поэтому разработчики‑любители могут пользоваться ей совершенно бесплатно. В сфере разработки ПО с открытым исходным кодом Git определенно выступает главным преемником успешных систем управления версиями предыдущих поколений, таких как SVN и CVS.
Критика Git
Git нередко критикуют за сложность освоения: одни термины могут быть незнакомы новичкам, а другие — иметь иное значение. Так, понятие revert (возврат к предыдущей версии) в Git имеет другой смысл, нежели в SVN и CVS. Тем не менее Git — очень мощная система, предлагающая пользователям широкие возможности. Их изучение займет какое‑то время, однако усвоенные навыки помогут участникам команды работать намного быстрее.
Команды, перешедшие на Git с нераспределенной системы управления версиями, могут захотеть и дальше пользоваться центральным репозиторием. Несмотря на распределенную архитектуру, Git допускает возможность создания классического репозитория, где сохраняются все изменения проекта. При этом в Git продуктивность разработчиков не зависит от доступности и производительности «центрального» сервера. Каждому пользователю доступна полная копия репозитория, в которой он может просматривать всю историю проекта даже в периоды отсутствия соединения с сетью и перебоев в системе. Распределенная архитектура и гибкость Git позволяют участникам проекта работать в удобном ритме и пользоваться уникальными преимуществами, о которых они могли не подозревать раньше.
Теперь вы разобрались в основах управления версиями, получили представление о Git и узнали, почему командам разработки ПО стоит пользоваться этой системой. Теперь можно перейти к изучению преимуществ, которые Git может предоставить в масштабах организации.
Готовы изучить Git?
Ознакомьтесь с этим интерактивным обучающим руководством.
В чем разница между Git Revert, Checkout и Reset?
Эти три команды имеют совершенно разные цели. Они даже отдаленно не похожи.
git revert
Эта команда создает новый коммит, который отменяет изменения предыдущего коммита. Эта команда добавляет новую историю в проект (она не изменяет существующую историю).
git checkout
Эта команда извлекает содержимое из репозитория и помещает его в дерево работы. Это также может иметь другие эффекты, в зависимости от того, как была вызвана команда. Например, он также может изменить ветку, над которой вы сейчас работаете. Эта команда не вносит никаких изменений в историю.
git reset
Эта команда немного сложнее. Это на самом деле делает несколько разных вещей в зависимости от того, как он вызывается. Он изменяет индекс (так называемая «область подготовки»). Или это меняет то, на какой коммит в данный момент указывает голова ветки. Эта команда может изменить существующую историю (путем изменения коммита, на который ссылается ветка).
Используя эти команды
Если коммит был сделан где-то в истории проекта, и вы позже решили, что коммит был неправильным и не должен был быть сделан, тогда git revert это инструмент для работы. Он отменит изменения, внесенные плохим коммитом, записав «отмену» в истории.
Если вы изменили файл в своем рабочем дереве, но не зафиксировали это изменение, вы можете использовать git checkout для извлечения свежую копию файла из хранилища.
Если вы сделали коммит, но не поделились им с кем-либо еще и решили, что он вам не нужен, то вы можете git reset переписать историю так, чтобы она выглядела так, как будто вы никогда не делали этот коммит.
Это лишь некоторые из возможных сценариев использования. Существуют и другие команды, которые могут быть полезны в некоторых ситуациях, и у вышеперечисленных трех команд есть и другие применения.
