Изменение последнего коммита — Введение в Git
Крайне часто разработчики делают коммит и сразу понимают, что забыли добавить часть файлов через git add . Оставшуюся часть изменений можно дослать следующим коммитом.
Есть еще один способ. Если изменения еще не были отправлены во внешнюю систему, можно добавить изменения в текущий коммит. Для этого во время коммита добавляется флаг —amend :
echo 'experiment with amend' >> INFO.md echo 'experiment with amend' >> README.md git add INFO.md # Забыли сделать подготовку README.md к коммиту git commit -m 'add content to INFO.md and README.md' [main 256de25] add content to INFO.md and README.md 1 file changed, 1 insertion(+) git status On branch main Your branch is ahead of 'origin/main' by 1 commit. (use "git push" to publish your local commits) Changes not staged for commit: (use "git add . " to update what will be committed) (use "git restore . " to discard changes in working directory) modified: README.md # Увидели, что забыли добавить файл # Добавляем git add README.md git commit --amend # После этой команды откроется редактор, ожидающий ввода описания коммита # Здесь можно поменять сообщение или выйти из редактора, оставив старое [main d96151a] add content to INFO.md and README.md Date: Sat Sep 26 16:02:07 2020 -0400 2 files changed, 2 insertions(+) git status On branch main Your branch is ahead of 'origin/main' by 1 commit. (use "git push" to publish your local commits) nothing to commit, working tree clean
В реальности —amend не добавляет изменения в существующий коммит. Этот флаг приводит к откату коммита через git reset и выполнению нового коммита с новыми данными. Поэтому мы и видим ровно один коммит, хотя команда git commit выполнялась два раза (первый раз — когда сделали ошибочный коммит).
Чтобы не открывался редактор для ввода описания коммита к команде git commit —amend можно добавить опцию —no-edit . В этом случае описание коммита не изменится:
Самостоятельная работа
- Выполните все шаги из урока
- Залейте изменения на GitHub
Дополнительные материалы
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
3.2 Ветвление в Git — Основы ветвления и слияния
Давайте рассмотрим простой пример рабочего процесса, который может быть полезен в вашем проекте. Ваша работа построена так:
- Вы работаете над сайтом.
- Вы создаете ветку для реализации новой функциональности в соответствии с пользовательской историей.
- Вы работаете в этой ветке.
В этот момент вы получаете сообщение, что обнаружена критическая ошибка, требующая скорейшего исправления. Ваши действия:
- Переключиться на основную ветку.
- Создать ветку для добавления исправления.
- После тестирования слить ветку, содержащую исправление, с основной веткой.
- Переключиться назад в ветку для реализации пользовательской истории и продолжить работать.
Основы ветвления
Предположим, вы работаете над проектом и уже имеете несколько коммитов.
Рисунок 18. Простая история коммитов
Вы выбрали задачу #53 из какая-там-у-вас-система-отслеживания-задач. Чтобы создать ветку и сразу переключиться на неё, можно выполнить команду git checkout с параметром -b :
$ git checkout -b iss53 Switched to a new branch "iss53"
Это то же самое, что и:
$ git branch iss53 $ git checkout iss53
Рисунок 19. Создание нового указателя ветки
Вы работаете над сайтом и делаете коммиты. Это приводит к тому, что ветка iss53 движется вперед, так как вы переключились на неё ранее ( HEAD указывает на неё).
$ vim index.html $ git commit -a -m 'Create new footer [issue 53]'
Рисунок 20. Ветка iss53 движется вперед
И тут вы получаете сообщение об обнаружении на сайте уязвимости, и эту уязвимость устранить нужно немедленно. Благодаря Git вам не придётся ни пытаться реализовать исправление вместе с изменениями, которые вы сделали в ходе разработки iss53 , ни прилагать усилия для отката этих изменений и возвращения к исходному состоянию перед началом разработки исправления. Все, что вам нужно — переключиться на ветку master .
Имейте в виду, что если рабочий каталог или индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки. Лучше всего переключаться из чистого рабочего состояния проекта: все изменённые файлы добавить в индекс и сделать коммит. Есть способы обойти это (припрятать изменения (stash) или добавить их в последний коммит (amend)), но об этом мы поговорим позже в разделе Припрятывание и очистка главы 7. Теперь предположим, что вы зафиксировали все свои изменения и можете переключиться на ветку master :
$ git checkout master Switched to branch 'master'
С этого момента ваш рабочий каталог имеет точно такой же вид, какой был перед началом работы над задачей #53, и вы можете сосредоточиться на работе над исправлением. Важно запомнить: когда вы переключаете ветки, Git возвращает состояние рабочего каталога к тому виду, какой он имел в момент последнего коммита в переключаемую ветку. Он добавляет, удаляет и изменяет файлы автоматически, чтобы состояние рабочего каталога соответствовало тому, когда был сделан последний коммит.
Теперь вы можете перейти к написанию исправления. Давайте создадим новую ветку, в которой реализуем исправление.
$ git checkout -b hotfix Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m 'Fix broken email address' [hotfix 1fb7853] Fix broken email address 1 file changed, 2 insertions(+)
Рисунок 21. Ветка hotfix основана на ветке master
Вы можете прогнать тесты, чтобы убедиться, что ваше уязвимость в самом деле исправлена. И если это так — выполнить слияние ветки hotfix с веткой master для включения изменений в продукт. Это делается командой git merge :
$ git checkout master $ git merge hotfix Updating f42c576..3a0874c Fast-forward index.html | 2 ++ 1 file changed, 2 insertions(+)
Заметили фразу «fast-forward» в этом слиянии? Git просто переместил указатель ветки вперед, потому что коммит C4 , на который указывает слитая ветка hotfix , был прямым потомком коммита C2 , на котором вы находились до этого. Другими словами, если коммит сливается с тем, до которого можно добраться, двигаясь по истории вперёд, Git упрощает слияние, просто перенося указатель ветки вперед, потому что в этом случае нет никаких разнонаправленных изменений, которые нужно было бы свести воедино. Это называется «fast-forward».
Теперь ваши изменения включены в коммит, на который указывает ветка master , и исправление можно внедрять.
Рисунок 22. master перемотан до hotfix
После внедрения вашего архиважного исправления вы готовы вернуться к работе над тем, что были вынуждены отложить. Но сначала нужно удалить ветку hotfix , потому что она больше не нужна — ветка master указывает на то же самое место. Для удаления ветки выполните команду git branch с параметром -d :
$ git branch -d hotfix Deleted branch hotfix (3a0874c).
Теперь вы можете переключиться обратно на ветку iss53 и продолжить работу над задачей #53:
$ git checkout iss53 Switched to branch "iss53" $ vim index.html $ git commit -a -m 'Finish the new footer [issue 53]' [iss53 ad82d7a] Finish the new footer [issue 53] 1 file changed, 1 insertion(+)
Рисунок 23. Продолжение работы над iss53
Стоит обратить внимание на то, что все изменения из ветки hotfix не включены в вашу ветку iss53 . Если их нужно включить, вы можете влить ветку master в вашу ветку iss53 командой git merge master , а можете отложить слияние этих изменений до завершения работы, и затем влить ветку iss53 в master .
Основы слияния
Предположим, вы решили, что работа по проблеме #53 закончена и её можно влить в ветку master . Для этого нужно выполнить слияние ветки iss53 точно так же, как вы делали это с веткой hotfix ранее. Все, что нужно сделать — переключиться на ветку, в которую вы хотите включить изменения, и выполнить команду git merge :
$ git checkout master Switched to branch 'master' $ git merge iss53 Merge made by the 'recursive' strategy. index.html | 1 + 1 file changed, 1 insertion(+)
Результат этой операции отличается от результата слияния ветки hotfix . В данном случае процесс разработки ответвился в более ранней точке. Так как коммит, на котором мы находимся, не является прямым родителем ветки, с которой мы выполняем слияние, Git придётся немного потрудиться. В этом случае Git выполняет простое трёхстороннее слияние, используя последние коммиты объединяемых веток и общего для них родительского коммита.
Рисунок 24. Использование трёх снимков при слиянии
Вместо того, чтобы просто передвинуть указатель ветки вперёд, Git создаёт новый результирующий снимок трёхстороннего слияния, а затем автоматически делает коммит. Этот особый коммит называют коммитом слияния, так как у него более одного предка.
Рисунок 25. Коммит слияния
Теперь, когда изменения слиты, ветка iss53 больше не нужна. Вы можете закрыть задачу в системе отслеживания ошибок и удалить ветку:
$ git branch -d iss53
Основные конфликты слияния
Иногда процесс не проходит гладко. Если вы изменили одну и ту же часть одного и того же файла по-разному в двух объединяемых ветках, Git не сможет их чисто объединить. Если ваше исправление ошибки #53 потребовало изменить ту же часть файла что и hotfix , вы получите примерно такое сообщение о конфликте слияния:
$ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.
Git не создал коммит слияния автоматически. Он остановил процесс до тех пор, пока вы не разрешите конфликт. Чтобы в любой момент после появления конфликта увидеть, какие файлы не объединены, вы можете запустить git status :
$ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add . " to mark resolution) both modified: index.html no changes added to commit (use "git add" and/or "git commit -a")
Всё, где есть неразрешённые конфликты слияния, перечисляется как неслитое. В конфликтующие файлы Git добавляет специальные маркеры конфликтов, чтобы вы могли исправить их вручную. В вашем файле появился раздел, выглядящий примерно так:
contact : email.support@github.com
please contact us at support@github.com
>>>>>>> iss53:index.html
Это означает, что версия из HEAD (вашей ветки master , поскольку именно её вы извлекли перед запуском команды слияния) — это верхняя часть блока (всё, что над ======= ), а версия из вашей ветки iss53 представлена в нижней части. Чтобы разрешить конфликт, придётся выбрать один из вариантов, либо объединить содержимое по-своему. Например, вы можете разрешить конфликт, заменив весь блок следующим:
please contact us at email.support@github.com
В этом разрешении есть немного от каждой части, а строки >>>>>> полностью удалены. Разрешив каждый конфликт во всех файлах, запустите git add для каждого файла, чтобы отметить конфликт как решённый. Добавление файла в индекс означает для Git, что все конфликты в нём исправлены.
Если вы хотите использовать графический инструмент для разрешения конфликтов, можно запустить git mergetool , который проведет вас по всем конфликтам:
$ git mergetool This message is displayed because 'merge.tool' is not configured. See 'git mergetool --tool-help' or 'git help config' for more details. 'git mergetool' will now attempt to use one of the following tools: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge Merging: index.html Normal merge conflict for 'index.html': : modified file : modified file Hit return to start merge resolution tool (opendiff):
Если вы хотите использовать инструмент слияния не по умолчанию (в данном случае Git выбрал opendiff , поскольку команда запускалась на Mac), список всех поддерживаемых инструментов представлен вверху после фразы «one of the following tools». Просто введите название инструмента, который хотите использовать.
Примечание
Мы рассмотрим более продвинутые инструменты для разрешения сложных конфликтов слияния в разделе Продвинутое слияние главы 7.
После выхода из инструмента слияния Git спросит об успешности процесса. Если вы ответите скрипту утвердительно, то он добавит файл в индекс, чтобы отметить его как разрешённый. Теперь можно снова запустить git status , чтобы убедиться в отсутствии конфликтов:
$ git status On branch master All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: index.html
Если это вас устраивает и вы убедились, что все файлы, где были конфликты, добавлены в индекс — выполните команду git commit для создания коммита слияния. Комментарий к коммиту слияния по умолчанию выглядит примерно так:
Merge branch 'iss53' Conflicts: index.html # # It looks like you may be committing a merge. # If this is not correct, please remove the file # .git/MERGE_HEAD # and try again. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # All conflicts fixed but you are still merging. # # Changes to be committed: # modified: index.html #
Если вы считаете, что коммит слияния требует дополнительных пояснений — опишите как были разрешены конфликты и почему были применены именно такие изменения, если это не очевидно.
7. Коммит изменений
Достаточно об индексации. Давайте сделаем коммит того, что мы проиндексировали, в репозиторий.
Когда вы ранее использовали git commit для коммита первоначальной версии файла hello.html в репозиторий, вы включили метку -m , которая делает комментарий в командной строке. Команда commit позволит вам интерактивно редактировать комментарии для коммита. Теперь давайте это проверим.
Если вы опустите метку -m из командной строки, Git перенесет вас в редактор по вашему выбору. Редактор выбирается из следующего списка (в порядке приоритета):
- переменная среды GIT_EDITOR
- параметр конфигурации core.editor
- переменная среды VISUAL
- переменная среды EDITOR
У меня переменная EDITOR установлена в vim . Если вы предпочитаете GUI-редактор, то теперь можно использовать VS Code в качестве Git-редактора.
Сделайте коммит сейчас и проверьте состояние.
Выполните
git commit
Вы увидите в вашем редакторе:
Результат
| # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # On branch main # Changes to be committed: # modified: hello.html #
В первой строке введите комментарий: Added h1 tag . Сохраните файл и выйдите из редактора (для этого в редакторе по умолчанию (Vim) вам нужно нажать клавишу ESC, ввести :wq и нажать Enter). Вы увидите:
Результат
$ git commit [main 78433de] Added h1 tag 1 file changed, 1 insertion(+), 1 deletion(-)
Строка «Waiting for Emacs. » получена из программы emacsclient , которая посылает файл в запущенную программу emacs и ждет его закрытия. Остальные выходные данные – стандартные коммит-сообщения.
02 Проверьте состояние
В конце давайте еще раз проверим состояние.
Выполните
git status
Результат
$ git status On branch main nothing to commit, working tree clean
Рабочая директория чиста, можем продолжить работу.
Управление репозиториями Git в Visual Studio
Окно репозитория Git предоставляет полноэкранный интерфейс Git, который помогает управлять репозиторием Git и оставаться в курсе проектов вашей команды. Например, может потребоваться сбросить, отменить изменения или фиксации вишни или просто очистить журнал фиксаций. Окно репозитория Git также отлично подходит для визуализации и управления ветвями.
С помощью Git можно легко управлять версиями в Visual Studio. Кроме того, вы можете удаленно работать с поставщиком Git, например GitHub или Azure DevOps. или локально без каких-либо поставщиков.
Изменение последней фиксации (изменение)
Обновление последней фиксации называется изменением в Git, и это распространенный вариант использования. Иногда вам просто нужно обновить сообщение о фиксации, или может потребоваться включить изменения в последнюю минуту.
Вы можете изменить фиксацию в командной строке с помощью следующей команды:
git commit --amend
Окно репозитория Git упрощает обновление сообщения фиксации. Откройте сведения о фиксации последней фиксации, дважды щелкнув его, а затем выберите параметр «Изменить » рядом с сообщением о фиксации.
После завершения редактирования сообщения фиксации нажмите кнопку «Изменить«.
Если вам нужно включить изменения кода в последнюю фиксацию, это можно сделать в окне изменений Git. Выберите поле «Изменить проверка», а затем зафиксируйте изменения.
Дополнительные сведения о внесении изменений см. в статье «Средства Git — переписывание журнала » на веб-сайте Git.
Фиксации слиянием (скваш)
Чтобы объединить серию фиксаций, Git предоставляет возможность squash-фиксаций в одну фиксацию. Этот параметр может быть полезным, если вы делаете частые фиксации и в конечном итоге с длинным списком фиксаций, которые необходимо очистить перед отправкой в удаленный репозиторий.
Вы можете сквашировать две фиксации в командной строке с помощью следующей команды:
git rebase -i HEAD~2
Затем обновите pick squash сообщение о фиксации, сохраните и обновите его.
Чтобы объединить фиксации в Visual Studio, используйте клавиши CTRL , чтобы выбрать несколько фиксаций, которые требуется объединить. Затем щелкните правой кнопкой мыши и выберите Squash Commits. Visual Studio автоматически объединяет сообщения фиксации, но иногда лучше предоставить обновленное сообщение. После просмотра и обновления сообщения фиксации нажмите кнопку Squash .
Дополнительные сведения о сквашировании см. в статье «Средства Git — переписывание журнала » на веб-сайте Git.
Слияние и повторная базовая ветвь
Если вы используете ветви Git для работы с различными функциями, в какой-то момент вам потребуется включить обновления, представленные в других ветвях. Это может произойти, пока вы все еще работаете над ветвь компонента. Это также может произойти, когда вы закончите работу над ветвь компонента и должны сохранить изменения, добавив их в другую ветвь. В Git эти обновления можно включить, объединяя или переключяя ветви.
Следующие инструкции используют New_Feature в качестве примера имени для ветвь компонента. Замените его именем собственной ветви.
Чтобы объединить основную ветвь в ветвь компонента в командной строке, выполните следующие команды:
git checkout New_Feature git merge main
Чтобы сделать то же самое в Visual Studio, проверка ветвь компонента, дважды щелкнув его в списке ветвей. Затем щелкните правой кнопкой мыши main и выберите «Объединить main» в «New_Feature».
Чтобы перебазировать главную ветвь в ветвь компонента в командной строке, используйте следующие команды:
git checkout New_Feature git rebase main
Чтобы сделать то же самое в Visual Studio, проверка ветвь компонента, дважды щелкнув его в списке ветвей. Затем щелкните правой кнопкой мыши main и выберите «Rebase» «New_Feature» на «main».
Дополнительные сведения о слиянии, перебазировании и ветвлениях в целом см . на веб-сайте Git Branching .
Копирование фиксаций (вишня-выбор)
Скопируйте фиксации из одной ветви в другую с помощью параметра выбора вишни. В отличие от слияния или повторной базы, выбор вишни приносит только изменения из выбранных фиксаций, а не все изменения в ветви. Выбор вишни — отличный способ решить эти распространенные проблемы:
- Случайное фиксация в неправильной ветви. Выберите изменения в правильной ветви, а затем сбросить исходную ветвь до предыдущей фиксации.
- Вытащив набор фиксаций, сделанных в ветвь компонента, поэтому вы объединяете их обратно в основную ветвь раньше.
- Перенос определенных фиксаций из основной ветви без повторной балансировки ветви.
Чтобы скопировать изменения из фиксации в текущую ветвь с помощью командной строки, используйте следующую команду:
git cherry-pick 7599e530
Чтобы сделать то же самое в Visual Studio, просмотрите ветвь, из которой вы хотите выбрать фиксацию, выбрав ее одним щелчком мыши. Затем щелкните правой кнопкой мыши целевую фиксацию и выберите «Вишни-Выбрать«.
По завершении операции Visual Studio отображает сообщение об успешном выполнении. Фиксация, которую вы выбрали вишни , появится в разделе «Исходящие «.
Дополнительные сведения о фиксациях выбора вишни см. на веб-странице Git для команды выбора вишни.
Отменить изменения
Используйте команду отменить изменения, чтобы отменить изменения, внесенные в фиксации, отправленные в общие ветви. Команда отменить изменения создает новую фиксацию, которая отменяет изменения, внесенные в предыдущую фиксацию. Команда отменить изменения не перезаписывает журнал репозитория, что делает его безопасным для использования при работе с другими пользователями.
Чтобы отменить изменения изменения, внесенные в фиксацию с помощью командной строки, используйте следующие команды. Замените пример идентификатором идентификатора реальной фиксации в ветви.
git revert 53333305 git commit
В предыдущем примере команды отменят изменения, внесенные в фиксацию 53333305, и создадут новую фиксацию в ветви. Исходная фиксация по-прежнему находится в журнале Git. Чтобы сделать то же самое в Visual Studio, щелкните правой кнопкой мыши фиксацию, которую вы хотите отменить изменения, а затем выберите «Вернуть». После подтверждения действия и завершения операции Visual Studio отображает сообщение об успешном выполнении, а новая фиксация появится в разделе «Исходящие».
Выберите новую фиксацию, чтобы убедиться, что она отменяет изменения отменить изменения фиксации.
Дополнительные сведения о отменить изменения изменениях см. на веб-странице Git для команды отменить изменения.
Сброс ветви в предыдущее состояние
Используйте команду сброса, чтобы вернуть ветвь в локальный репозиторий к содержимому предыдущей фиксации. Это действие не карта все изменения, которые произошли после фиксации, в которую вы сбрасываете ветвь.
Не сбрасывайте общие ветви, так как вы можете удалить работу других пользователей. Используйте вместо этого команду отменить изменения.
Чтобы сбросить ветвь в предыдущее состояние с помощью командной строки, используйте следующую команду. Замените пример идентификатором идентификатора реальной фиксации в ветви.
git reset --hard 53333305
—hard Часть команды сообщает Git, чтобы сбросить файлы в состояние предыдущей фиксации и дис карта любые промежуточные изменения. Чтобы сделать то же самое в Visual Studio, щелкните правой кнопкой мыши фиксацию, в которую нужно сбросить ветвь, а затем нажмите кнопку «Сброс >изменений» (—hard).
Дополнительные сведения о сбросе ветвей см. на веб-странице Git для команды сброса.
Связанный контент
- Работа с несколькими репозиториями
- Интерфейс Git в Visual Studio