что такое git revert

Что такое git revert

Given one or more existing commits, revert the changes that the related patches introduce, and record some new commits that record them. This requires your working tree to be clean (no modifications from the HEAD commit).

See «Reset, restore and revert» in git[1] for the differences between the three commands.

OPTIONS

With this option, git revert will let you edit the commit message prior to committing the revert. This is the default if you run the command from a terminal.

Usually you cannot revert a merge because you do not know which side of the merge should be considered the mainline. This option specifies the parent number (starting from 1) of the mainline and allows revert to reverse the change relative to the specified parent.

Reverting a merge commit declares that you will never want the tree changes brought in by the merge. As a result, later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge. This may or may not be what you want.

With this option, git revert will not start the commit message editor.

Usually the command automatically creates some commits with commit log messages stating which commits were reverted. This flag applies the changes necessary to revert the named commits to your working tree and the index, but does not make the commits. In addition, when this option is used, your index does not have to match the HEAD commit. The revert is done against the beginning state of your index.

This is useful when reverting more than one commits’ effect to your index in a row.

Add a Signed-off-by trailer at the end of the commit message. See the signoff option in git-commit[1] for more information.

Use the given merge strategy. Should only be used once. See the MERGE STRATEGIES section in git-merge[1] for details.

Pass the merge strategy-specific option through to the merge strategy. See git-merge[1] for details.

Allow the rerere mechanism to update the index with the result of auto-conflict resolution if possible.

SEQUENCER SUBCOMMANDS

Skip the current commit and continue with the rest of the sequence.

Forget about the current operation in progress. Can be used to clear the sequencer state after a failed cherry-pick or revert.

Cancel the operation and return to the pre-sequence state.

EXAMPLES

Revert the changes specified by the fourth last commit in HEAD and create a new commit with the reverted changes.

Revert the changes done by commits from the fifth last commit in master (included) to the third last commit in master (included), but do not create any commit with the reverted changes. The revert only modifies the working tree and the index.

Источник

10 Git-команд, которые стоит знать разработчику

В этой статье мы обсудим разные Git-команды, которые могут оказаться полезными для разработчика или специалиста по Big Data. Вы узнаете, как проверять, удалять и приводить код в порядок. А еще рассмотрим способы выхода из Vim и экономию времени с помощью псевдонимов Bash и конфигурации редактора Git.

Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».

Проверяем все и вся

Вернуть, как было

Если вы работаете в коллективе и коммиты общие, тогда ваш выбор — git revert.

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

HEAD часто используется для my_commit, чтобы отменить изменения в вашем локальном рабочем каталоге с момента последней фиксации.

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

Если вы используете checkout с веткой вместо коммита, HEAD переключается на указанную ветвь, а рабочий каталог обновляется для соответствия изменениям. Это самое распространенное использование этой команды.

git revert my_commit — отмена последствий изменений в my_commit. revert выполняет новый коммит после отмены изменений.

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

Иногда вы просто хотите удалить неотслеживаемые файлы в вашем локальном каталоге. К примеру, запустив какой-то код, который создал много разных типов файлов, которые вам не нужны. К сожалению. Clean поможет мгновенно удалить их!

-n — флаг для пробного запуска, ничего не удаляется.
-f — флаг для удаления файлов.
-d — флаг для удаления неотслеживаемых директорий.

Наводим порядки

Если ничего не проиндексировано, команда позволяет вам редактировать последнее сообщение коммита. Используйте команду только в том случае, если коммит не был объединен с удаленной master-веткой.

Помогите, я застрял в Vim и не могу выбраться!

Git в некоторых случаях открывает сессию редактора Vim. И если вы не слишком хорошо знакомы с ним, то можете оказаться в затруднительной ситуации. Да и не только вы — к примеру, на Stack Overflow более 4 тысяч пользователей хотят знать, как выбраться из Vim.

Вот четырехэтапный план, который поможет закрыть Vim и сохранить изменения:

Изменяем редактор по умолчанию.

Вы можете избавиться от Vim совсем, если смените редактор по умолчанию. Вот команды для работы с популярными редакторами. Пример выбора другого редактора, в нашем случае Atom:

Ярлыки для команд Git

Что касается способа, приведенного выше, то теперь вы можете использовать gs вместо git status.

Собственно, это все на сегодня. Если есть возможность, укажите в комментариях, какие Git-команды используете вы и почему.

Источник

Git, я хочу все отменить! Команды исправления допущенных ошибок

Git — удобная, но довольно сложная система. Сложность, прежде всего, в том, что по невнимательности можно допустить ошибку, которую затем сложно или вообще невозможно исправить. Документация Git предоставляет описание множества команд, которые дают возможность исправить ошибку.

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

Черт, я сделал что-то не то. Дайте мне волшебную машину времени!

Эта команда позволяет восстановить случайно удаленные данные, откатив слияние, после которого случилась неприятность. refLog используется ну очень часто — давайте скажем спасибо тому, что предложил добавить эту команду.

Я сделал коммит, но сразу же заметил ошибку, ее нужно исправить!

NB! Никогда не изменяйте коммиты в публичной ветке. Применяйте команду лишь для коммитов в локальной ветке, иначе у вас будут проблемы.

Хочу изменить сообщение последнего коммита!

Это просто… глупые требования к оформлению сообщений.

Я случайно закоммитил в мастер, хотя это должен был в новую ветку!

Если вы уже закоммитили в публичную ветку, команды не сработают. В этом случае поможет git reset HEAD@ <укажите количество коммитов, на которое нужно вернуться>вместо HEAD

Ну вот, я ошибочно закоммитил не в ту ветку

Есть еще один способ, который использует большое количество разработчиков — это cherry-pick.

Мне нужно запустить diff, но ничего не получается

Если вы уверены в том, что изменения были внесены, но diff пустой, вполне может быть, что вы индексировали изменения через add. Поэтому стоит использовать специальный флаг.

В общем, это не баг, а фича, но она чертовски неочевидная ¯\_(ツ)_/¯

Мне срочно нужно отменить коммит, который сделан 5 коммитов назад

К счастью, не нужно отказываться назад на 5 коммитов, занимаясь копипастом старых и новых файлов. Отменить все это можно при помощи revert.

Кроме того, откатить можно не только коммит, но и целый файл. Правда, это уже будут другие команды…

Отменить изменения в файле

А вот и они, эти другие команды.

Когда я впервые нашел эту возможность, это было КРУТО, КРУТО, К-Р-У-Т-О. Но если задуматься — почему именно checkout — лучший вариант для отмены изменений в файле? :shakes-fist-at-linus-torvalds:

Спасибо Eric V. За этот способ. И все жалобы по поводу использования sudo адресуйте ему.

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

Внимание! Эта статья не является исчерпывающим руководством. И да, есть и другие способы сделать то же самое, причем еще лучше. Но я пришел именно к этим вариантам методом проб и ошибок. Потом у меня появилась сумасшедшая идея поделиться находками. Берите это или уходите!

Даниил Пилипенко, директор центра подбора IT-специалистов SymbioWay и евангелист бэкенд-направления онлайн-университета Skillbox, дополнил перевод мнением о Git и его актуальности для разработчиков.

Git появился в 2005-ом году, и он далеко не сразу занял рынок. Помню, когда мы ещё в 2008-ом году в команде разработчиков внедряли SVN. И даже в 2012-ом одна близкая ко мне компания усиленно внедряла Mercurial. С годами для многих стало очевидным, что Git — это лучшая система контроля версий, и её теперь используют практически все разработчики.

Если вы начинающий разработчик и собираетесь устраиваться на работу, обязательно изучите Git! Вы должны знать, что такое система контроля версий и зачем она нужна, что такое коммит, ветка, как клонировать репозиторий и отправлять сделанные изменения на сервер, как получать новые изменения с сервера, как делать merge, какие бывают виды “reset”. Поначалу эта тема вам может показаться непонятной и сложной, но вам нужно лишь привыкнуть пользоваться Git, и отвыкнуть вы уже не сможете.

Источник

Сравнение процессов

Git — это наиболее распространенная система управления версиями на сегодняшний день. Рабочий процесс Git — это инструкции или рекомендации, которые помогают выполнять работу в Git единообразно и продуктивно. Рабочие процессы Git побуждают разработчиков и команды DevOps использовать Git эффективно и последовательно. Пользователи Git могут очень гибко управлять изменениями. Поскольку в Git особое значение придается гибкости, не существует стандартного процесса взаимодействия с этой системой. При командной работе над проектом под управлением Git важно согласовать с участниками команды процесс внесения изменений. Чтобы между участниками команды существовало взаимопонимание, необходимо разработать или выбрать единый рабочий процесс Git. Есть несколько широко известных рабочих процессов Git, которые могут подойти вашей команде. Здесь мы рассмотрим некоторые из них.

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

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

Что такое успешный рабочий процесс Git?

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

Централизованный рабочий процесс

Переход на распределенную систему управления версиями может казаться очень сложной задачей, но на самом деле вам не придется изменять существующий рабочий процесс, чтобы воспользоваться преимуществами Git. Ваша команда может продолжать разработку проектов точно так же, как она это делала в Subversion.

Однако процесс разработки в Git имеет ряд преимуществ перед SVN. Во-первых, каждый разработчик использует собственную локальную копию всего проекта. Работая в изолированной среде, разработчик может не заботиться о других изменениях в проекте. Он добавляет коммиты в локальный репозиторий и не думает о более высоких уровнях разработки, пока это ему удобно.

Во-вторых, этот процесс открывает доступ к надежной модели ветвления и слияния, принятой в Git. В отличие от SVN, ветки Git представляют собой отказоустойчивый механизм для интеграции кода и передачи изменений между репозиториями. Централизованный рабочий процесс похож на другие рабочие процессы тем, что в нем используется удаленный репозиторий. Репозиторий размещается на сервере, и разработчики помещают туда и извлекают оттуда содержимое. В отличие от других рабочих процессов, в централизованном рабочем процессе не определены шаблоны запросов pull или ветвления (форков). Централизованный рабочий процесс обычно больше подходит для команд, которые переходят из SVN в Git, а также для небольших команд.

Порядок действий

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

Инициализация центрального репозитория

Прежде всего, кто-то должен создать центральный репозиторий на сервере. Если это новый проект, можно инициализировать пустой репозиторий. В остальных случаях необходимо импортировать существующий репозиторий Git или SVN.

Централизованные репозитории всегда должны быть чистыми (т. е. не должны содержать рабочего каталога). Такой репозиторий можно создать командой

Размещение центральных репозиториев

Часто центральные репозитории создаются через сторонние сервисы хостинга Git, такие как Bitbucket Cloud или Bitbucket Server. В этом случае процедуру инициализации чистого репозитория, рассмотренную выше, выполняет сам сервис хостинга. После этого сервис хостинга предоставляет разработчикам адрес центрального репозитория для доступа к нему из локальных репозиториев.

Клонирование центрального репозитория

Затем каждый разработчик создает локальную копию всего проекта с помощью команды git clone :

Внесение изменений и выполнение коммита

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

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

Отправка новых коммитов в центральный репозиторий

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

Управление конфликтами

Центральный репозиторий представляет официальный проект, поэтому его история коммитов считается неприкосновенной. Если локальные коммиты разработчика расходятся с центральным репозиторием, Git откажется вносить изменения, потому что при этом будут перезаписаны официальные коммиты.

Прежде чем публиковать свою функцию, разработчик должен извлечь из центрального репозитория обновленные коммиты и перебазировать свои изменения поверх них. Этим он как бы заявляет: «Я хочу, чтобы мои изменения были добавлены после всех остальных». В результате получится абсолютно линейная история, как в классических рабочих процессах SVN.

Пример

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

Джон работает над своей функцией

В своем локальном репозитории Джон может вести разработку функций, используя стандартный процесс коммитов в Git: редактирование, индексирование и выполнение коммита.

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

Мэри работает над своей функцией

Тем временем Мэри работает над своей функцией в собственном локальном репозитории, используя тот же процесс редактирования, индексирования и выполнения коммитов. Как и Джон, она не заботится о том, что происходит в центральном репозитории, и ей совершенно все равно, что делает в своем локальном репозитории Джон, потому что все локальные репозитории являются частными.

Джон публикует свою функцию

Мэри пытается опубликовать свою функцию

Давайте посмотрим, что произойдет, если Мэри попытается отправить свою функцию после того, как Джон опубликовал свои изменения в центральном репозитории. Она может использовать ту же команду push:

Однако поскольку ее локальная история отличается от истории центрального репозитория, Git отклонит запрос, выдав довольно подробное сообщение об ошибке:

Таким образом, Мэри не сможет перезаписать официальные коммиты. Ей необходимо с помощью команды pull забрать обновления Джона в свой репозиторий, интегрировать их с собственными локальными изменениями, а затем повторить попытку.

Мэри перебазирует свои изменения поверх коммитов Джона

Мэри разрешает конфликт слияния

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

Если Мэри и Джон работают над не связанными друг с другом функциями, то вряд ли процесс перебазирования приведет к появлению конфликтов. Однако если это все же произойдет, Git приостановит перебазирование на текущем коммите и выведет вот такое сообщение с несколькими соответствующими инструкциями:

Замечательная особенность Git состоит в том, что разрешить свои конфликты слияния может любой пользователь. В нашем примере Мэри может просто запустить команду git status и найти источник проблемы. Конфликтующие файлы отобразятся в разделе Unmerged paths (Пути без слияния).

Затем она может отредактировать файлы по своему усмотрению. После внесения нужных изменений можно проиндексировать файлы обычным способом и позволить команде git rebase сделать все остальное.

Вот и все. Git перейдет к следующему коммиту и повторит процесс для всех остальных коммитов, создающих конфликты.

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

Мэри опубликовала свою функцию

После выполнения синхронизации с центральным репозиторием Мэри может опубликовать свои изменения:

Куда можно перейти отсюда

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

Централизованный рабочий процесс отлично подходит для небольших команд. По мере роста вашей команды описанный выше процесс разрешения конфликтов может стать проблемным местом. Если вашей команде удобен централизованный рабочий процесс, но хочется оптимизировать совместную работу, рекомендуется изучить преимущества рабочего процесса с функциональными ветками. Выделение изолированной ветки для каждой функции позволяет проводить подробные обсуждения новых дополнений перед их интеграцией в официальный проект.

Другие распространенные рабочие процессы

Централизованный рабочий процесс — это, по сути, строительный блок для других рабочих процессов Git. Наиболее популярные рабочие процессы Git имеют своего рода централизованный репозиторий, откуда забирают и куда отправляют код отдельные разработчики. Далее кратко рассматриваются некоторые другие популярные рабочие процессы Git. Эти расширенные рабочие процессы предлагают более специализированные с точки зрения управления ветками шаблоны для разработки функций, внесения быстрых исправлений и выпуска релизов.

Использование функциональных веток

Рабочий процесс Gitflow Workflow

Рабочий процесс Gitflow был впервые опубликован в 2010 году в блоге разработчика Винсента Дриссена, известного под псевдонимом nvie. Gitflow предполагает выстраивание строгой модели ветвления с учетом выпуска проекта. В этом рабочем процессе используются понятия и команды, которые были предложены в рамках рабочего процесса с функциональными ветками. Однако Gitflow привносит новые специфические роли для разных веток и определяет характер и частоту взаимодействия между ними.

Рабочий процесс Forking Workflow

Рабочий процесс с форками принципиально отличается от других рабочих процессов, рассмотренных в этом обучающем руководстве. Этот рабочий процесс предоставляет каждому разработчику репозиторий на стороне сервера, чтобы не использовать один репозиторий на сервере в качестве «центральной» базы кода. Таким образом, у каждого автора будет не один, а два репозитория Git: один частный локальный и один публичный на сервере.

Рекомендации

Универсального рабочего процесса Git не существует. Как отмечалось ранее, важно разработать рабочий процесс Git, который повысит продуктивность вашей команды. Рабочий процесс должен дополнять не только культуру команды, но и бизнес-культуру. Возможности Git, такие как ветки и теги, должны дополнять график релизов, соответствующий потребностям бизнеса. Если ваша команда использует программное обеспечение для отслеживания заданий, вы можете использовать ветки, которые соответствуют текущим выполняемым заданиям. При выборе рабочего процесса также следует учитывать приведенные ниже рекомендации.

Краткосрочные ветки

Чем дольше ветка живет отдельно от рабочей среды, тем выше риск возникновения конфликтов слияния и проблем с развертыванием. Краткосрочные ветки способствуют более чистому слиянию и развертыванию.

Сокращение количества возвратов к предыдущей версии и упрощение этого процесса

Соответствие графику релизов

Рабочий процесс должен дополнять цикл релизов ПО в компании. Если вы планируете выпускать релизы несколько раз в день, ветка main должна оставаться стабильной. Если график релизов предполагает менее частый выпуск, можно соотнести ветку с нужной версией с помощью тегов Git.

Резюме

В этом документе были рассмотрены рабочие процессы Git. Мы подробно изучили централизованный рабочий процесс и его практические примеры. Для более подробного освещения темы централизованного рабочего процесса были рассмотрены дополнительные специализированные рабочие процессы. Вот некоторые ключевые идеи этого документа.

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

Готовы изучить Git?

Ознакомьтесь с этим интерактивным обучающим руководством.

Источник