При помощи какой команды можно отправить изменения

Основы работы с Git

Для чего нужен Git, и что вообще такое система контроля версий? Система контроля версий – это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая вернуться позже к определенной версии. Проще говоря, в случае изменения файла будет отмечен файл и место изменения, также можно отменить введенные ранее изменения файла, увидеть, кто последний менял что-то и вызвал проблему и когда, и многое другое. Если вы сломали что-то или потеряли файлы, это спокойно можно исправить.

Одной из таких систем является Git. На данный момент она наиболее распространена по ряду причин:

• Бесплатная и с открытым кодом
• Быстрая
• Простое ветвление
• Резервное копирование

Для git-репозиториев предоставляются хостинги, например: GitHub, Codebase, Bitbucket, GitLab и др.

2 . Основные команды:

Команда	Описание команды
git init	создание нового репозитория
git status	просмотр статуса текущих файлов
git add	добавление изменений и новых файлов в текущую директорию
git add file.py	добавление файла file.py
git .add	добавление всех изменений
git commit	создание нового коммита
git commit -m ’text’	создание коммита с названием text
git branch	показывает список всех веток
git branch -v	показает список веток и последний коммит в каждой
git branch name	создает новую ветку name
git branch -D name	удаляет ветку name
git checkout	переключение между последними коммитами
git checkout file	вернуть file в состояние последнего коммита
git config	конфигурация и параметры git
git config –global user.name	показывает имя пользователя
git config –global user.name ‘New name’	изменяет имя пользователя
git config –global user.email	показывает email пользователя
git config –global user.email ’name@gmail.com’	изменяет email пользователя
git push	загрузка локальных коммитов в удаленный репозиторий
git pull	загружает изменения с удаленного репозитория в локальный
git clone	клонирование проекта из удаленного репозитория

3 . Словарь

Бранч

Ветка или копия проекта, в которую можно вносить любые изменения, они не повлияют на основной проект.

Способ хранения файлов и их версий.

Клонирование

Копирование репозитория на жесткий диск.

Коммит

Набор с изменениями (измененными, новыми и добавленными файлами), записанный в локальный репозиторий.

Отправка изменений на сервер.

Долганов Ян Львович

Студент по направлению “Прикладная информатика”

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

© 2023 Me. This work is licensed under CC BY NC ND 4.0

Published with Wowchemy — the free, open source website builder that empowers creators.

Что такое git push и как его использовать

В инструкции рассказываем о наиболее частых сценариях использования git push.

Эта инструкция — часть курса «Введение в Git».

Смотреть весь курс

Введение

Команда Git push позволяет отправлять локальную ветку на удаленный репозиторий. Она помогает разработчикам синхронизироваться в команде, а именно отправляет проделанные изменения. Если программист работает один, то пуш позволяет хранить код в облаке, например github, gitlab и не только, избавляя от риска потери данных на компьютере.

Дополнительно для синхронизации еще используют git pull для получения изменений с сервера и git remote, чтобы получить список удаленных подключений к репозиторию.

В этой инструкции мы расскажем, как запушить в удаленный git репозиторий. В статье под «пушем» будем подразумевать git push.

Отправка изменений в чистый репозиторий

Перед пушем надо связать локальный и удаленный репозитории. Делается это при помощи команды:

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

Вместо link — ссылка на удаленный репозиторий, она может выглядеть по-разному в зависимости от того используется ssh или https.

Для ssh, который обязателен для github и gitlab, потребуются сделать дополнительные манипуляции для создания ssh-ключа. Соответствующие инструкции есть на этих ресурсах.

Отправка изменений

Перед пушем надо зафиксировать текущие изменения, то есть сделать git commit.

Далее для отправки в терминале пишем:

Вместо branch — имя ветки, которую надо отправить. Чаще всего используется master или main:

Такое каждый раз писать слишком громоздко, для этого придумали git push по умолчанию. Для этого единожды набираем предыдущую команду с флагом -u:

После этого можно писать более коротко, так как git запомнил, что пушить надо на сервер origin ветку под именем master:

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

Дополнительные опции публикации

Отправка ветки на сервер в ветку с другим именем

Для того чтобы сделать git push в другую ветку, есть специальный синтаксис, где после имени ветки через двоеточие пишется имя удаленной ветки:

где branch – имя локальной ветки, server_branch – имя удаленной ветки на сервере.

Отправка всех веток на сервер

Вместо имени ветки пишем флаг —all:

После этого все зафиксированные изменения в ветках отправятся в удаленный репозиторий.

Отправка текущей ветки

Удобный способ отправить текущую ветку с тем же именем на сервере.

HEAD указывает на текущую ветку (current branch). Тем самым, не надо запоминать имя ветки, на которой вы находитесь.

Принудительная публикация (git push —force …)

При отправке может произойти ошибка публикации:

Это так называемый git push rejected, он означает что пуш был отклонен. Правильнее всего — сделать то, что написано в подсказке к ошибке. Надо получить и смержить изменения, затем снова отправить.

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

Флагом —force или сокращенной его версией -f отключается проверка коммитов и при необходимости выполняется перезапись истории.

Нужно быть аккуратными с этой командой, так как она стирает работу других людей. Эта команда оправдана лишь изредка, например, если вы почти сразу внесли изменения коммита с помощью git commit —amend и запушили до того, как кто-то сделал git pull.

Принудительная публикация с параметром (git push —force-with-lease …)

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

Принудительная публикация с этим параметром чревата появлением git push rejected у других людей

Как пушить в PhpStorm

При первом открытии PhpStorm потребуется создать новый проект.

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

Синяя стрелка означает git pull, зеленая галочка — git commit, зеленая стрелка — git push. При нажатии на зеленую стрелку (горячие клавиши Ctrl+Alt+K или ⌥ ⌘ K) открывается диалоговое окно с информацией об изменениях и настроках отправки.

Незапушенные коммиты

Самый простой способ узнать про них при помощи команды:

Вывод будет содержать имя текущей ветки и то, насколько она опережает версию сервера. Пример вывода:

Для более подробной информации можно использовать:

Будет выведена история коммитов:

В скобках пишется где и какой коммит расположен.

HEAD -> master означает что текущая ветка (current branch) — это master и это последний локальный коммит в ней.

В нижнем коммите в скобках origin/master означает, что это последний опубликованный коммит на сервере в ветке master, а origin/HEAD, что коммит расположен на ветке, которая совпадает с локальной веткой HEAD.

Как пушить теги

Для создания тегов используют git tag, а для их отправки:

Вместо tag_name — имя тега, который надо удалить на сервере.

Также можно сделать отправку всех тегов:

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

Удаление ветки или тега на сервере

Чтобы удалить ветку на удаленном репозитории, используем уже привычную команду с флагом —delete:

remote_branch_or_tag_name — имя ветки или тега на сервере.

Для удаление локальной ветки:

А для удаления локального тега:

Продвинутые возможности

Удаление локальных данных (prune)

Если на сервере была удалена ветка, то локально она все еще существует. Чтобы удалить все локальные ветки, которых нет на сервере:

Проверить, удастся ли пушинг (dry run option)

С этой опцией пушинг фактически не произойдет, но покажет вывод словно он произошел.

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

Атомарный пушинг (atomic option)

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

Заключение

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

Git rebase — перебазирование коммитов и веток

Что такое GitLab, как и для чего он используется

Зарегистрируйтесь в панели управления

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

Основные команды для работы с Git

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

☝ В некоторых командах мы будем писать URL-адрес удалённого репозитория и название проекта в квадратных скобках, вот так — [ссылка на удалённый репозиторий] . Мы делаем это только для наглядности. Вам квадратные скобки ставить не нужно.

Первоначальная настройка Git

Работа с любой программой всегда начинается с её настройки. Git можно настроить один раз и менять что-то только по мере необходимости.

Указать имя пользователя — git config —global user.name «Ivan Ivanov» . Задаёт имя пользователя, от которого будут идти коммиты. Вместо Ivan Ivanov нужно написать свои данные на латинице. Если имя состоит из одного слова, кавычки можно не ставить.

Указать электронную почту — git config —global user.email «mail@gmail.com» . Вместо mail@gmail.com нужно указать вашу почту. Обратите внимание, она должна совпадать с той, на которую зарегистрирован аккаунт в Гитхабе.

Посмотреть настройки — git config —list . Параметры можно посмотреть и в конфигурационном файле, но этот способ быстрее.

Работа с репозиторием

Создать репозиторий — git init . Инициализирует пустой репозиторий.

Склонировать удалённый репозиторий — git clone [ссылка на удалённый репозиторий] . Проект появится в директории, где вы находились в момент клонирования.

Связать удалённый и локальный репозитории — git remote add origin [ссылка на удалённый репозиторий] .

Работа с изменениями

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

Подтянуть изменения — git pull . Подтягивает в локальный репозиторий последнюю версию проекта. Будьте внимательны, вызов этой команды сотрёт все незафиксированные изменения. Иногда после ввода этой команды появляется конфликт.

Посмотреть статус файлов — git status . Вы увидите, какие файлы изменили, удалили или добавили в проект. При этом статус «Закоммичен» не отобразится.

Добавить файлы в индекс — git add [название файла] . После ввода этой команды вы можете сделать коммит.

Есть похожие команды, например, git add . индексирует сразу все изменённые файлы и папки в директории, где вы находитесь. Обратите внимание, между точкой и словом add нужно ставить пробел. Команда git add :/ добавляет в индекс все файлы независимо от того, в какой директории вы находитесь.

Сделать коммит — git commit -m «Комментарий к коммиту» — фиксирует изменения. До выполнения этой команды локальные изменения никуда не запишутся.

Нужно правильно разбивать изменения и давать полные комментарии к коммитам. Подробнее об этом читайте в статье «Как оформлять коммиты».

Посмотреть историю коммитов — git log . Выводит список всех коммитов. У этой команды есть разные опции, самая используемая из них — —oneline . Она показывает хеш в укороченном формате, ветку, в которой сделан коммит, а также текст коммита. Чтобы использовать эту опцию (как и любую другую), нужно добавить её после команды: git log—oneline .

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

Работа с ветками

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

☝ Здесь мы для примера используем branch-name. Вам при вводе команды нужно указать название вашей ветки.

Создать ветку — git switch —create branch-name . Добавляет новую ветку с названием branch-name и автоматически переключает на неё.

Переключить ветку — git switch branch-name . Вы перейдёте на уже созданную ветку branch-name .

Для создания и переключения веток также можно использовать git checkout . Эта команда появилась раньше, у неё есть множество дополнительных функций. Например, она может восстанавливать изменения в коммите. Как раз из-за такого разнообразия задач разработчики решили создать отдельную команду для переключения между ветками — git switch . Вы можете использовать любую из команд, однако git switch доступна только в версиях от 2.23.

Посмотреть все локальные ветки — git branch .

Переименовать ветку — git branch -m [старое-название-ветки] [новое-название-ветки] — переименовывает ветку. Названия нужно писать на латинице.

Отправить ветку — git push origin [branch-name] — отправляет ветку в удалённый репозиторий.

Удалить ветки — git branch —delete [branch-name] . Команда удаляет ветку [branch-name] в локальном репозитории. Если нужно избавиться от ветки в удалённом репозитории, используйте git push —delete origin [branch-name] .

Влить ветки — git merge [branch-name] . Вливает ветку branch-name в ветку, в которой вы находитесь.

Перебазировать коммиты — git rebase [branch-name] . Перебазирует коммиты из ветки, в которой вы находитесь, в ветку [branch-name] .

Создать точную копию коммитов — git cherry-pick . Команду часто совмещают с git merge и git rebase , чтобы сохранить линейную историю коммитов. То есть создаётся точная копия коммитов, выполняется перебазирование и слияние веток.

Откладывание и удаление

Отложить изменения — git stash push . Откладывает изменения, чтобы вы, например, могли срочно перейти к другой задаче. Чтобы отложить только часть изменений, используйте git stash —patch .

Вернуть отложенные изменения — git stash pop .

Отменить изменения, не добавленные в индекс — git restore [название файла] . Удалит изменения в одном файле. Чтобы удалить изменения во всех файлах, используйте git restore :/ .

Отменить изменения, добавленные в индекс — git reset —hard . Возвращает изменения из индекса и полностью их отменяет.

Удалить коммит — git revert [195dfb0] . Вместо [195dfb0] указывается хеш коммита, его можно узнать с помощью команды git log .

Отменить слияние с конфликтом — git merge —abort . Используется, когда нет времени решать конфликт прямо здесь и сейчас.

Удалить лишнее — git clean . Команда «наводит чистоту» — удаляет неотслеживаемые файлы из рабочего каталога.

Больше информации о работе с Git и практические навыки вы получите на курсе о Git и GitHub.

Введение в Git: от установки до основных команд

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

Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.

Основы Git

Git — это система контроля версий (VCS), которая позволяет отслеживать и фиксировать изменения в коде: вы можете восстановить код в случае сбоя или откатить до более ранних версий. А ещё это must-have инструмент для взаимодействия нескольких разработчиков на одном проекте. Подробнее об этом в руководстве по командной разработке с Git.

С Git работают через командную строку или инструменты вроде GitHub Desktop. Команды Git принимают вид git <команда> <аргументы> , где аргументом может быть путь к файлу. В команды также включаются опции, которые обозначаются как —<опция> . Забыли, как использовать команду? Откройте руководство с git help <команда> .

Установка Git

Введение в Git всегда начинается с установки: скачайте Git для Windows, macOS или Linux и проверьте версию с помощью git —version .

Настройка конфигурационного файла

Первое, что нужно сделать, — настроить имя пользователя и email для идентификации. Эти настройки хранятся в конфигурационном файле.

Вы можете напрямую отредактировать файл .gitconfig в текстовом редакторе или сделать это командой git config —global —edit . Для отдельных полей это git config —global <поле> <значение> — поля user.name и user.email .

Также можно настроить текстовый редактор для написания сообщений коммитов, используя поле core.editor . А вот поле commit.template позволяет указать шаблон, который будет использоваться при каждом коммите. Ещё одно полезное поле — alias , которое привязывает команду к псевдониму. Например, git config —global alias.st «status -s» позволяет использовать git st вместо git status -s

Команда git config —list выведет все поля и их значения из конфигурационного файла.

Создаём Git-репозиторий

Для инициализации нового репозитория .git подойдёт git init или, если хотите скопировать существующий, git clone <адрес репозитория> .

Коммиты

Основы работы с Git предполагают понимание коммитов. Команда git commit откроет текстовый редактор для ввода сообщения коммита. Также эта команда принимает несколько аргументов:

• -m позволяет написать сообщение вместе с командой, не открывая редактор. Например git commit -m «Пофиксил баг» ;
• -a переносит все отслеживаемые файлы в область подготовленных файлов и включает их в коммит (позволяет пропустить git add перед коммитом);
• —amend заменяет последний коммит новым изменённым коммитом, что бывает полезно, если вы неправильно набрали сообщение последнего коммита или забыли включить в него какие-то файлы.

Советы для эффективного введения в Git:

• Коммитьте как можно чаще.
• Одно изменение — один коммит: не помещайте все не связанные между собой изменения в один коммит, разделите их, чтобы было проще откатиться.
• Формат сообщений: заголовок должен быть в повелительном наклонении, меньше 50 символов в длину и должен логически дополнять фразу this commit will ___ (this commit will fix bugs — этот коммит исправит баги). Сообщение должно пояснять, почему был сделан коммит, а сам коммит показывает, что изменилось.
• Если у вас много незначительных изменений, хорошим тоном считается делать небольшие коммиты при разработке, а при добавлении в большой репозиторий объединять их в один коммит.

История коммитов в Git

Коммиты хранят состояние файловой системы в определённый момент времени и указатели на предыдущие коммиты. Каждый коммит содержит уникальную контрольную сумму — идентификатор, который Git использует, чтобы ссылаться на коммит. Чтобы отслеживать историю, Git хранит указатель HEAD, который указывает на первый коммит (мы следуем по цепочке коммитов в обратном порядке, чтобы попасть к предыдущим коммитам).

Мы можем ссылаться на коммит либо через его контрольную сумму, либо через его позицию относительно HEAD, например HEAD

4 ссылается на коммит, который находится 4 коммитами ранее HEAD.

Файловая система Git

Git отслеживает файлы в трёх основных разделах:

• рабочая директория (файловая система вашего компьютера);
• область подготовленных файлов (staging area, хранит содержание следующего коммита);
• HEAD (последний коммит в репозитории).

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

Просмотр изменений в файловых системах

Команда git status отображает все файлы, которые различаются между тремя разделами. У файлов есть 4 состояния:

1. Неотслеживаемый (untracked) — находится в рабочей директории, но нет ни одной версии в HEAD или в области подготовленных файлов (Git не знает о файле).
2. Изменён (modified) — в рабочей директории есть более новая версия по сравнению с хранящейся в HEAD или в области подготовленных файлов (изменения не находятся в следующем коммите).
3. Подготовлен (staged) — в рабочей директории и области подготовленных файлов есть более новая версия по сравнению с хранящейся в HEAD (готов к коммиту).
4. Без изменений — одна версия файла во всех разделах, т. е. в последнем коммите содержится актуальная версия.

Мы можем использовать опцию -s для команды git status , чтобы получить более компактный вывод (по строке на файл). Если файл не отслеживается, то будет выведено ?? ; если он был изменён, то его имя будет красным, а если подготовлен — зелёным.

Чтобы посмотреть сами изменения, а не изменённые файлы, можно использовать следующие команды:

• git diff — сравнение рабочей директории с областью подготовленных файлов;
• git diff —staged — сравнение области подготовленных файлов с HEAD.

Если использовать аргумент <файл/папка> , то diff покажет изменения только для указанных файлов/папок, например git diff src/ .

Обновление файловых систем

Команда git add <файл/папка> обновляет область подготовленных файлов версиями файлов/папок из рабочей директории.

Команда git commit обновляет HEAD новым коммитом, который делает снимки файлов в области подготовленных файлов.

Действие команды git reset <коммит> состоит из трёх потенциальных шагов:

1. Переместить указатель HEAD на <коммит> (например, при откате коммита в рабочей директории и области подготовленных файлов будут более новые версии файлов, чем в HEAD). Также указатель HEAD ветки будет перемещён на этот коммит.
2. Обновить область подготовленных файлов содержимым коммита. В таком случае только в рабочей директории будут новейшие версии файлов.
3. Обновить рабочую директорию содержимым области подготовленных файлов. С этим нужно быть осторожнее, поскольку в итоге будут уничтожены изменения файлов.

По умолчанию команда git reset выполняет только шаги 1 и 2, однако её поведение можно изменить с помощью опций —soft (только 1 шаг) и —hard (все шаги).

Если передать путь к файлу/папке, то команда будет выполнена только для них, например git reset —soft HEAD

Команда git checkout HEAD <файл> приводит к тому же результату, что и git reset —hard HEAD <файл> — перезаписывает версию файла в области подготовленных файлов и в рабочей директорией версией из HEAD, то есть отменяет изменения после последнего коммита.

С другой стороны, git checkout <файл> (уже без HEAD) перезаписывает версию файла в рабочей директории версией в области подготовленных файлов, то есть отменяет изменения с момента последней подготовленной версии.

Наконец, git rm <файл> отменяет отслеживание файла и удаляет его из рабочей директории, опция —cached позволит сохранить файл.

Игнорирование файлов

Зачастую нам не нужно, чтобы Git отслеживал все файлы в репозитории, потому что в их число могут входить:

• файлы с чувствительной информацией вроде паролей;
• большие бинарные файлы;
• файлы сборок, которые генерируются после каждой компиляции;
• файлы, специфичные для ОС/IDE, например, .DS_Store для macOS или .iml для IntelliJ IDEA — нам нужно, чтобы репозиторий как можно меньше зависел от системы.

Для игнорирования используется файл .gitignore . Чтобы отметить файлы, которые мы хотим игнорировать, можно использовать шаблоны поиска (считайте их упрощёнными регулярными выражениями):

• /___ — позволяет избежать рекурсивности — соответствует файлам только в текущей директории;
• __/ — соответствует всем файлам в указанной директории;
• *___ — соответствует всем файлам с указанным окончанием;
• ! — игнорирование файлов, попадающих под указанный шаблон;
• [__] — соответствует любому символу из указанных в квадратных скобках;
• ? — соответствует любому символу;
• /**/ — соответствует вложенным директориям, например a/**/d соответствует a/d , a/b/d , a/b/c/d и т. д.

Мы даже можем использовать шаблоны поиска при указании файла/папки в других командах. Например, git add src/*.css добавит все файлы .css в папке src .

Просмотр изменений

Для просмотра истории предыдущих коммитов в обратном хронологическом порядке можно использовать команду git log . Ей можно передать разные опции:

• -p показывает изменения в каждом коммите;
• —stat показывает сокращённую статистику для коммитов, например изменённые файлы и количество добавленных/удалённых строк в каждом их них;
• -n показывает n последних коммитов;
• —since=___ и —until=___ позволяет отфильтровать коммиты по промежутку времени, например —since=»2019-01-01″ покажет коммиты с 1 января 2019 года;
• —pretty позволяет указать формат логов (например, —pretty=oneline ), также можно использовать —pretty=format для большей кастомизации, например —pretty=format:»%h %s» ;
• —grep и -S фильтруют коммиты с сообщениями/изменениями кода, которые содержат указанную строку, например, git log -S имя_функции позволяет посмотреть добавление/удаление функции;
• —no-merges пропускает коммиты со слиянием веток;
• ветка1..ветка2 позволяет посмотреть, какие коммиты из ветки 2 не находятся в ветке 1 (полезно при слиянии веток). Например, git log master..test покажет, каких коммитов из ветки test нет в master (о ветках поговорим чуть позже).
• —left-right ветка1. ветка2 показывает коммиты, которые есть либо в ветке 1, либо в ветке 2, но не в обеих; знак < обозначает коммиты из ветка1 , а > — из ветка2 . Обратите внимание: используется три точки, а не две;
• -L принимает аргумент начало,конец:файл или :функция:файл и показывает историю изменений переданного набора строк или функции в файле.

Другой полезной командой является git blame <файл> , которая для каждой строки файла показывает автора и контрольную сумму последнего коммита, который изменил эту строку. -L <начало>, <конец> позволяет ограничить эту команду заданными строками. Это можно использовать, например, для выяснения того, какой коммит привёл к определённому багу (чтобы можно было его откатить).

Наконец, есть команда git grep , которая ищет по всем файлам в истории коммитов (а не только в рабочей директории, как grep ) по заданному регулярному выражению. Опция -n отображает соответствующий номер строки в файле для каждого совпадения, а —count показывает количество совпадений для каждого файла.

Примечание Не путайте git grep с git log —grep ! Первый ищет по файлам среди коммитов, а последний смотрит на сообщения логов.

Удалённые репозитории

Пока что мы обсуждали использование Git только на локальной машине. Однако мы можем хранить историю коммитов удалённых репозиториев, которую можно отслеживать и обновлять. git remote -v выводит список удалённых репозиториев, которые мы отслеживаем, и имена, которые мы им присвоили.

При использовании команды git clone <url репозитория> мы не только загружаем себе копию репозитория, но и неявно отслеживаем удалённый сервер, который находится по указанному адресу и которому присваивается имя origin.

Наиболее употребляемые команды:

• git remote add <имя> <url> — добавляет удалённый репозиторий с заданным именем;
• git remote remove <имя> — удаляет удалённый репозиторий с заданным именем;
• git remote rename <старое имя> <новое имя> — переименовывает удалённый репозиторий;
• git remote set-url <имя> <url> — присваивает репозиторию с именем новый адрес;
• git remote show <имя> — показывает информацию о репозитории.

Следующие команды работают с удалёнными ветками:

• git fetch <имя> <ветка> — получает данные из ветки заданного репозитория, но не сливает изменения;
• git pull <имя> <ветка> — сливает данные из ветки заданного репозитория;
• git push <имя> <ветка> — отправляет изменения в ветку заданного репозитория. Если локальная ветка уже отслеживает удалённую, то можно использовать просто git push или git pull .

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

GitHub

GitHub — это платформа, которая хранит Git-репозитории на своих серверах, и основы распределенной системы управления версиями Git подразумевает умение с ней работать. Вы можете хранить свои удалённые репозитории или участвовать в Open Source проектах на GitHub.

Да, есть и другие платформы, но GitHub идеален для введения в Git и дополняет VCS новыми возможностями.

Например, вы можете сделать форк удалённого репозитория, то есть создать свою копию репозитория на севере GitHub. Это полезно в тех случаях, когда у вас нет прав на создание ветки в оригинальном репозитории. Когда вы воспользуетесь командой git clone , ваш локальный репозиторий будет отслеживать удалённый форк как origin, а оригинальный репозиторий как upstream.

После этого вам может понадобиться слить тематическую ветку вашего удалённого репозитория в основную ветку оригинального. Для этого вы можете создать новый Pull Request — запрос на внесение изменений, где GitHub проверяет наличие конфликтов прежде чем повзолить вам провести слияние. Зачастую существуют и другие проверки перед слиянием, например просмотр и одобрение кода или даже запуск тестов. В запросе можно обсудить код, а все коммиты, которые вы отправляете в удалённую тематическую ветку, будут автоматически добавлены в запрос, даже если он был создан до этих коммитов.

Работа с ветками

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

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

• git branch <имя ветки> — создаёт новую ветку с HEAD, указывающим на HEAD. Если не передать аргумент <имя ветки> , то команда выведет список всех локальных веток;
• git checkout <имя ветки> — переключается на эту ветку. Можно передать опцию -b , чтобы создать новую ветку перед переключением;
• git branch -d <имя ветки> — удаляет ветку.

Локальный и удалённый репозитории могут иметь немало ветвей, поэтому когда вы отслеживаете удалённый репозиторий — отслеживается удалённая ветка ( git clone привязывает вашу ветку master к ветке origin/master удалённого репозитория).

Привязка к удалённой ветке:

• git branch -u <имя удалённого репозитория>/<удалённая ветка> — привязывает текущую ветку к указанной удалённой ветке;
• git checkout —track <имя удалённого репозитория>/<удалённая ветка> — аналог предыдущей команды;
• git checkout -b <ветка> <имя удалённого репозитория>/<удалённая ветка> — создаёт новую локальную ветку и начинает отслеживать удалённую;
• git branch —vv — показывает локальные и отслеживаемые удалённые ветки;
• git checkout <удалённая ветка> — создаёт локальную ветку с таким же именем, как у удалённой, и начинает её отслеживать.

В общем, git checkout связан с изменением места, на которое указывает HEAD ветки, что похоже на то, как git reset перемещает общий HEAD.

Прятки и чистка

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

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

Однако порой у вас есть незавершённые изменения, которые нельзя фиксировать. В такой ситуации их можно сохранить и «спрятать» с помощью команды git stash . Чтобы вернуть изменения, используйте git stash apply .

Возможно, вместо этого вы захотите стереть все внесённые изменения. В таком случае используйте команду git clean . Опция -d также удалит неотслеживаемые файлы. Совет: добавьте опцию -n , чтобы увидеть, что произойдёт при запуске git clean без непосредственного использования.

Слияние

Ветку, в которую мы хотим слить изменения, будем называть основной, а ветку, из которой мы будем их сливать, — тематической.

Слиние включает в себя создание нового коммита, который основан на общем коммите-предке двух ветвей и указывает на оба HEAD в качестве предыдущих коммитов. Для слияния мы переходим на основную ветку и используем команду git merge <тематическая ветка> .

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

После открытия таких файлов вы увидите похожие маркеры разрешения конфликта:

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

Перемещение

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

Для перемещения используется команда git rebase <основная ветка> <тематическая ветка> , которая воспроизводит изменения тематической ветки на основной; HEAD тематической ветки указывает на последний воспроизведённый коммит.

Перемещение vs. слияние

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

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

Перемещайте изменения только на вашей приватной локальной ветке — не перемещайте коммиты, от которых зависит ещё кто-то.

Откат коммитов — revert и reset

Похожие дебаты по поводу того, что лучше использовать, возникают, когда вы хотите откатить коммит. Команда git revert <коммит> создаёт новый коммит, отменяющий изменения, но сохраняющий историю, в то время как git reset <коммит> перемещает указатель HEAD, предоставляя более чистую историю (словно бы этого коммита никогда и не было). Важно отметить, что это также означает, что вы больше не сможете вернуться обратно к этим изменениям, например, если вы всё-таки решите, что отмена коммита была лишней. Чище — не значит лучше!

Продвинутое использование

На этом основное введение в Git заканчивается, и начинается более глубокое изучение.

Интерактивная подготовка

Вы можете с удобством управлять областью подготовленных файлов (например при фиксации нескольких небольших коммитов вместо одного большого) с помощью интерактивной консоли, которую можно запустить с git add -i . В ней есть 8 команд:

• status — показывает для каждого файла краткое описание того, что (не)подготовлено;
• update — подготавливает отслеживаемые файлы;
• revert — убрать один или несколько файлов из подготовленной области;
• add untracked — подготавливает неотслеживаемый файл;
• patch — подготавливает только часть файла (полезно, когда вы, например, изменили несколько функций, но хотите разбить изменения на несколько коммитов). После выбора файла вам будут показаны его фрагменты и представлены возможные команды: Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? . Можно ввести ? , чтобы узнать, что делает каждая команда;
• diff — показывает список подготовленных файлов и позволяет посмотреть изменения для каждого из них;
• quit — выходит из интерактивной консоли;
• help — показывает краткое описание каждой команды.

Символ * рядом с файлом означает, что команда изменит его статус (подготовлен/неподготовлен в зависимости от того, происходит ли обновление или откат). Если нажать Enter, не введя ничего ни в одном из под-меню команды, то все файлы перейдут в (не)подготовленное состояние. Создание патчей доступно в интерактивной консоли и через команду git add -p .

Правка истории

Для большего контроля над историей коммитов локальной ветки можно использовать команду git rebase -i HEAD

n , которая откроет интерактивную консоль для перемещения набора последних n коммитов, перечисленных в порядке от старых к новым (то есть в том порядке, в котором они будут перемещены). Таким образом вы можете «редактировать историю», однако помните, что оригинальные коммиты нельзя изменить, только переместить.

Вы можете поменять порядок коммитов, изменив порядок, в котором они перечислены.

Изменение сообщения/разбивка коммитов

Для указания коммита, который вы хотите изменить, используется команда edit . Затем, когда Git будет проводить перемещение, он остановится на этом коммите. После этого вы можете использовать git commit —amend , чтобы изменить сообщение или подготовить забытые файлы. Если вы хотите разделить коммит, после остановки введите git reset HEAD^ (в результате HEAD будет перемещён на один коммит назад и все изменённые в этом коммите файлы перейдут в статус неподготовленных). Затем вы сможете зафиксировать файлы в отдельных коммитах обычным образом.

После завершения редактирования введите git rebase —continue .

Перезапись нескольких коммитов

Иногда вам может потребоваться перезаписать несколько коммитов — в таких случаях можно использовать git filter-branch . Например, чтобы удалить случайно зафиксированный файл, можно ввести git filter-branch —tree-filter ‘git rm -f <имя файла>’ HEAD . Однако учтите, что при этом вся история перемещается.

Объединение нескольких коммитов

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

Перенос отдельного коммита

Кроме слияния/перемещения всех коммитов в тематической ветке, вас может интересовать только определённый коммит. Допустим, у вас есть локальная ветка drafts, где вы работаете над несколькими потенциальными статьями, но хотите опубликовать только одну из них. Для этого можно использовать команду git cherry-pick . Чтобы получить определённые коммиты, из которых мы хотим выбирать, можно использовать git log <основная ветка>..<тематическая> .

Обратите внимание, что таким образом создаётся новый коммит, который только повторяет diff выбранного коммита (то есть разницу между этим коммитом и предыдущим), но не его состояние.