Начало работы с Github на компьютере с Windows

Если вы разработчик, сотрудничающий с командой, вы знаете важность систем контроля версий исходного кода. Отслеживание изменений и дополнений в проекте через членов команды становится необходимым. Несмотря на то, что Microsoft Team Foundation Server остается инструментом выбора в сообществе разработчиков Microsoft, некоторые, возможно, захотят выбрать легковесную и не требующую обслуживания (или даже бесплатную) систему контроля версий.

Git – это один из инструментов, который вы можете использовать в таком сценарии. Github – это популярный сервис, который предлагает бесплатные публичные Git-репозитории (популярные для проектов с открытым исходным кодом) и премиальные частные Git-репозитории. Поэтому, по сути, вам не нужно обслуживать сервер контроля версий собственными силами.

Github Tutorial

Давайте кратко рассмотрим, как получить настройки учетной записи Github и готовые к использованию для проектов на вашем компьютере с Windows 10/8/7. Для начала войдите на github.com или создайте новую учетную запись, если у вас ее еще нет. После этого вы увидите страницу приветствия, показанную ниже.

Перейдите в «Настройка Git» и загрузите установщик Github для Windows. Эта онлайн-установка также включает в себя оболочку Git, поэтому вам не нужно устанавливать ее отдельно.

Нажмите «Установить» в приглашении Установить приложение, чтобы запустить онлайн-установщик. Онлайн установщик загружает около 38 МБ файлов.

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

Сконфигурируйте вашу локальную установку Git с вашими данными пользователя – (полное имя и адрес электронной почты), которые будут использоваться при фиксации ваших репозиториев.

После этого вы можете создавать и добавлять репозитории в свой новый Git-клиент. Чтобы создать новый репозиторий, нажмите «Добавить».

Введите имя и описание для нового репо и выберите местоположение файла для репо, который будет создан. Выберите опцию «Push to Github», так как мы хотим также хранить наш репозиторий в Интернете.

Пустой репозиторий создан. В левой части экрана вы увидите подсказку, в которой будет указано, что файл «Read me» не включен. Итак, давайте добавим readme к нашему репозиторию Git. Это файл, который отображается на главном экране вашего хранилища на Github; как тот, который вы увидите здесь.

Откройте Блокнот и введите следующий текст.

Сохраните этот файл как «Readme.md» в репозитории Git в ранее выбранном месте.

Откройте репозиторий на клиенте Github. Клиент будет отражать изменения, то есть новые файлы, добавленные в репо. Иногда вам может потребоваться закрыть и снова открыть репозиторий, чтобы изменения отразились. Хотя клиент автоматически добавляет изменения в репозиторий, вы должны зафиксировать изменения с соответствующим описанием в репозитории, как показано на рисунке ниже.

Как только вы добавите коммит, репозиторий автоматически начнет синхронизироваться. Чтобы просмотреть репозиторий на Github, нажмите Инструменты> Вид на Github.

Теперь, когда у вас есть онлайн-репозиторий Github, вы можете свободно изменять и добавлять файлы в репозиторий. Разместить коммиты и позволяет клиенту Github синхронизировать его для вас. Кроме того, вы также можете начать извлекать репозитории из Github.

Новый Github Desktop

Github выпустил обновленную версию Github Desktop — программы под Windows 7+ и OS X, которая дублирует функциональность сайта github.com, но при этом работает локально на компьютере разработчика.

Github Desktop упрощает многие действия в рабочем процессе и заменяет Github for Mac и Github for Windows на новый унифицированный интерфейс.

Ветви

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

Совместная работа

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

Прямо из программы отправляются и пул-реквесты.

Слияние и развертывание

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

Просмотр истории

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

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

GitHub Desktop

Описание программы

GitHub Desktop — это клиент одноименного веб-сервиса для Windows, которым пользуются большинство разработчиков. Сервис позволяет создавать репозитории, в которых содержаться все файлы программного продукта, а в дальнейшем разработчик может поддерживать свой код, обновлять версии и взаимодействовать с пользователями.

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

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

Преимущества и недостатки

• Современный интерфейс
• Обширный функционал для работы с проектами
• Поддержка множества языков программирования
• Возможность совместной работы
• Система контроля версий

• Сложно использовать (для новичков)
• Ограниченные возможности в бесплатной версии сервиса

Функции и особенности

Скриншоты

Скриншоты интерфейса и рабочих окон GitHub Desktop.

Как пользоваться

Видео инструкция по использованию и настройке GitHub Desktop.

Скачать бесплатно

Скачайте последнюю версию GitHub Desktop (2.2.4) по прямой ссылке с нашего сайта. Программа совместима с операционными системами Windows 10, 8, 7 разрядностью 32/64-bit. Данный программный продукт распространяется условно-бесплатно, а его интерфейс доступен на английском языке. Также вы можете скачать программу по ссылке с официального сайта.

• 2.2.4
• 87.3 Мб
• 478

Безопасная загрузка файла с нашего сервера!

Отзывы

Отзывов о GitHub Desktop пока нет. Добавите первый?

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

Введение в 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. Без изменений — одна версия файла во всех разделах, т. е. в последнем коммите содержится актуальная версия.

Примечание Файл может быть одновременно в состоянии «изменён» и «подготовлен», если версия в рабочей директории новее, чем в области подготовленных файлов, которая в свою очередь новее версии в HEAD.

Мы можем использовать опцию -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 мы не только загружаем себе копию репозитория, но и неявно отслеживаем удалённый сервер, который находится по указанному адресу и которому присваивается имя origin.

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

• git remote add — добавляет удалённый репозиторий с заданным именем;
• git remote remove — удаляет удалённый репозиторий с заданным именем;
• git remote rename — переименовывает удалённый репозиторий;
• git remote set-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 выбранного коммита (то есть разницу между этим коммитом и предыдущим), но не его состояние.