git-checkout - Интернет в облаке

ПРОГРАММА:

ИМЯ

git-checkout - переключать ветви или восстанавливать файлы рабочего дерева

СИНТАКСИС

мерзавец контроль [-q] [-f] [-m] [ ]
мерзавец контроль [-q] [-f] [-m] --detach [ ]
мерзавец контроль [-q] [-f] [-m] [--detach]
мерзавец контроль [-q] [-f] [-m] [[-b | -B | --orphan] ] [ ]
мерзавец контроль [-f | --ours | --theirs | -m | --conflict = ] [] [--] ...
мерзавец контроль [-p | --patch] [ ] [-] [ ...]

ОПИСАНИЕ

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

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

Если не найден, но существует ветка отслеживания только в одном удаленном
(назови это ) с совпадающим именем рассматривать как эквивалент

$ git checkout -b --отслеживать /

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

мерзавец контроль -b | -B [ ]
Указание -b вызывает создание новой ветки, как если бы git-ветка(1) были названы и
затем проверил. В этом случае вы можете использовать опции --track или --no-track, которые
будет передан мерзавец филиал. Для удобства --track без -b подразумевает ветвление
творчество; см. описание --track ниже.

Если задано -B, создается, если его не существует; в противном случае он сбрасывается.
Это транзакционный эквивалент

$ git branch -f [ ]
$ git checkout

то есть ветка не сбрасывается / не создается, если "git checkout" не завершился успешно.

мерзавец контроль --detach [ ], мерзавец контроль [--detach]
Приготовьтесь работать поверх , отсоединив ГОЛОВУ от нее (см. "ОТДЕЛЕННАЯ ГОЛОВА"
раздел) и обновление индекса и файлов в рабочем дереве. Местный
модификации файлов в рабочем дереве сохраняются, так что полученные рабочие
tree будет состоянием, записанным в фиксации, плюс локальные изменения.

Когда аргумент - это имя ветки, параметр --detach может использоваться для отсоединения
ГОЛОВА на кончике ветки (git checkout проверил бы эту ветку
без отсоединения ГОЛОВКИ).

Опуская отделяет HEAD от конца текущей ветви.

мерзавец контроль [-p | --patch] [ ] [-] ...
Когда или --patch, мерзавец контроль приносит переключить ветки. Он обновляет
именованные пути в рабочем дереве из индексного файла или из именованного
(чаще всего коммит). В этом случае параметры -b и --track бессмысленны и
предоставление любого из них приводит к ошибке. В аргумент может быть использован для
укажите конкретное дерево (например, фиксацию, тег или дерево), чтобы обновить индекс для
заданные пути перед обновлением рабочего дерева.

мерзавец контроль с участием или --patch используется для восстановления измененных или удаленных путей к
их исходное содержимое из индекса или заменить пути содержимым из именованного
(чаще всего коммит-иш).

Индекс может содержать не объединенные записи из-за предыдущего неудачного слияния. По умолчанию,
если вы попытаетесь извлечь такую ​​запись из индекса, операция проверки завершится ошибкой
и ничего проверять не будет. Использование -f игнорирует эти несвязанные записи. В
содержимое с определенной стороны слияния можно извлечь из индекса с помощью
- наши или - их. С помощью -m изменения, внесенные в файл рабочего дерева, можно отменить в
воссоздать исходный конфликтующий результат слияния.

ДОПОЛНИТЕЛЬНЫЕ ОПЦИИ

-к, --тишина
Тихо, подавить сообщения обратной связи.

--[Нет прогресса
Статус выполнения сообщается в стандартном потоке ошибок по умолчанию, когда он
прикреплен к терминалу, если не указан --quiet. Этот флаг разрешает прогресс
отчет, даже если он не подключен к терминалу, независимо от --quiet.

-ф, --сила
При переключении ветвей продолжайте, даже если индекс или рабочее дерево отличается от
ГОЛОВА. Это используется для удаления локальных изменений.

При проверке путей из индекса не допускайте сбоев при несоединенных записях; вместо,
не объединенные записи игнорируются.

- наши, - их
При проверке путей из индекса проверьте этап # 2 (наш) или # 3 (их) для
не объединенные пути.

Обратите внимание, что во время git rebase и git pull --rebase, наш и их может оказаться поменяемым местами;
--ours дает версию из ветки, на которую были перенесены изменения, а --theirs
дает версию из ветки, в которой хранится ваша работа, которая перебазируется.

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

-b
Создайте новую ветку с именем и начни с ; видеть мерзавец
филиал(1) для подробностей.

-B
Создает ветку и начни с ; если он уже существует,
затем сбросьте его на . Это эквивалентно запуску «git branch» с «-f»;
посмотреть git-ветка(1) для подробностей.

-т, --трек
При создании новой ветки настройте конфигурацию «восходящего потока». См. "--Track" в мерзавец
филиал(1) для подробностей.

Если нет -b задана опция, имя новой ветки будет производным от
удаленного отслеживания, просмотрев локальную часть refspec, настроенную для
соответствующий пульт, а затем убрав начальную часть до "*". Это бы
скажите нам использовать "hack" в качестве локальной ветки при ответвлении от "origin / hack" (или
"remotes / origin / hack" или даже "refs / remotes / origin / hack"). Если данное имя не имеет
косая черта, или указанное выше угадывание приводит к пустому имени, угадывание прерывается. Ты
может явно дать имя с помощью -b в таком случае.

- без трека
Не настраивайте «восходящую» конфигурацию, даже если Branch.autoSetupMerge
переменная конфигурации истинна.

-l
Создайте рефлог новой ветки; видеть git-ветка(1) для подробностей.

--отсоединить
Вместо того, чтобы проверять ветку для работы над ней, проверьте фиксацию для проверки и
отбрасываемые эксперименты. Это поведение по умолчанию для "git checkout " когда
это не название филиала. См. Подробности в разделе «ОТДЕЛЕННАЯ ГОЛОВКА» ниже.

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

Индекс и рабочее дерево настраиваются так, как если бы вы ранее запускали "git checkout".
". Это позволяет вам начать новую историю, которая записывает набор путей
похожий на просто выполнив команду «git commit -a», чтобы выполнить фиксацию root.

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

Если вы хотите запустить историю отключения, которая записывает набор путей,
полностью отличается от одного из , то вы должны очистить индекс и
рабочее дерево сразу после создания ветки-сироты с помощью команды «git rm -rf». из
верхний уровень рабочего дерева. После этого вы будете готовы подготовить новый
файлы, повторно заполняя рабочее дерево, копируя их из другого места, извлекая
tarball и т. д.

--ignore-skip-worktree-bits
В режиме разреженной проверки git checkout - обновит только записи, соответствующие
и разреженные шаблоны в $ GIT_DIR / info / sparse-checkout. Эта опция игнорирует
разреженные шаблоны и добавляет обратно любые файлы в .

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

Когда происходит конфликт слияния, записи индекса для конфликтующих путей остаются
unmerged, и вам нужно разрешить конфликты и пометить разрешенные пути с помощью git
add (или git rm, если слияние должно привести к удалению пути).

При извлечении путей из индекса этот параметр позволяет воссоздать конфликтующие
объединить по указанным путям.

--conflict =
То же, что и опция --merge выше, но меняет способ определения конфликтующих фрагментов.
представлен, переопределяя переменную конфигурации merge.conflictStyle. Возможные значения
являются "объединить" (по умолчанию) и "diff3" (в дополнение к тому, что показано в стиле "объединить",
показывает исходное содержимое).

-p, --патч
В интерактивном режиме выбирайте куски разницы между (или индекс, если
unspecified) и рабочее дерево. Выбранные фрагменты затем применяются в обратном порядке к
рабочее дерево (а если был указан индекс).

Это означает, что вы можете использовать git checkout -p, чтобы выборочно отменить изменения из вашего
текущее рабочее дерево. См. Раздел «Интерактивный режим» в git-добавить(1) научиться
работать в режиме --patch.

--игнорировать другие рабочие деревья
git checkout отказывается, когда требуемый ref уже извлечен другим рабочим деревом.
Эта опция заставляет его все равно проверять реф. Другими словами, рефери может принадлежать
более одного рабочего дерева.


Переход к кассе; если оно относится к ветке (т. е. имя, которое при добавлении
"refs / Heads /", является действительной ссылкой), тогда эта ветка проверяется. В противном случае, если это
относится к действительной фиксации, ваша ГОЛОВА становится «отсоединенной», и вы больше не находитесь ни на одном
ветку (подробнее см. ниже).

В качестве особого случая проверяется синтаксис "@ {- N}" для N-й последней ветви / фиксации.
ветви (вместо отделения). Вы также можете указать - что является синонимом
"@ {- 1}".

В качестве еще одного особого случая вы можете использовать "A ... B" как ярлык для базы слияния A
и B, если существует ровно одна база слияния. Вы можете пропустить не более одного из A и B в
в этом случае по умолчанию используется HEAD.


Имя новой ветки.


Имя коммита, с которого начинается новая ветка; видеть git-ветка(1) для подробностей.
По умолчанию HEAD.


Дерево, из которого нужно оформить заказ (если указаны пути). Если не указан, индекс будет
используемый.

ОТДЕЛЕННЫЙ ГОЛОВА

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

ГОЛОВА (относится к ветке "хозяин")
|
v
a --- b --- c ветка 'master' (относится к фиксации 'c')
^
|
тег 'v2.0' (относится к фиксации 'b')

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

$ редактировать; git add; git commit

ГОЛОВА (относится к ветке "хозяин")
|
v
a --- b --- c --- d ветка 'master' (относится к фиксации 'd')
^
|
тег 'v2.0' (относится к фиксации 'b')

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

$ git checkout v2.0 # или
$ git checkout master ^^

HEAD (относится к фиксации 'b')
|
v
a --- b --- c --- d ветка 'master' (относится к фиксации 'd')
^
|
тег 'v2.0' (относится к фиксации 'b')

Обратите внимание, что независимо от того, какую команду проверки мы используем, HEAD теперь ссылается непосредственно на
совершать b. Это называется отключенным состоянием HEAD. Это просто означает, что HEAD ссылается
к конкретной фиксации, в отличие от ссылки на именованную ветку. Давай посмотрим что происходит
когда мы создаем коммит:

$ редактировать; git add; git commit

HEAD (относится к фиксации 'e')
|
v
e
/
a --- b --- c --- d ветка 'master' (относится к фиксации 'd')
^
|
тег 'v2.0' (относится к фиксации 'b')

Теперь есть новый коммит e, но на него ссылается только HEAD. Конечно, мы можем добавить еще
другой коммит в этом состоянии:

$ редактировать; git add; git commit

HEAD (относится к фиксации 'f')
|
v
е --- е
/
a --- b --- c --- d ветка 'master' (относится к фиксации 'd')
^
|
тег 'v2.0' (относится к фиксации 'b')

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

$ git мастер проверки

ГОЛОВА (относится к ветке "хозяин")
е --- е |
/v
a --- b --- c --- d ветка 'master' (относится к фиксации 'd')
^
|
тег 'v2.0' (относится к фиксации 'b')

Важно понимать, что на данный момент ничто не относится к фиксации. f, В итоге
совершать f (и по расширению фиксации e) будет удален обычной сборкой мусора Git.
процесс, если мы не создадим ссылку до того, как это произойдет. Если мы еще не отошли
от фиксации f, любой из них создаст ссылку на него:

$ git checkout -b foo (1)
$ git ветка foo (2)
$ git тег foo (3)

1. создает новую ветку Foo, что относится к фиксации f, а затем обновляет HEAD для ссылки на
филиал Foo. Другими словами, после этой команды мы больше не будем находиться в отсоединенном состоянии HEAD.
2. аналогично создает новую ветку Foo, что относится к фиксации f, но оставляет HEAD отсоединенным.
3. создает новый тег Foo, что относится к фиксации f, оставляя HEAD отсоединенным.

Если мы отошли от фиксации f, тогда мы должны сначала восстановить его имя объекта (обычно
используя git reflog), а затем мы можем создать ссылку на него. Например, чтобы увидеть
последние два коммита, на которые ссылается HEAD, мы можем использовать любую из этих команд:

$ git reflog -2 HEAD # или
$ git log -g -2 ГОЛОВКА

ПРИМЕРЫ

1. Следующая последовательность проверяет главную ветвь, возвращает Makefile к двум
исправляет, по ошибке удаляет hello.c и возвращает его из индекса.

$ git мастер проверки (1)
$ git checkout master ~ 2 Makefile (2)
$ rm -f привет.с
$ git оформить заказ hello.c (3)

1. переключить ветку
2. взять файл из другого коммита
3. восстановить hello.c из индекса

Если вы хотите, чтобы проверить ВСЕ Исходные файлы C вне индекса, вы можете сказать

$ git checkout - '* .c'

Обратите внимание на кавычки вокруг * .c. Файл hello.c также будет извлечен, даже если он
больше не находится в рабочем дереве, потому что подстановка файлов используется для сопоставления записей
в индексе (а не в рабочем дереве оболочкой).

Если у вас есть неудачная ветка с именем hello.c, этот шаг будет запутан
как указание переключиться на эту ветку. Вместо этого вы должны написать:

$ git checkout - hello.c

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

$ git checkout моя тема

Однако ваша «неправильная» ветвь и правильная «mytopic» ветка могут отличаться в файлах, которые вы
были изменены локально, и в этом случае вышеуказанная проверка завершится неудачно:

$ git checkout моя тема
ошибка: у вас есть локальные изменения в 'frotz'; не переключая ветки.

Вы можете указать флаг -m команде, которая попытается выполнить трехстороннее слияние:

$ git checkout -m моя тема
Автоматическое слияние Frotz

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

3. Когда возникает конфликт слияния во время переключения ветвей с параметром -m, вы должны
увидеть что-то вроде этого:

$ git checkout -m моя тема
Автоматическое слияние Frotz
ОШИБКА: конфликт слияния в frotz
фатальный: программа слияния не удалась

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

$ редактировать
$ git добавить мороз

GIT

Часть мерзавец(1) люкс

Используйте git-checkout онлайн с помощью сервисов onworks.net