Git restore staged что делает

Команда git-restore: опции, ключи и примеры использования

Общие команды – Общие команды, присущие различным операционным системам.

git restore

Restore working tree files. Requires Git version 2.23+. See also git checkout and git reset . More information: https://git-scm.com/docs/git-restore.

• Restore an unstaged file to the version of the current commit (HEAD):

• Restore an unstaged file to the version of a specific commit:

• Discard all unstaged changes to tracked files:

• Unstage all files:

git restore —staged :/

• Discard all changes to files, both staged and unstaged:

git restore —worktree —staged :/

• Interactively select sections of files to restore:

git restore —patch

Примеры кода, демонстрирующие общие подходы в программировании или же решающие небольшие прикладные задачи. Языки программирования и библиотеки, позволяющие эффективно решать задачи разработки. Объектно-ориентированное программирование, функциональное программирование и прочие подходы и …

Трюки Bash

Полезные заметки по работе с командной строкой: bash и прочие *sh. Однострочники, скрипты, позволяющие решать большие и малые задачи администрирования и настройки Юникс систем. Zsh для современного MacOS, Bash для …

Заметки о настройке различных IT-штуковин. Настройка, допиливание, полировка. Конфигурируем приложения и тюнингуем сервера. Полезные параметры и ключи запуска программ. Увеличиваем скорость, уменьшаем отклик, ускоряем работу и улучшаем результаты работы. Объясняем …

Терминал/Консоль

Команды и инструкции терминала (консоли) Linux, MacOS, Windows и прочих операционных систем. Трюки и особенности командных оболочек, скрипты для администрирования Unix. Программирование и скриптование Windows и Linux, тонкая настройка Macos. …

Также может быть вам интересно:

• Как получить дерево директорий на Bash одним однострочником
• Python: Функции
• Python: Встроенные типы данных (list, set, dict, etc)
• Python: типы данных, переменные, логическое ветвление и циклы
• Как сделать свою middleware в Django (с примерами)

Свежее на «Цифре»
MessageId или как дебажить систему с минимумом проблем
Программы, 49 дней назад
Проверочный список для выпуска промышленных приложений с иллюстрациями
Работа и управление, 90 дней назад
В Google Pixel и Windows Snipping Tool есть возможность восстановления обрезанных изображений
Новости, 23.03.2023
Два подарка «под ёлочку» от Heroes of Might and Magic
Новости, 25.12.2022
Вышел Pulsar – редактор кода на основе Atom
Новости, 25.12.2022
Ленивый backup PostgreSQL
Программы, 17.12.2022
Google анонсировала OSV-Scanner: сканер уязвимостей в программных проектах
Новости, 16.12.2022

Gitea запускает коммерческую версию, а недовольные – форк Forĝejo

На днях группа бывших разработчиков Gitea решили создать на базе хостинга кода Gitea свою версию проекта – «Forgejo». Причиной тому …

Пользователи и их создание в Django — своя регистрация на сайте

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

Новый синтаксис старой команды with в Python 3.10

Как же долго моё чувство прекрасного страдало… Но в Python 3.10 появился новый парсер синтаксических конструкций Python!

Добавляем постраничную пагинацию на Django сайт

На сайтах часто встречаются многостраничные объекты: список товаров, список заметок и т.д. Поэтому важно уметь добавить навигацию по страницам на …

Новый оператор match-case в Python

В новой версии Python (3.10) появится новый оператор. Новый оператор сопоставления по шаблону (match-case).

Нет слов, одни. однострочники

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

Добавляем переменные в контекст Django шаблонов (свой контекст-процессор)

В Django вы можете передавать данные в шаблоны посредством контекстов. Контекст передаётся из контроллера (view в терминах Django), однако, если …

Пример своей консольной команды в Django проекте

Если вы работали с Django проектом, то, скорее всего, запускали команды из консоли (manage.py). В Django есть простой способ писать …

Разграничение прав доступа на Django сайте

Почти на любом веб-сайте необходимо разделять пользователей на группы и предоставлять им разные возможности. В Django есть довольно серьёзная система …

Отмена изменений в рабочей директории — Введение в Git

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

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

Неотслеживаемые файлы

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

В этом случае можно выполнить очистку:

mkdir one touch two git status On branch main Your branch is up to date with 'origin/main'. # Пустые директории в Git не добавляются в принципе # Физически директория one находится в рабочей директории, # но при этом ее нет в Git, поэтому Git игнорирует ее Untracked files: (use "git add . " to include in what will be committed) two # Выполняем очистку. Команда удалит все незакоммиченные изменения # -f – force, -d – directory git clean -fd Removing one/ Removing two 

Забавный факт: про эту команду знает не так много программистов. Используя ее, вы можете удивить даже опытных коллег.

Измененные файлы в рабочей директории

Для отмены изменений в таких файлах используется команда git restore . Причем Git сам напоминает об этом при проверке статуса:

echo 'new text' > INFO.md git status On branch main Your branch is up to date with 'origin/main'. Changes not staged for commit: (use "git add . " to update what will be committed) # Ниже написано, как отменить изменение (use "git restore . " to discard changes in working directory) modified: INFO.md # Отменяем git restore INFO.md 

Изменения, подготовленные к коммиту

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

echo 'new text' > INFO.md git add INFO.md git status On branch main Your branch is up to date with 'origin/main'. Changes to be committed: (use "git restore --staged . " to unstage) modified: INFO.md 

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

--staged INFO.md git status On branch main Your branch is up to date with 'origin/main'. Changes not staged for commit: (use "git add . " to update what will be committed) (use "git restore . " to discard changes in working directory) modified: INFO.md 

Теперь, если нужно, можно выполнить git restore и окончательно отменить изменения в выбранных файлах:

Самостоятельная работа

1. Выполните все шаги из урока

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты

Введение в Git

Основное предназначение Git – это сохранение снимков последовательно улучшающихся состояний вашего проекта (Pro git, 2019).

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

Здесь рассматриваются только технические аспекты git’а, для более подробного погружения в философию git’а и его внутреннюю реализацию, советую прочитать несколько полезных книг (см. Рекомендуемая литература).

1. Настройка git

Прежде чем начинать работу с git необходимо его настроить под себя!

1.1 Конфигурационные файлы

• /etc/gitconfig — Общие настройки для всех пользователей и репозиториев
• ~/.gitconfig или ~/.config/git/config — Настройки конкретного пользователя
• .git/config — Настройки для конкретного репозитория

git config []

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

В зависимости какой параметр вы передадите команде git config (—system, —global, —local), настройки будут записываются в один из этих файлов. Каждый из этих “уровней” (системный, глобальный, локальный) переопределяет значения предыдущего уровня!

Что бы посмотреть в каком файле, какие настройки установлены используйте git config —list —show-origin.

Игнорирование файлов
В git вы сами решаете какие файлы и в какой коммит попадут, но возможно вы бы хотели, что бы определённые файлы никогда не попали в индекс и в коммит, да и вообще не отображались в списке не отлеживаемых. Для этого вы можете создать специальный файл (.gitignore) в вашем репозитории и записать туда шаблон игнорируемых файлов. Если вы не хотите создавать такой файл в каждом репозитории вы можете определить его глобально с помощью core.excludesfile (см. Полезные настройки). Вы также можете скачать готовый .gitignore file для языка программирования на котором вы работаете.
Для настройки .gitignore используйте регулярные выражения bash.

1.2 Настройки по умолчанию

Есть куча настроек git’а как для сервера так и для клиента, здесь будут рассмотрены только основные настройки клиента.

git config name value

где name это название параметра, а value его значение, для того что бы задать настройки.
Пример:

git config --global core.editor nano

установит редактор по умолчанию nano.

Вы можете посмотреть значение существующего параметра с помощью git config —get [name] где name это параметр, значение которого вы хотите получить.

Полезные настройки:

• user.name — Имя, которое будет использоваться при создании коммита
• user.email — Email, который будет использоваться при создании коммита
• core.excludesfile — Файл, шаблон которого будет использоваться для игнорирования определённых файлов глобально
• core.editor — Редактор по умолчанию
• commit.template — Файл, содержимое которого будет использоваться для сообщения коммита по умолчанию (См. Работа с коммитами).
• help.autocorrect — При установке значения 1, git будет выполнять неправильно написанные команды.
• credential.helper [mode] — Устанавливает режим хранения учётных данных. [cache] — учётные данные сохраняются на определённый период, пароли не сохраняются (—timeout [seconds] количество секунд после которого данные удаляются, по умолчанию 15 мин). [store] — учётные данные сохраняются на неограниченное время в открытом виде (—file [file] указывает путь для хранения данных, по умолчанию ~/.git-credentials).

1.3 Псевдонимы (aliases)

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

git config alias.SHORT_NAME COMMAND

где SHORT_NAME это имя для сокращения, а COMMAND команда(ы) которую нужно сократить. Пример:

git config --global alias.last 'log -1 HEAD'

после выполнения этой команды вы можете просматривать информацию о последнем коммите на текущей ветке выполнив git last.

Я советую вам использовать следующие сокращения (вы также можете определить любые свои):

• st = status
• ch = checkout
• br = branch
• mg = merge
• cm = commit
• reb = rebase
• lg = «git log —pretty=format:’%h — %ar: %s’»

2. Основы git

Здесь перечислены только обязательные и полезные (на мой взгляд) параметры, ибо перечисление всех неуместно. Для этого используйте git command -help или —help, где command — название команды справку о который вы хотите получить.

2.1 Создание репозитория

• git init [] — Создаёт git репозитории и директорию .git в текущей директории (или в директории указанной после —separate-git-dir , в этом случае директория .git будет находится в другом месте);
• git clone [] [—] [] [-o, —origin ] [-b, —branch ] [—single-branch] [—no-tags] [—separate-git-dir ] [-c, —config ] — Клонирует репозитории с названием origin (или с тем которое вы укажите -o ), находясь на той ветке, на которую указывает HEAD (или на той которую вы укажите -b ). Также вы можете клонировать только необходимую ветку HEAD (или ту которую укажите в -b ) указав —single-branch. По умолчанию клонируются все метки, но указав —no-tags вы можете не клонировать их. После выполнения команды создаётся директория .git в текущей директории (или в директории указанной после —separate-git-dir , в этом случае директория .git будет находится в другом месте);

2.2 Состояние файлов

Для просмотра состояния файлов в вашем репозитории используйте:

git status []

Эта команда может показать вам: на какой ветке вы сейчас находитесь и состояние всех файлов. Обязательных опций нет, из полезных можно выделить разве что -s которая покажет краткое представление о состояний файлов.

Жизненный цикл файлов
Как видно на картинке файлы могут быть не отслеживаемые (Untracked) и отслеживаемые. Отслеживаемые файлы могут находится в 3 состояниях: Не изменено (Unmodified), изменено (Modified), подготовленное (Staged).
Если вы добавляете (с помощью git add) «Не отслеживаемый» файл, то он переходит в состояние «Подготовлено».
Если вы изменяете файл в состояния «Не изменено», то он переходит в состояние «Изменено». Если вы сохраняете изменённый файл (то есть находящийся в состоянии «Изменено») он переходит в состояние «Подготовлено». Если вы делаете коммит файла (то есть находящийся в состоянии «Подготовлено») он переходит в состояние «Не изменено».
Если версии файла в HEAD и рабочей директории отличаются, то файл будет находится в состояний «Изменено», иначе (если версия в HEAD и в рабочем каталоге одинакова») файл будет находится в состояний «Не изменено».
Если версия файла в HEAD отличается от рабочего каталога, но не отличается от версии в индексе, то файл будет в состоянии «Подготовлено».

Этот цикл можно представить следующим образом:
Unmodified -> Modified -> Staged -> Unmodified
То есть вы изменяете файл сохраняете его в индексе и делаете коммит и потом все сначала.

2.3 Работа с индексом

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

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

Что бы просмотреть индекс, используйте git status.

Что бы добавить файлы в индекс используйте

git add []

Полезные параметры команды git add:

• -f, —force — добавить также игнорируемые файлы
• -u, —update — обновить отслеживаемые файлы

Что бы удалить файлы из индекса вы можете использовать 2 команды git reset и git restore.
git-restore — восстановит файлы рабочего дерева.
git-reset — сбрасывает текущий HEAD до указанного состояния.
По сути вы можете добиться одного и того же с помощью обеих команд.

Что бы удалить из индекса некоторые файлы используйте:

git restore --staged

таким образом вы восстановите ваш индекс (или точнее удалите конкретные файлы из индекса), будто бы git add после последнего коммита не выполнялся для них. С помощью этой команды вы можете восстановить и рабочую директорию, что бы она выглядела так, будто бы после коммита не выполнялось никаких изменений. Вот только эта команда имеет немного странное поведение — если вы добавили в индекс новую версию вашего файла вы не можете изменить вашу рабочую директорию, пока индекс отличается от HEAD. Поэтому вам сначала нужно восстановить ваш индекс и только потом рабочую директорию. К сожалению сделать это одной командой не возможно так как при передаче обеих аргументов (git restore -SW) не происходит ничего. И точно также при передаче -W тоже ничего не произойдет если файл в индексе и HEAD разный. Наверное, это сделали для защиты что бы вы случайно не изменили вашу рабочую директорию. Но в таком случае почему аргумент -W передаётся по умолчанию? В общем мне не понятно зачем было так сделано и для чего вообще была добавлена эта команда. По мне так reset справляется с этой задачей намного лучше, да и еще и имеет более богатый функционал так как может перемещать индекс и рабочую директорию не только на последний коммит но и на любой другой.

Но собственно разработчики рекомендуют для сброса индекса использовать именно git restore -S . Вместо git reset HEAD .

С помощью git status вы можете посмотреть какие файлы изменились но если вы также хотите узнать что именно изменилось в файлах то воспользуйтесь командой:

git diff []

таким образом выполнив команду без аргументов вы можете сравнить ваш индекс с рабочей директорией. Если вы уже добавил в индекс файлы, то используйте git diff —cached что бы посмотреть различия между последним коммитом (или тем который вы укажите) и рабочей директории. Вы также можете посмотреть различия между двумя коммитами или ветками передав их как аргумент. Пример: git diff 00656c 3d5119 покажет различия между коммитом 00656c и 3d5119.

2.4 Работа с коммитами

Теперь, когда ваш индекс находится в нужном состояний, пора сделать коммит ваших изменений. Запомните, что все файлы для которых вы не выполнили git add после момента редактирования — не войдут в этот коммит. На деле файлы в нём будут, но только их старая версия (если таковая имеется).

Для того что бы сделать коммит ваших изменений используйте:

git commit []

Полезные опции команды git commit:

• -F, —file [file] — Записать сообщение коммита из указанного файла
• —author [author] — Подменить автора коммита
• —date [date] — Подменить дату коммита
• -m, —mesage [message] — Сообщение коммита
• -a, —all — Закоммитеть все изменения в файлах
• -i, —include [files. ] — Добавить в индекс указанные файлы для следующего коммита
• -o, —only [files. ] — Закоммитеть только указанные файлы
• —amend — Перезаписать предыдущий коммит

Вы также можете изменить, удалить, объединить любой коммит.
Как вы уже могли заметить вы можете быстро перезаписать последний коммит с помощью git commit —amend.
Для изменения коммитом в вашей истории используйте

git rebase -i

где commit это верхний коммит в вашей цепочке с которого вы бы хотели что либо изменить.

После выполнения git rebase -i в интерактивном меню выберите что вы хотите сделать.

• pick = использовать коммит
• reword = использовать коммит, но изменить сообщение коммита
• edit = использовать коммит, но остановиться для исправления
• squash = использовать коммит, но объединить с предыдущим коммитом
• fixup = как «squash», но пропустить сообщение коммита
• exec = выполнить команду (остаток строки) с помощью командной оболочки
• break = остановиться здесь (продолжить с помощью «git rebase —continue»)
• drop = удалить коммит
• label = дать имя текущему HEAD
• reset = сбросить HEAD к указанной метке

pick 2748cb4 first commit
edit 750f5ae second commit
pick 716eb99 third commit

После сохранения скрипта вы вернётесь в командную строку и git скажет что необходимо делать дальше:

Остановлено на 750f5ae … second commit
You can amend the commit now, with

git commit —amend

Once you are satisfied with your changes, run

git rebase —continue

Как указанно выше необходимо выполнить git commit —amend для того что бы изменить сообщение коммита. После чего выполнить git rebase —continue. Если вы выбрали несколько коммитов для изменения названия то данные операций необходимо будет проделать над каждым коммитом.

Для удаления коммита
Необходимо удалить строку с коммитом.
Пример: вы хотите удалить коммит 750f5ae
Нужно изменить скрипт с такого:
pick 2748cb4 third commit
pick 750f5ae second commit
pick 716eb99 first commit
на такой:
pick 2748cb4 first commit
pick 716eb99 third commit

Для объединения коммитов
Необходимо изменить pick на squash над коммитами которые вы хотите объединить.
Пример: вы хотите объединить коммиты 750f5ae и 716eb99.
Необходимо изменить скрипт с такого:
pick 2748cb4 third commit
pick 750f5ae second commit
pick 716eb99 first commit
На такой
pick 2748cb4 third commit
squash 750f5ae second commit
squash 716eb99 first commit

Заметьте что в интерактивном скрипте коммиты изображены в обратном порядке нежели в git log. С помощью squash вы объедините коммит 750f5ae с 716eb99, а 750f5ae с 2748cb4. В итоге получая один коммит содержащий изменения всех трёх.

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

С помощью команды

git log [] []

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

Полезные параметры команды git log:

• -p — Показывает разницу для каждого коммита.
• —stat — Показывает статистику измененных файлов для каждого коммита.
• —graph — Отображает ASCII граф с ветвлениями и историей слияний.

• -(n) Показывает только последние n коммитов.
• —since, —after — Показывает коммиты, сделанные после указанной даты.
• —until, —before — Показывает коммиты, сделанные до указанной даты.
• —author — Показывает только те коммиты, в которых запись author совпадает с указанной строкой.
• —committer — Показывает только те коммиты, в которых запись committer совпадает с указанной строкой.
• —grep — Показывает только коммиты, сообщение которых содержит указанную строку.
• -S — Показывает только коммиты, в которых изменение в коде повлекло за собой добавление или удаление указанной строки.

Также вы можете настроить свои формат вывода коммитов с помощью

git log --format:["format"]

Варианты форматирования для git log —format.

• %H — Хеш коммита
• %h — Сокращенный хеш коммита
• %T — Хеш дерева
• %t — Сокращенный хеш дерева
• %P — Хеш родителей
• %p — Сокращенный хеш родителей
• %an — Имя автора — %ae — Электронная почта автора
• %ad — Дата автора (формат даты можно задать опцией —date=option)
• %ar — Относительная дата автора
• %cn — Имя коммитера
• %ce — Электронная почта коммитера
• %cd — Дата коммитера
• %cr — Относительная дата коммитера
• %s — Содержание

git log --pretty=format:"%h - %ar : %s"

покажет список коммитов состоящий из хэша времени и сообщения коммита.

2.6 Работа с удалённым репозиторием

Так как git это распределённая СКВ вы можете работать не только с локальными но и с внешними репозиториеми.

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

Для работы с внешними репозиториями используйте:

git remote []

Если вы с клонировали репозитории через http URL то у вас уже имеется ссылка на внешний. В другом случае вы можете добавить её с помощью

git remote add []

Вы можете тут же извлечь внешние ветки с помощью -f, —fetch (вы получите имена и состояние веток внешнего репозитория). Вы можете настроить репозитории только на отправку или получение данных с помощью —mirror[=(push|fetch)]. Для получения меток укажите —tags.

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

Для отслеживания веток используйте git branch -u где rep это название репозитория, br название внешней ветки, а branch название локальной ветки. Либо git branch —set-upstream local_br origin/br для того что бы указать какая именно локальная ветка будет отслеживать внешнюю ветку.

Когда ваша ветка отслеживает внешнюю вы можете узнать какая ветка (локальная или внешняя) отстаёт или опережает и на сколько коммитов. К примеру если после коммита вы не выполняли git push то ваша ветка будет опережать внешнюю на 1 коммит. Вы можете узнать об этом выполнив git branch -vv, но прежде выполните git fetch [remote-name] (—all для получения обновления со всех репозиториев) что бы получить актуальные данные из внешнего репозитория. Для отмены отслеживания ветки используйте git branch —unset-upstream [].

Для загрузки данных с внешнего репозитория используйте git pull [rep] [branch]. Если ваши ветки отслеживают внешние, то можете не указывать их при выполнение git pull. По умолчанию вы получите данные со всех отслеживаемых веток.

Для загрузки веток на новую ветку используйте git checkout -b .

Для отправки данных на сервер используйте

git push [] [
]

где rep это название внешнего репозитория, а br локальная ветка которую вы хотите отправить. Также вы можете использовать такую запись git push origin master:dev. Таким образом вы выгрузите вашу локальную ветку master на origin (но там она будет называется dev). Вы не сможете отправить данные во внешний репозитории если у вас нет на это прав. Также вы не сможете отправить данные на внешнюю ветку если она опережает вашу (в общем то отправить вы можете используя -f, —forse в этом случае вы перепишите историю на внешнем репозитории). Вы можете не указывать название ветки если ваша ветка отслеживает внешнюю.

Для удаления внешних веток используйте

git push origin --delete branch_name

Для получения подробной информации о внешнем репозитории (адреса для отправки и получения, на что указывает HEAD, внешние ветки, локальные ветки настроенные для git pull и локальные ссылки настроенные для git push)

git remote show

Для переименования названия внешнего репозитория используйте

git remote rename

Для удаления ссылки на внешний репозитории используйте

git remote rm

3. Ветвление в git

Ветвление это мощные инструмент и одна из главных фич git’а поскольку позволяет вам быстро создавать и переключатся между различным ветками вашего репозитория. Главная концепция ветвления состоит в том что вы можете откланяться от основной линии разработки и продолжать работу независимо от нее, не вмешиваясь в основную линию. Ветка всегда указывает на последний коммит в ней, а HEAD указывает на текущую ветку (см. Указатели в git).

3.1 Базовые операций

Для создания ветки используйте

git branch []

Здесь branch_name это название для новой ветки, а start_commit это коммит на который будет указывать ветка (то есть последний коммит в ней). По умолчанию ветка будет находится на последнем коммите родительской ветки.

Опции git branch:

• -r | -a [—merged | —no-merged] — Список отслеживаемых внешних веток -r. Список и отслеживаемых и локальных веток -a. Список слитых веток —merged. Список не слитых веток —no-merged.
• -l, -f [] — Список имён веток -l. Принудительное создание, перемещение или удаление ветки -f. Создание новой ветки .
• -r (-d | -D) — Выполнить действие на отслеживаемой внешней ветке -r. Удалить слитую ветку -d. Принудительное удаление (даже не слитой ветки) -D.
• -m | -M [] — Переместить/переименовать ветки и ее журнал ссылок (-m). Переместить/переименовать ветку, даже если целевое имя уже существует -M.
• (-с | -С) [] — Скопировать ветку и её журнал ссылок -c. Скопировать ветку, даже если целевое имя уже существует -C.
• -v, -vv — Список веток с последним коммитом на ветке -v. Список и состояние отслеживаемых веток с последним коммитом на них.

Для переключения на ветку используйте git checkout . Также вы можете создать ветку выполнив git checkout -b .

3.2 Слияние веток

Для слияния 2 веток git репозитория используйте git merge .

Полезные параметры для git merge:

• —squash — Создать один коммит вместо выполнения слияния. Если у вас есть конфликт на ветках, то после его устранения у вас на ветке прибавится 2 коммита (коммит с сливаемой ветки + коммит слияния), но указав этот аргумент у вас прибавится только один коммит (коммит слияния).
• —ff-only — Не выполнять слияние если имеется конфликт. Пусть кто ни будь другой разрешает конфликты 😀
• -X [strategy] — Использовать выбранную стратегию слияния.
• —abort — Отменить выполнение слияния.

Если вы выполняли коммиты на обеих ветках, но при этом не создали конфликт, то слияния пройдёт в «recursive strategy», то есть вам просто нужно будет создать коммит слияния что бы применить изменения (используйте опцию —squash что бы не создавать лишний коммит).
Если вы выполняли коммиты на обоих ветках, которые внесли разные изменения в одну и ту же часть одного и того же файла, то вам придётся устранить конфликт и зафиксировать слияние коммитом.

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

Разрешив конфликт вы должны завершить слияния выполнив коммит.

Во время конфликта вы можете посмотреть какие различия в каких файлах имеются.
git diff —ours — Разница до слияния и после
git diff —theirs — Разница сливаемой ветки до слияния и после
git diff —base — Разница с обеими ветками до слияния и после

Если вы не хотите разрешать слияние то используйте различные стратегии слияния, выбрав либо «нашу» версию (то есть ту которая находится на текущей ветке) либо выбрать «их» версию находящуюся на сливаемой ветке при этом не исправляя конфликт. Выполните git merge —Xours или git merge —Xtheirs соответственно.

3.3 Rerere

Rerere — «reuse recorded resolution” — “повторное использование сохраненных разрешений конфликтов». Механизм rerere способен запомнить каким образом вы разрешали некую часть конфликта в прошлом и провести автоматическое исправление конфликта при возникновении его в следующий раз.

Что бы включить rerere выполните

git config --global rerere.enabled true

Таrже вы можите включить rerere создав каталог .git/rr-cache в нужном репозитории.

Используйте git rerere status для того что бы посмотреть для каких файлов rerere сохранил снимки состояния до начала слияния.

Используйте git rerere diff для просмотра текущего состояния конфликта.

Если во время слияния написано: Resolved ‘nameFile’ using previous resolution. Значит rerere уже устранил конфликт используя кэш.

Для отмены автоматического устранения конфликта используйте git checkout —conflict=merge таким образом вы отмените авто устранение конфликта и вернёте файл(ы) в состояние конфликта для ручного устранения.

4. Указатели в git

в git есть такие указатели как HEAD branch. По сути всё очень просто HEAD указывает на текущую ветку, а ветка указывает на последний коммит в ней. Но для понимания лучше представлять что HEAD указывает на последний коммит.

4.1 Перемещение указателей

В книге Pro git приводится очень хороший пример того как вы можете управлять вашим репозиторием поэтому я тоже буду придерживается его. Представите что Git управляет содержимым трех различных деревьев. Здесь под “деревом” понимается “набор файлов”.
В своих обычных операциях Git управляет тремя деревьями:

• HEAD — Снимок последнего коммита, родитель следующего
• Индекс — Снимок следующего намеченного коммита
• Рабочий Каталог — Песочница

Используя различные опций этой команды вы можете:

• —soft — Cбросить только HEAD
• —mixed — Cбросить HEAD и индекс
• —hard — Cбросить HEAD, индекс и рабочий каталог

Примеру 1. Вы сделали 3 лишних коммита каждый из которых приносит маленькие изменения и вы хотите сделать из них один, таким образом вы можете с помощью git reset —soft переместить указатель HEAD при этом оставив индекс и рабочий каталог нетронутым и сделать коммит. В итоге в вашей истории будет выглядеть так, что все изменения произошли в одном коммите.

Пример 2. Вы добавили в индекс лишние файлы и хотите их от туда убрать. Для этого вы можете использовать git reset HEAD . Или вы хотите что бы в коммите файлы выглядели как пару коммитов назад. Как я уже говорил ранее вы можете сбросить индекс на любой коммит в отличий от git restore который сбрасывает только до последнего коммита. Только с опцией mixed вы можете применить действие к указанному файлу!

Пример 3. Вы начали работать над новой фичей на вашем проекте, но вдруг работодатель говорит что она более не нужна и вы в порыве злости выполняете git reset —hard возвращая ваш индекс, файлы и HEAD к тому моменту когда вы ещё не начали работать над фичей. А на следующей день вам говорят, что фичу всё таки стоит запилить. Но что же делать? Как же переместится вперёд ведь вы откатили все 3 дерева и теперь в истории с помощью git log их не найти. А выход есть — это журнал ссылок git reflog. С помощью этой команды вы можете посмотреть куда указывал HEAD и переместится не только вниз по истории коммитов но и вверх. Этот журнал является локальным для каждого пользователя.

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

5. Рекомендуемая литература

1. Pro git — Scott Chacon
2. Git для профессионального программиста — С. Чакон, Б, Штрауб
3. Git Essentials — F. Santacroce
4. Git: Version Control for Everyone (2013) — R. Somasundaram
5. Version Control with Git: Powerful tools and techniques for collaborative software development (2009) — J. Loeliger, M. McCullough
6. Practical Git and GitHub (2016) — D. Cruz
7. Git in Practice (2016) — M. McQuaid
8. Git Best Practices Guide (2014) — E. Pidoux
9. Learn Enough Git to Be Dangerous (2016) — M. Hartl
10. Learn Version Control with Git: A step-by-step course for the complete beginner (2014) — T. Günther
11. Git: Learn Version Control with Git: A step-by-step Ultimate beginners Guide (2017) — D. Hutten
12. Pragmatic Guide to Git (2010) — S. Travis
13. Волшебство Git (2016) — Б. Лин
14. A Hacker’s Guide to Git (2014) — J. Wynn
15. Practical Git and GitHub (2016) — D. Cruz
16. Deploying to OpenShift(2018) — G. Dumpleton
17. Git for Teams (2015) — Emma Jane Hogbin Westby

• git workflow
• git
• github
• linux
• системы управления версиями
• системы контроля версий

Exploring git life-cycle

In this blog we will see the basic life-cycle of a file in git. Refer below diagram.

Round 1 Changes

I have created the ‘git-learning’ repository using GitHub. Initialized the repository using the README.md file. That is my initial commit on the master branch. See below unique commit id: 1d4ce0714c2e9a8d873c1a5e97cc0ce7bc12fd1b

As of now we have only one branch that is master, we can create other branches also, that we will cover later.

I have cloned the repository & run git log list down the version history for the current branch i.e. master. Showing all information like when & who performed the commit.

Lets do some changes in README.md file. After that run git status

So after changing the file, git saying there is ‘Changes not staged. Use git add to update….’ i.e. there are some changes in your working area. Let’s run the git diff to see the changes.

Let’s run git add command to move the changes from working to staging area & see the git status again.

Here if you notice that, git is saying you are up to date with master. You have staged your changes, now ready for commit. It is also showing changes to be committed.

Here if you run git diff, it will not show any data, as you have pushed changes in staging area. You have to run the git diff –staged

Let’s commit our changes using git commit command. This will move the changes from staging area to local repository & records file permanently in version history.

You have committed your changes. Permanently noted in version history locally. This commit is not available in remote repository. Check latest commit id using git log.

commit 77016c10f68af68b355884bdce65e98f6e7642bc

Notice below screenshot the red line ‘origin/master, origin/Head‘ – is on previous commit. Which is remote repository latest commit. Local repository latest commit is on top, that we have done above.

You can compare the commits using git diff

Final thing is to push the changes in remote repository using git push

git push is done i.e. local commits uploaded to remote repository. Checking remote repository:

commit 77016c10f68af68b355884bdce65e98f6e7642bc

Check git log now. After push, notice the red line ‘origin/master, origin/Head‘ – is now present on latest commit.

Round 2 Changes

I have added two new files & changed the README.md

Checking git status

Checking git diff

Moving all changes to staging area: git add . –all

Commit & Checking git log

commit: 177a091e9b72c3b97799aaac97c5ffa8e7478c23

Final git push.

Restoring Files (git restore)

When you have changed file in workarea & want to restore with original one. Run git restore command.

When you have staged the file in staging area & want to restore. Run git restore –Staged command.

Reset Commit (git reset)

I have commit the change in local repository & commit got generated f975da9d4ecb7c45db061b72fd1b450fd61cfa0f. Now want to reset the commit.

Lets reset to last commit. i.e. 179359643be893c489a61b50233752a299b01f4a

Lets run git reset –soft HEAD1 command to reset to last commit

Provide HEADn for nth last commit.

Happy Learning! Your feedback would be appreciated!

Похожие публикации:

1. Высшее образование 5 лет как называется
2. Как выйти из tty linux
3. Как добавить запись в базу данных
4. Как посмотреть event listener в chrome