Git checkout
На этой странице рассматривается команда git checkout , включая примеры использования и пограничные случаи. В Git под термином checkout подразумевают переключение между различными версиями целевого объекта. Команда git checkout работает с тремя различными объектами: файлами, коммитами и ветками. Под переключением также обычно понимают действие, связанное с выполнением команды git checkout . В рамках темы «Отмена изменений» мы рассмотрели, каким образом команду git checkout можно использовать для просмотра старых коммитов. В этом документе основное внимание будет уделено операциям переключения на ветки.
Переключение веток аналогично переключению старых коммитов и файлов, в которых рабочий каталог обновляется в соответствии с выбранной веткой/ревизией; вместе с тем новые изменения сохраняются в истории проекта, то есть это не просто операция чтения.
Переключение веток
Команда git checkout позволяет перемещаться между ветками, созданными командой git branch . При переключении ветки происходит обновление файлов в рабочем каталоге в соответствии с версией, хранящейся в этой ветке, а Git начинает записывать все новые коммиты в этой ветке. Рассматривайте эту команду как способ выбрать направление своей разработки.
Наличие выделенной ветки для каждой новой функции сильно отличается от традиционного рабочего процесса в SVN. Это значительно облегчает проведение новых экспериментов без страха разрушить существующую функциональность и позволяет одновременно работать со множеством несвязанных функций. Кроме того, ветки облегчают ведение нескольких совместных рабочих процессов.
Иногда команду git checkout можно спутать с командой git clone . Разница между этими двумя командами заключается в том, что при клонировании (clone) выполняется извлечение кода из удаленного репозитория, тогда как при переключении (checkout) происходит переключение между версиями кода, который уже находится в локальной системе.

Связанные материалы
Расширенный журнал Git
СМ. РЕШЕНИЕ
Изучите Git с помощью Bitbucket Cloud
Использование: существующие ветки
Если предположить, что ваш рабочий репозиторий уже содержит существующие ветки, вы можете переключаться между этими ветками с помощью команды git checkout . Чтобы узнать, какие ветки доступны и как называется текущая ветка, выполните команду git branch .
$> git branch
main
another_branch
feature_inprogress_branch
$> git checkout feature_inprogress_branch
В вышеприведенном примере показано, как просмотреть список доступных веток с помощью команды git branch и переключиться на конкретную ветку (в данном случае — на ветку feature_inprogress_branch ).
Новые ветки
Команда git checkout часто используется вместе с командой git branch. С помощью команды git branch можно создать новую ветку. Когда вы захотите начать работу над новой функцией, создайте новое ответвление от ветки main с помощью команды git branch new_branch . Затем переключитесь на новую ветку с помощью команды git checkout new_branch . Команда git checkout также принимает аргумент -b , который действует как вспомогательный метод, позволяя создать новую ветку и сразу переключиться на нее. Вы можете работать сразу с несколькими функциями в одном репозитории, переключаясь между ними с помощью git checkout .
git checkout -b <new-branch>
В вышеприведенном примере одновременно создается ветка и сразу же выполняется переключение на нее. Опция -b — это удобный способ сообщить системе Git, чтобы она выполнила команду git branch перед выполнением команды git checkout .
git checkout -b <new-branch> <existing-branch>
По умолчанию команда git checkout -b создает ветку новая-ветка от текущего указателя HEAD . Команде git checkout можно передать необязательный параметр с указанием ветки. В приведенном выше примере передается < существующая-ветка> , поэтому новая-ветка будет создана от ветки существующая-ветка , а не от текущего указателя HEAD .
Переключение веток
Переключение веток — простая операция. При выполнении следующей команды указатель HEAD будет перенесен на последний коммит ветки .
git checkout <branchname>
Git отслеживает историю операций переключения в журнале ссылок reflog. Чтобы просмотреть эту историю, выполните команду git reflog .
Переключение на удаленную ветку
При совместной работе команды нередко используют удаленные репозитории. Такие репозитории могут размещаться на сервере с предоставлением общего доступа либо это может быть локальная копия другого коллеги. Каждый удаленный репозиторий содержит собственный набор веток. Для переключения на удаленную ветку нужно сначала извлечь содержимое этой ветки.
git fetch --all
В современных версиях Git переключение на удаленную ветку не отличается от переключения на локальную ветку.
git checkout <remotebranch>
В старых версиях Git необходимо создавать новую ветку на основе удаленного репозитория ( remote ).
git checkout -b <remotebranch> origin/<remotebranch>
Кроме того, можно переключиться на новую локальную ветку и сбросить ее до последнего коммита удаленной ветки.
git checkout -b <branchname>
git reset --hard origin/<branchname>
Открепленные указатели HEAD
Теперь, когда мы рассмотрели три основных варианта использования команды git checkout на ветках, важно обсудить состояние detached HEAD , или состояние открепленного указателя HEAD. Помните, что HEAD — это указатель на текущий снимок в Git. По сути дела, команда git checkout просто обновляет указатель HEAD , чтобы он ссылался на указанную ветку или коммит. Когда HEAD указывает на ветку, Git молчит, но при попытке переключиться на коммит система переходит в состояние detached HEAD (открепленный указатель HEAD).
Это сообщение предупреждает о том, что вся текущая работа «откреплена» от остальной части вашего проекта. Если вы начнете разрабатывать функцию, находясь в состоянии открепленного указателя HEAD , у вас не будет ветки, которая позволила бы вам вернуться к этой функции. Когда вы неизбежно переключитесь на другую ветку (например, чтобы слить код своей функции), вы уже никак не сможете сослаться на свою функцию:
Всегда ведите разработку на ветке, а не на открепленном указателе HEAD . Это гарантия того, что у вас всегда будет ссылка на ваши новые коммиты. Вместе с тем при просмотре предыдущего коммита состояние указателя HEAD не имеет значения: он может быть как откреплен, так и нет.
Резюме
На этой странице было рассмотрено использование команды git checkout при смене ветки. В общем и целом при использовании команды git checkout на ветках происходит изменение позиции указателя HEAD . С помощью этой команды можно создавать ветки, менять текущую ветку и переключаться на удаленные ветки. Команда git checkout — важный инструмент при стандартной работе в Git. Она представляет собой аналог команды git merge. Команды git checkout и git merge критически важны для реализации рабочих процессов Git.
Создание ветви для работы с проблемой
Вы можете создать ветвь для работы с проблемой непосредственно на странице проблемы и сразу приступить к работе.
Note: The ability to create a branch for an issue is currently in public beta and subject to change.
About branches connected to an issue
Branches connected to an issue are shown under the «Development» section in the sidebar of an issue. When you create a pull request for one of these branches, it is automatically linked to the issue. The connection with that branch is removed and only the pull request is shown in the «Development» section. For more information, see «Linking a pull request to an issue.»
Creating a branch for an issue
Anyone with write permission to a repository can create a branch for an issue. You can link multiple branches for an issue.
By default, the new branch is created in the current repository, and from the default branch.
- On GitHub.com, navigate to the main page of the repository.
- Under your repository name, click

Issues.

and click Create a branch.
Учимся работать с другими
Допустим, у вас есть проект с кучей разных идей и возможностей для дальнейшей реализации. Что-то из этого уже готово, а над чем-то еще стоит потрудиться. Вполне возможно, что вы сотрудничаете с другими пользователями, которые работают над чем-то своим. Здесь и пригодится ветвление!
Ветка — это отдельное место для реализации новых идей. Изменения в ветке не затронут основную ветку master до тех пор, пока вы сами этого не захотите. То есть с отдельной веткой вы делаете что угодно, а затем просто сливаете эти изменения с основной веткой master .
Единственная ветка, которая может изменять проект, — это master . Если вы не хотите вносить изменения сразу, то выделите их отдельной веткой, а затем сливайте с master .
Если вы работаете с другими и хотите внести собственные изменения либо работаете над проектом и хотите изменить что-то, не затрагивая master , то создавайте отдельную ветку. Сделать это можно в любое время.
Очень удобно создавать в терминале ветку с названием new_feature (новая опция) и переходить в нее по команде:
git checkout -b new_feature
Вносить изменения в ветку можно сразу после ее создания. Использование отдельных веток с подходящими названиями позволяет сразу понять, что именно изменялось и почему. Каждый новый коммит следует снабжать комментарием, описывающим суть изменений.
Теперь поговорим о переключении между ветками:
git checkout
Команда позволяет «заглянуть» в репозиторий, который в данный момент не открыт. Например, вы можете перейти в ветку master :
git checkout master
или открыть ветку new_feature :
git checkout new_feature
По завершению работы с веткой можно слить эти изменения с master , чтобы их увидели другие.
git merge new_feature
Эта команда берет все изменения в ветке new_feature и добавляет их в ветку master .
Вы можете отправить изменения в репозиторий и установить удаленную ветку (например, new_feature ) в качестве «отслеживаемой»:
git push — set-upstream origin new_feature
Допустим, вы внесли какие-то изменения. Эти изменения вас устраивают, и вы хотите создать запрос на принятие изменений (Pull request). В Pull request ваши коллеги смогут проверить внесенные изменения и обсудить их. Pull request можно создавать по любому поводу, будь то внесение конечных изменений или просьба о помощи в решении какой-либо проблемы.
Эмммм… это делается через сайт?
Да, все это делается с сайта GitHub.
Pull request создается по нажатию одноименной кнопки, о которой мы говорили ранее при редактировании README-файла. Элементарно!
А еще вы можете создать отдельную ветку на сайте через сам репозиторий. Перейдите в репозиторий и кликните по выпадающему меню в левой части экрана. Там еще написано Branch: master. Задайте имя новой ветки и выберите Create branch (либо нажмите Enter на клавиатуре). Теперь у вас есть две одинаковые ветки. Это отличное место для внесения изменений и тестирования их до слияния с master .
Если вы работаете в отдельной ветке, то изменения затронут только ее.
Если вас устраивают внесенные изменения вы и хотите слить их с основной веткой, создайте Pull request. При коллективной работе вы можете предложить свои изменения через Pull request и попросить проверить их или слить их с нужными ветками.
Pull request можно открыть сразу при создании коммита, даже если вы все еще работаете с кодом. Делается это с сайта GitHub. Допустим, вы внесли изменения в ветку и хотите слить их с master . Тогда:
- Кликните по вкладке Pull request вверху экрана.
- Нажмите зеленую кнопку New pull request.
- Перейдите в поле Example Comparisons. Выберите ветку, которую хотите сравнить с master .
- Еще раз просмотрите все изменения, убедитесь, что они готовы для коммита.
- Нажмите большую зеленую кнопку Newpull request. Напишите заголовок запроса, дайте краткое описание изменений. Нажмите Create pull request.
Если это ваш репозиторий, то слить изменения с master можно через зеленую кнопку Merge pull request. Нажмите Confirm merge. Сразу после объединения нужной ветки с master нажмите Delete branch в фиолетовом боксе.
Если вы участвуете в чужом проекте, то у участников команды (или проверяющего коммиты) могут возникнуть вопросы или замечания. Хотите внести какие-то изменения? Сейчас — самое время. Сразу по завершению изменений участники проекта смогут развертывать эти изменения напрямую из ветки и проводить конечное тестирование до слияния с master . Вы также сможете произвести развертку изменений для проверки их в рабочей среде.
После утверждения изменений необходимо произвести слияние вашего кода с веткой master . В Pull request хранится запись о ваших изменениях. Таким образом, вы всегда сможете открыть этот запрос и понять, какие изменения были сделаны и почему.
Обновление и слияние
Если вы хотите работать с самой свежей версией репозитория на локальном компьютере, то можно получать изменения с GitHub через git pull . Для обновления локального репозитория до последнего коммита выполните в рабочей директории следующую команду:
git pull
Для слияния какой-то ветки с вашей активной веткой воспользуйтесь:
git merge
Git старается автоматически сливать изменения, однако это не всегда возможно. Иногда возникают конфликты слияния. Если такое произошло, то необходимо разрешить конфликт слияния вручную. После внесения нужных изменений отметьте их в качестве «объединенных» или «слитых» через git add . Просмотреть изменения до слияния можно по команде:
git diff
Перейти к ветке master можно через:
git checkout master
После слияния последних изменений обязательно удалите эту ветку через команду:
git branch -d new_feature
Другие пользователи не увидят вашу ветку, пока она не будет отправлена на удаленный репозиторий. Для отправки ветки в репозиторий выполните следующую команду:
git push origin
Подборка полезных команд
Для начала, вот вам шпаргалка по GitHub, где перечислены все самые полезные Git-команды.
Просмотр истории коммита в репозитории:
git log
Просмотр коммитов одного пользователя:
git log — author=
Просмотр непроиндексированных изменений:
git diff
Сложно запомнить нужные команды? Получите подсказку из 21 самой популярной команды:
git help
Либо почитайте разъяснения по использованию определенных команд. Например, вот эта команда показывает, как пользоваться clone :
git help clone
Практическое задание
Давайте потренируемся, а заодно и поприветствуем всех, кто знакомится с Git и GitHub. Мы создадим Стену для записей GitHub Wall, где изучающие Git и GitHub смогут оставлять комментарии и участвовать в своих первых open-source проектах.
На своей Стене вы можете разместить любые материалы. Главное — помните о вежливости и доброжелательности. Оставьте комментарий, добавьте какую-то картинку… да что угодно. Если вам сложно придумать приветственный текст, то можете взять готовый шаблон из README-файла (ссылку см. ниже).
- Клонируйте мой репозиторий на сайте GitHub или по команде
- Создайте новую ветку, добавьте файл welcome_wall.md с какой-нибудь мотивирующей цитатой. Это можно сделать на сайте GitHub. Но куда интереснее склонировать репозиторий на свой компьютер, открыть файл в любимом текстовом редакторе и вписать там нужный комментарий. Так знания лучше усвоятся.
- Создайте Pull request.
- Добавьте комментарий, описывающий суть изменений. Нажмите зеленую кнопку для отправки Pull request.
Поздравляю — вы успешно справились!
- Top 100 наиболее популярных репозиториев на GitHub
- Как создать бесплатный сайт на GitHub Pages
- Как стать продуктивнее на GitHub
Работа с ветками в Git (git branch)
Инструкция о том, как работать с ветками в Git. Расскажем, как закоммитить изменения и запушить в новую ветку, как удалить ветку или изменить ее — и это не все.
Эта инструкция — часть курса «Введение в Git».
Смотреть весь курс
Введение
Ветвление стало неотъемлемой частью командной разработки, потому что оно дает возможность работать над разными версиями исходного кода. Основной идеей ветвления является отклонение от основного кода и продолжение работы независимо от него. Также это удобно в тестировании отдельного функционала, потому что позволяет работать над новой частью кода, не беспокоясь о поломке чего-то в рабочей версии. В этой инструкции расскажем о том, как работать с ветками в Git.
Основные понятия: о ветке Git и master
Под веткой принято понимать независимую последовательность коммитов в хронологическом порядке. Однако конкретно в Git реализация ветки выполнена как указатель на последний коммит в рассматриваемой ветке. После создания ветки уже новый указатель ссылается на текущий коммит.
Имя основной ветки Git-проекта по умолчанию — master (однако зачастую бывает main, например, в GitHub), она появляется сразу при инициализации репозитория. Эта ветка ничем не отличается от остальных и также ее можно переименовать, но по договоренности master принято считать главной веткой в проекте.
Что делает git branch
Команда git branch — главный инструмент для работы с ветвлением. С ее помощью можно добавлять новые ветки, перечислять и переименовывать существующие и удалять их.
Способы создания веток и переключения между ними
Чтобы в Git добавить ветку мы используем:
$ git branch
После данной операции ветка уже была создана, но вы по-прежнему находитесь в прежней ветке. Если вы планируете переместиться на другую ветку, в том числе только что созданную, необходимо написать checkout:
$ git checkout
Для того чтобы определить, где сейчас находится разработчик, Git использует специальный указатель HEAD, ссылающийся на текущую локальную ветку. В результате checkout HEAD переместится на иную ветку.
Как с помощью git branch создать ветку и перейти в нее
Чаще всего при создании новой ветки git пользователю необходимо сразу же переключиться на нее. В таком случае стоит использовать:
$ git checkout branch
Это будет равносильно:
$ git branch
$ git checkout
И также мы получим тот же результат при использовании git checkout с ключом -b:
$ git checkout -b
Если пользователю нужно получить список определенного множества веток, то тогда можно воспользоваться ключами. Одними из самых распространенных будут:
- -r — при использовании этого ключа мы получим список удаленных веток,
- -a — используя этот параметр, в выводе будут удаленные и локальные ветки.
О команде git checkout
При выполнении этой команды Git требуется осуществить определенный порядок действий, чтобы переходить на ветку, которую мы указали. Для этого программа выполняет следующий алгоритм:
Проверка, что указанная нами ветка существует в проекте
Этот этап необходим, так как в ином случае программа не сможет переключиться на ветвь, которая не определена. Для большего понимания нужно вспомнить, что такое ветка в git. Учитываем, что фактически задание ветки — это запись коммита, на который она ссылается. Внутри Git наличие конкретной ветки проверяется наличием одноименного файла в конкретной директории.
Переключение указателя HEAD на новую ветку
Необходимо сместить указатель, чтобы Git понимал, где сейчас идет работа.
Изменение рабочей версии таким образом, чтобы новая ветка ей полностью соответствовала
Сама концепция работы ветвления заключается в том, что в разных ветках находятся разные версии кода, над которыми работа ведется отдельно друг от друга. Тогда необходимо изменить рабочую копию. Git берет последний коммит и восстанавливает все изменения.
После завершения всех перечисленных выше действий можно считать, что мы полностью переключились. Также с помощью checkout можно извлечь отдельный файл (или папку) из другой ветки и получить его, предварительно перейдя в ту ветку, куда вы собираетесь перенести файл. Для этого выполняем:
$ git checkout --
Основы ветвления и слияния
Ветвление позволяет разделять рабочий процесс, оптимизировать тестирование и написание нового кода. Однако после того, как разработчик убедился, что написанный им кусок кода готов и его можно отправить к остальной части итоговой версии, удобно переместить его в основную ветку. Такой подход дает возможность получить к концу разработки проекта целый продукт в одном месте.
Для этого в Git предусмотрено слияние — перенос изменений с одной ветки на другую. Однако сливаемая ветка (под этим определением мы подразумеваем ветку, у которой берем изменения для «вливания» их в другую ветвь) никак не меняется и остается в прежнем состоянии. Такие преобразования мы получаем, применив git merge:
$ git merge
Операция может привести к появлению конфликтов при попытке слить ветки. Это вызвано тем, что изменения удаляют или переписывают информацию в существующих файлах. При попытке некорректного слияния Git останавливает выполнение команды, чтобы вы могли разрешить конфликт.
Также стоит упомянуть о существовании ключей, предназначенных специально для работы с конфликтами:
- —abort — прерывает слияние и возвращает все к началу
- —continue — продолжает слияние после разрешения конфликта
Решить конфликт можно двумя способами:
- Вручную разрешить файловый конфликт. Для этого нужно самим изменить файлы, с которыми возникли проблемы. Мы получим файлы такими, какими и представляли их при попытке слияния.
- Выбрать более подходящий файл, а от второго отказаться.
Управление ветками с помощью git branch
Эта команда может немного больше, чем просто в git создавать ветки из текущей. Если запустить ее без параметров:
$ git branch
При выполнении этой строки мы получим список существующих веток, где символом * будет отмечена ветка, где вы сейчас находитесь. Это может выглядеть так:
first_branch * master second_branch
С помощью параметра -v можно получить последний сохраненный коммит в каждой ветке.
$ git branch -v first_branch 8fa301b Fix math * master 225cc2d Merge branch 'first_branch' second_branch c56ee12 Refactor code style
Так же существуют опции —merged и —no-merged, с помощью которых можно отфильтровать полученную последовательность веток. То есть мы получим список ответвлений, которые уже были слиты, или, наоборот, ветки, которые еще не прошли через слияние с другими. Выведем ветки, которые уже были слиты с текущей:
$ git branch --merged first_branch * master
Как закоммитить изменения в новую ветку
После создания новой ветки, перехода в нее и совершения всех запланированных преобразований, нужно сделать коммит в эту же ветку, чтобы сохранить все изменения. Команды для выполнения этих действий ничем не отличаются от команд для создания коммитов в ветке мастер.
$ git add
$ git commit -m ''
После выполнения последовательности этих команд мы закоммитили изменения в нужной версии программы.
Как запушить в новую ветку
Если мы хотим запушить нашу ветку, то для этого нужно написать:
$ git push origin
Теперь ветка запушена. Если до этого мы уже пушили ее, то произойдет отправка новых коммитов.
В отличии от команды git checkout, при выполнении пуша нет проверки на существование указанной ветки. Это будет значить, что при написании несуществующей ветки git создаст ее автоматически.
Как переименовать ветку
В процессе разработки могут возникнуть ситуации, когда человек хочет по-другому называть уже созданную ветку. Это может быть связано с разными причинами (например, разрабатываемый в данной версии функционал не соответствует названию). Чтобы переименовать ветку применяем:
$ git branch -m
Однако здесь нужно быть аккуратными, чтобы не перегрузить проект ненужными ветками. Если запушить переименованную ветку, то на сервере появится ветка с новым именем, но и ветка со старым названием тоже останется. Чтобы избежать такой проблемы, необходимо удалить ветку локально и на сервере.
Как удалить ветку
Удаление веток не такой простой процесс, как может показаться. Можно случайно удалить несохраненные изменения в исходном коде, что приведет к нежелательным последствиям. Поэтому здесь нужно действовать осторожно. С операцией удаления над ветками справляется уже привычная команда git branch с параметром -d:
$ git branch -d
Для корректного удаления нужно помнить несколько правил, чтобы не получить ошибки:
- Нельзя удалить ветку, в которой вы находитесь. Git выкинет ошибку и не произведет удаление. Следовательно, нужно перейти на другую ветку.
- Git не позволит удалить ветку, у которой есть несохраненные изменения. Так мы избегаем ситуации, когда часть написанного кода будет безвозвратно утеряна. Если же мы уверены, что изменения в этой версии не нужны и их можно смело удалять, то вместо флага -d используем -D:
$ git branch -D
Соблюдая все условия, нам удастся удалить указанную ветвь.
Работа с ветками на практике
В инструментах для разработки на языках часто есть встроенный функционал, позволяющий работать напрямую с Git. Например, в таких средах разработки как IntelliJ IDEA, PyCharm, PhpStorm, CLine, Rider очень удобно и понятно, как правильно оперировать с разными ветками. Для примера разберем работу в одной из таких сред.
Как работать с ветками в PhpStorm
Справа в нижнем углу расположены вкладки для работы с Git, где и происходит вся настройка ветвления. На этой панели расположено название текущей ветки. При желании создать новую нужно нажать на этот пункт и выбрать New Branch. Для смены ветки — выбрать из списка искомую и кликнуть на Checkout. Для удаления и переименования предусмотрены кнопки Delete и Rename соответственно.
Работа в специальном приложении почти ничем не отличается от работы в консоли, поэтому все полученные знания можно применять независимо от выбранного способа.
Получение информации о состоянии веток
Как просмотреть состояния файлов ветки
Отметим, что при переходе на другую версию, незакоммиченные изменения перенесутся на ветку, куда мы перейдем. Поэтому перед переключением необходимо убедиться, что изменения в текущей ветки уже закоммичены. Для этого подходит git status:
$ git status
Выполнение этой операции позволит просмотреть файлы, расположенные в ветке, где мы находимся. Как раз с помощью нее можно отслеживать незакоммиченные изменения, чтобы случайно не перенести их в другое место. Пустой вывод этой команды показывает то, что в ветке не присутствуют измененные файлы и мы можем без опасений продолжать с ней работу. А иначе необходимо закоммитить все нужные исправления.
Как просмотреть истории коммитов ветки
Неоднократно в процессе разработки нужно посмотреть на журнал изменений: для отслеживания развития проекта или для определения коммита, к которому следует вернуться. В таких ситуациях выручает команда git log:
$ git log --
У данной команды есть множество ключей, используя которые можно получить более конкретную информацию:
- — (равноценно -n= ) — показывает последние n коммитов,
- —pretty= (доступные такие значения, как oneline, short, medium, full и другие) ****— форматированный вывод истории,
- -p — выводятся изменения, содержащиеся в коммите,
- —graph — представляет дерево взаимосвязей коммитов в виде ASCII-графа — такой метод использования позволяет получить графическое представление ветвей прямо в консоли,
- —all — на выходе мы получаем историю всех коммитов для всех существующих веток,
- —decorate — показывает, на что ссылаются указатели.
Если нам нужно посмотреть историю для конкретной ветви, то поможет выполнение:
$ git log ..
Структура веток в Git представлена в виде графа. Когда мы получаем коммиты определенной ветки, передвигаясь «вверх» по графу, мы должны остановиться в тот момент, когда дойдем до коммита, который будет меньше указателя родителя ветки. При выполнении этого условия когда ветка, чья история коммитов нас интересует, добирается до своего родителя, вывод прекращается, и мы получаем корректный ответ.
Как просмотреть различия между коммитами
Достаточно часто в ходе разработки какого-либо продукта у разработчика может возникнуть потребность посмотреть разницу между двумя коммитами, прежде чем заливать что-то. Для этого существует git diff:
$ git diff
Для этой операции также предусмотрены несколько ключей:
- —diff-filter= — с помощью этого параметра, изменяя значения меток, можно задать, обновления между какими файлами мы хотим увидеть. Рассмотрим некоторые возможные значения меток:
- D — покажет удаленные файлы,
- M — мы получим файлы, модифицированные после последнего коммита.
Заключение
Git обладает множеством преимуществ по сравнению с другими системами контроля версий как раз из-за легковесной работы с ветвлением. Такая гибкость помогает максимально оптимизировать процесс разработки. А само ветвление сильно упрощает разработку проекта. Ветки обеспечивают безопасный совместный доступ к коду для разных людей. Ведь именно они дают возможность пластично и изящно работать над созданием нового продукта.
Как установить Git на Windows