git-rebase - онлайн в облаке

ПРОГРАММА:

ИМЯ

git-rebase - локальный прямой порт фиксируется в обновленной заголовке восходящего потока

СИНТАКСИС

мерзавец перебазировать [-i | --interactive] [параметры] [--exec ] [--на ]
[ [ ]]
мерзавец перебазировать [-i | --interactive] [параметры] [--exec ] [--на ]
--корень [ ]
мерзавец перебазировать --продолжить | - пропустить | --abort | --редактировать-todo

ОПИСАНИЕ

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

Если не указан, восходящий поток настроен в ветке. .remote и
ветвь. Будут использоваться параметры .merge (см. git-конфигурация(1) для подробностей) и
Предполагается опция --fork-point. Если вы в настоящее время не находитесь ни в одной ветке или если текущий
ветка не имеет настроенного восходящего потока, перебазирование будет прервано.

Все изменения, сделанные коммитами в текущей ветке, но которых нет в сохранены
во временную зону. Это тот же набор коммитов, который показывает git log.
..ГОЛОВА; или git log 'fork_point' .. HEAD, если --fork-point активен (см.
описание на --fork-point ниже); или с помощью git log HEAD, если указана опция --root.

Текущая ветка сбрасывается на , или если была указана опция --onto.
Это имеет тот же эффект, что и git reset --hard (или ). ORIG_HEAD - это
установите так, чтобы он указывал на кончик ветви перед сбросом.

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

Возможно, что ошибка слияния помешает этому процессу полностью
автоматический. Вам нужно будет устранить любой такой сбой слияния и запустить git rebase --continue.
Другой вариант - обойти фиксацию, которая вызвала сбой слияния, с помощью git rebase
--пропускать. Чтобы проверить оригинал и удалите рабочие файлы .git / rebase-apply,
вместо этого используйте команду git rebase --abort.

Предположим, что существует следующая история и текущая ветка - «тема»:

A --- B --- C тема
/
D --- E --- F --- G мастер

С этого момента результат любой из следующих команд:

git мастер перебазирования
git rebase главная тема

было бы:

Тема A '- B' - C '
/
D --- E --- F --- G мастер

ПРИМЕЧАНИЕ: Последняя форма - это всего лишь краткое изложение темы проверки git, за которой следует git rebase.
мастер. Когда перебазирование завершится, тема останется выделенной веткой.

Если восходящая ветвь уже содержит внесенные вами изменения (например, из-за того, что вы отправили
patch, который был применен вверх по течению), то этот коммит будет пропущен. Например, бег
git rebase master в следующей истории (в которой A 'и A вводят один и тот же набор
изменяется, но имеет другую информацию о коммиттере):

A --- B --- C тема
/
D --- E --- A '--- F мастер

приведет к:

B '--- C' тема
/
D --- E --- A '--- F мастер

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

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

о --- о --- о --- о --- о мастер
\
о --- о --- о --- о --- о дальше
\
о --- о --- о тема

Мы хотим сделать тема раздвоенный из ветки мастер; например, потому что функциональность на
который тема зависимый был объединен с более стабильным мастер ветвь. Мы хотим, чтобы наше дерево
выглядеть следующим образом:

о --- о --- о --- о --- о мастер
| \
| o '- o' - o 'тема
\
о --- о --- о --- о --- о дальше

Мы можем получить это с помощью следующей команды:

git rebase --onto мастер следующей темы

Другой пример опции --onto - перебазирование части ветки. Если у нас есть следующие
ситуация:

H --- I --- J темаB
/
E --- F --- G themeA
/
A --- B --- C --- D мастер

тогда команда

git rebase --в качестве главной темыA topicB

приведет к:

H '- I' - J 'темаB
/
| E --- F --- G themeA
|/
A --- B --- C --- D мастер

Это полезно, когда topicB не зависит от topicA.

Ряд коммитов также можно удалить с помощью rebase. Если у нас есть следующая ситуация:

E --- F --- G --- H --- I --- J темаA

тогда команда

git rebase --onto topicA ~ 5 topicA ~ 3 topicA

приведет к удалению коммитов F и G:

E --- H '--- I' --- J 'themeA

Это полезно, если F и G были некорректны или не должны быть частью topicA. Примечание
что аргумент --onto и Параметр может быть любым допустимым типом фиксации.

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

git добавить

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

git rebase - продолжить

Кроме того, вы можете отменить мерзавец перебазировать

git перебазировать --abort

КОНФИГУРАЦИЯ

rebase.stat
Показывать ли diffstat того, что изменилось в восходящем направлении с момента последней перезагрузки. Ложь
по умолчанию.

rebase.autoSquash
Если установлено значение true, включить --автосквош вариант по умолчанию.

rebase.autoStash
Если установлено значение true, включить --автосташ вариант по умолчанию.

rebase.missingCommitCheck
Если установлено значение «предупреждать», выводить предупреждения об удаленных коммитах в интерактивном режиме. Если установлено на
"error", распечатайте предупреждения и остановите перебазирование. Если установлено "игнорировать", проверка не выполняется.
сделано. "игнорировать" по умолчанию.

rebase.instructionFormat
Пользовательский формат списка фиксации для использования во время - интерактивный перебазировать.

ДОПОЛНИТЕЛЬНЫЕ УСЛУГИ, НЕ ВКЛЮЧЕННЫЕ В ПАКЕТ

--на
Начальная точка для создания новых коммитов. Если параметр --onto не установлен
указано, отправной точкой является . Может быть любой действительный коммит, а не только
название существующей ветки.

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


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


Рабочая ветка; по умолчанию HEAD.

--Продолжить
После разрешения конфликта слияния перезапустите процесс перебазирования.

- отменить
Прервите операцию перебазирования и сбросьте HEAD в исходную ветку. Если было
при условии, что операция перебазирования была запущена, тогда HEAD будет сброшен на .
В противном случае HEAD будет сброшен на то место, где он был при запуске операции rebase.

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

--пропускать
Перезапустите процесс перебазирования, пропустив текущий патч.

--редактировать-todo
Отредактируйте список задач во время интерактивной перестановки.

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

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

-s , --strategy =
Используйте данную стратегию слияния. Если нет опции -s мерзавец слияние-рекурсивный используется
вместо. Это подразумевает --merge.

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

-ИКС , --strategy-option =
Пройти вплоть до стратегии слияния. Это означает --merge и, если
стратегия не указана, -s рекурсивно. Обратите внимание на изменение направления наш и их as
отмечалось выше для опции -m.

-S [ ], --gpg-sign [= ]
GPG-подписывает коммиты. Аргумент keyid является необязательным и по умолчанию используется коммиттер.
личность; если указано, он должен быть прикреплен к опции без пробела.

-к, --тишина
Будь спокоен. Подразумевает --no-stat.

-v, --подробный
Будьте многословны. Подразумевает --stat.

--stat
Покажите различную статистику того, что изменилось в восходящем направлении с момента последней перезагрузки. Диффстат также
контролируется опцией конфигурации rebase.stat.

-n, --no-stat
Не показывать diffstat как часть процесса перебазирования.

--no-проверить
Эта опция обходит ловушку pre-rebase. Смотрите также гитхуки(5).

--проверять
Разрешает запуск обработчика pre-rebase, который используется по умолчанию. Эта опция может быть использована для
переопределить --no-verify. Смотрите также гитхуки(5).

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

-f, --force-rebase
Принудительно выполнить перебазирование, даже если текущая ветка актуальна, а команда - без
- сила вернется, ничего не делая.

Вы можете найти это (или --no-ff с интерактивным перебазированием) полезным после возврата к
слияние ветки темы, так как эта опция воссоздает ветку темы со свежими коммитами, чтобы
может быть успешно добавлен без необходимости «отменить реверсию» (см.
откатить ошибочное слияние How-To[1] для подробностей).

--fork-point, --no-fork-point
Используйте reflog, чтобы найти лучшего общего предка между а также когда
вычисление, какие коммиты были введены .

Когда --fork-point активен, fork_point будет использоваться вместо к
вычислить набор коммитов для перебазирования, где fork_point это результат git
база слияния --fork-point команда (см. git-слияние-база(1)). Если
fork_point оказывается пустым, будет использоваться как запасной вариант.

Если либо или --root задается в командной строке, тогда значение по умолчанию
--no-fork-point, иначе по умолчанию --fork-point.

--ignore-whitespace, --whitespace =
Эти флаги передаются мерзавец подать заявление программа (см. git-применить(1)), который применяет
пластырь. Несовместимо с параметром --interactive.

--committer-date-is-author-date, --ignore-date
Эти флаги передаются мерзавец am чтобы легко изменить даты перебазированных коммитов
(См. мерзавец(1)). Несовместимо с опцией --interactive.

-я, --интерактивный
Составьте список коммитов, которые будут перебазированы. Позвольте пользователю редактировать этот список
перед ребазированием. Этот режим также можно использовать для разделения коммитов (см. РАЗДЕЛЕНИЕ КОМИТЕТОВ
ниже).

Формат списка фиксации можно изменить, установив параметр конфигурации
rebase.instructionFormat. Настроенный формат инструкции автоматически будет иметь
к формату добавлен длинный хеш фиксации.

-p, --preserve-слияния
Повторное создание коммитов слияния вместо сглаживания истории путем воспроизведения коммитов слияния
фиксация вводит. Разрешение конфликтов слияния или ручные поправки к коммитам слияния
не сохранились.

Он использует внутренне интерактивный механизм, но объединяет его с
- интерактивная опция явно не является хорошей идеей, если вы не знаете, что вы
делают (см. ОШИБКИ ниже).

-Икс , --exec
Добавить "exec "после каждой строчки создания фиксации в финальной истории. буду
интерпретироваться как одна или несколько команд оболочки.

Этот параметр можно использовать только с параметром --interactive (см. ИНТЕРАКТИВНЫЙ РЕЖИМ
ниже).

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

git rebase -i --exec "cmd1 && cmd2 && ..."

или указав более одного --exec:

git rebase -i --exec "cmd1" --exec "cmd2" --exec ...

Если используется --autosquash, строки "exec" не будут добавляться для промежуточных
фиксируется и появляется только в конце каждой серии сквоша / исправлений.

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

--autosquash, --no-autosquash
Когда сообщение журнала фиксации начинается с "squash! ..." (или "fixup! ..."), и есть
коммит, название которого начинается с того же ..., автоматически изменяет список задач
rebase -i, чтобы фиксация, помеченная для сжатия, появлялась сразу после фиксации, которая должна быть
изменен, и измените действие перемещенного коммита с выбора на сквош (или исправление).
Игнорирует последующие «исправление!» Или «сквош!» После первого, если вы упомянули
более раннее исправление / сквош с помощью git commit --fixup / - squash.

Эта опция действительна только тогда, когда - интерактивный опция используется.

Если же линия индикатора --автосквош опция включена по умолчанию с использованием переменной конфигурации
rebase.autoSquash, этот параметр можно использовать для отмены и отключения этого параметра.

--autostash, --no-autostash
Автоматически создавать временный тайник до начала операции и применять его после
операция заканчивается. Это означает, что вы можете запустить rebase на грязном рабочем дереве. Тем не мение,
используйте с осторожностью: последнее приложение тайника после успешного переназначения может привести к
нетривиальные конфликты.

--но-фф
С --interactive, выберите вишневый выбор для всех перемещенных коммитов вместо быстрой перемотки вперед.
неизменные. Это гарантирует, что вся история перебазированной ветки
состоит из новых коммитов.

Без --interactive это синоним --force-rebase.

Вы можете найти это полезным после отмены слияния тематической ветки, так как эта опция
воссоздает ветку темы со свежими коммитами, чтобы ее можно было успешно повторно объединить
без необходимости «отменить возврат» (см. откатить ошибочное слияние How-To[1] для
подробности).

MERGE СТРАТЕГИИ

Механизм слияния (команды git merge и git pull) позволяет бэкэнд слияние стратегий
для выбора с параметром -s. Некоторые стратегии также могут иметь свои собственные варианты, которые могут быть
прошло, дав -X аргументы для git merge и / или git pull.

решение
Это может разрешить только две головы (то есть текущую ветвь и другую ветку, которую вы вытащили
from) с использованием 3-стороннего алгоритма слияния. Он пытается тщательно обнаружить перекрестное слияние
двусмысленностей и считается в целом безопасным и быстрым.

рекурсивный
Это может разрешить только две головы с использованием 3-стороннего алгоритма слияния. Когда больше, чем
один общий предок, который можно использовать для 3-стороннего слияния, он создает объединенное дерево
общих предков и использует это в качестве ссылочного дерева для трехстороннего слияния. Это
сообщалось, что это приводит к меньшему количеству конфликтов слияния, не вызывая ошибок слияния при тестировании
сделано на фактических коммитах слияния, взятых из истории разработки ядра Linux 2.6.
Кроме того, это может обнаруживать и обрабатывать слияния с переименованием. Это по умолчанию
стратегия слияния при извлечении или слиянии одной ветки.

Ассоциация рекурсивный Стратегия может принимать следующие варианты:

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

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

их
Это противоположность наш.

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

diff-algorithm = [терпение | минимальная | гистограмма | myers]
Сообщает слияние-рекурсивный использовать другой алгоритм сравнения, который поможет избежать
ошибочные слияния, возникающие из-за несущественных совпадающих строк (например, фигурных скобок из
различные функции). Смотрите также git-diff(1) --дифференциальный алгоритм.

игнорировать-пробел-изменение, игнорировать-все-пространство, игнорировать-пробел-в-эол
Обрабатывает строки с указанным типом изменения пробелов как неизменные для
ради трехстороннего слияния. Изменения пробелов смешиваются с другими изменениями строки
не игнорируются. Смотрите также git-diff(1) -b, -w и --ignore-space-at-eol.

· Если их версия только вводит изменения пробелов в строке, наши версия
использовал;

· Если наши версия вводит изменения пробелов, но их версия включает
существенное изменение, их версия используется;

· В противном случае слияние происходит обычным образом.

перенормировать
Это запускает виртуальную регистрацию и регистрацию всех трех этапов файла, когда
разрешение трехстороннего слияния. Эта опция предназначена для использования при объединении веток
с различными чистыми фильтрами или правилами нормализации конца строки. См. «Слияние
ветки с разными атрибутами проверки / оформления заказа "в gitattributes(5) для
Детали.

без перенормировки
Отключает опцию перенормировки. Это отменяет merge.renormalize
переменная конфигурация.

переименовать-порог =
Управляет порогом сходства, используемым для обнаружения переименования. Смотрите также git-diff(1)
-М.

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

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

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

поддерево
Это модифицированная рекурсивная стратегия. При объединении деревьев A и B, если B соответствует
поддерево A, B сначала настраивается для соответствия древовидной структуре A, а не
чтение деревьев на одном уровне. Эта настройка также выполняется для общего
дерево предков.

Со стратегиями, использующими 3-стороннее слияние (включая значение по умолчанию, рекурсивный), если изменить
выполняется в обеих ветвях, но позже откатывается в одной из ветвей, это изменение будет
присутствует в объединенном результате; некоторых людей это поведение сбивает с толку. Это происходит потому, что
при слиянии учитываются только головы и база слияния, а не
индивидуальные коммиты. Следовательно, алгоритм слияния рассматривает отмененное изменение как отсутствие
изменить и заменить вместо этого измененную версию.

ПРИМЕЧАНИЯ

Вы должны понимать последствия использования мерзавец перебазировать в репозитории, которым вы делитесь.
См. Также ВОССТАНОВЛЕНИЕ ИЗ UPSTREAM REBASE ниже.

Когда запускается команда git-rebase, она сначала выполняет хук "pre-rebase", если один
существуют. Вы можете использовать этот хук для проверки работоспособности и отклонить перебазирование, если это не так.
подходящее. См. Пример в сценарии ловушки предварительной перебазировки шаблона.

По завершении, будет текущая ветка.

INTERACTIVE РЕЖИМ

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

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

1. есть замечательная идея

2. взломать код

3. подготовить серию к подаче

4. отправить

где пункт 2. состоит из нескольких экземпляров

а) регулярное использование

1. закончить что-нибудь достойное коммита

2. совершить

б) независимая фиксация

1. понимаете, что что-то не работает

2. исправить это

3. совершить это

Иногда вещь фиксируется в п.2. не может быть изменен на не совсем идеальный совершить его
исправления, потому что этот коммит глубоко похоронен в серии патчей. Это именно то, что
интерактивное перебазирование предназначено для: используйте его после множества "a" и "b", переставляя и
редактирование коммитов и объединение нескольких коммитов в один.

Начните с последнего коммита, который хотите оставить как есть:

git rebase -i

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

pick deadbee единственная линия этого коммита
pick fa1afe1 Линия следующего коммита
...

Однострочные описания предназначены исключительно для вашего удовольствия; мерзавец перебазировать не буду смотреть на них
но в именах фиксации (в этом примере «deadbee» и «fa1afe1»), поэтому не удаляйте и не
редактировать имена.

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

Если вы просто хотите отредактировать сообщение фиксации для фиксации, замените команду «выбрать» на
команда "перефразировать".

Чтобы удалить фиксацию, замените команду «выбрать» на «сбросить» или просто удалите совпадающую
линии.

Если вы хотите объединить два или более коммитов в один, замените команду «выбрать» на
второй и последующие коммиты с "squash" или "fixup". Если бы у коммитов были разные
Авторы, свернутый коммит будет отнесен к автору первого коммита. В
Предлагаемое сообщение фиксации для свернутой фиксации - это объединение сообщений фиксации
первой фиксации и тех, у кого есть команда "squash", но опускает сообщения фиксации
коммитов с помощью команды "fixup".

мерзавец перебазировать остановится, когда "выбрать" было заменено на "редактировать" или когда команда не удалась из-за
слить ошибки. Когда вы закончите редактирование и / или разрешение конфликтов, вы можете продолжить
с помощью git rebase --continue.

Например, если вы хотите изменить порядок последних 5 коммитов, так что то, что было HEAD ~ 4, станет
новая ГОЛОВА. Для этого вы должны позвонить мерзавец перебазировать как это:

$ git rebase -i HEAD ~ 5

И переместите первый патч в конец списка.

Возможно, вы захотите сохранить слияния, если у вас есть такая история:

X
\
А --- М --- Б
/
--- о --- O --- P --- Q

Предположим, вы хотите переставить боковую ветвь, начиная с «A», на «Q». Убедитесь, что
текущий HEAD - "B", и позвоните

$ git rebase -i -p --onto QO

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

Pick deadbee Функция орудия XXX
fixup f1a5c00 Исправление для функции XXX
исполнитель сделать
выбрать c0ffeee Линия следующего коммита
edit deadbab Единственная линия коммита после
exec cd subdir; сделать тест
...

Интерактивное перебазирование остановится, когда команда завершится неудачно (т.е. завершится со статусом, отличным от 0), чтобы
дать вам возможность исправить проблему. Вы можете продолжить с помощью git rebase --continue.

Команда "exec" запускает команду в оболочке (той, которая указана в $ SHELL, или
оболочка по умолчанию, если $ SHELL не установлена), поэтому вы можете использовать функции оболочки (например, "cd", ">", ";"
...). Команда запускается из корня рабочего дерева.

$ git rebase -i --exec "сделать тест"

Эта команда позволяет вам проверять компилируемость промежуточных коммитов. Список дел
становится так:

выбрать 5928aea один
exec сделать тест
выберите 04d0fda два
exec сделать тест
выбрать ba46169 три
exec сделать тест
выбрать f4593f9 четыре
exec сделать тест

РАЗДЕЛЕНИЕ ОБЯЗАНЫ

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

· Запустите интерактивную перебазировку с помощью git rebase -i ^, где это фиксация
вы хотите разделиться. Фактически, подойдет любой диапазон фиксации, если он содержит это
совершить.

· Отметьте фиксацию, которую вы хотите разделить, действием «редактировать».

· Когда дело доходит до редактирования этого коммита, выполните команду git reset HEAD ^. Эффект состоит в том, что
HEAD перематывается на единицу, и индекс следует этому примеру. Однако рабочее дерево остается
тоже самое.

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

· Зафиксируйте текущий индекс с любым подходящим сообщением фиксации.

· Повторяйте последние два шага, пока ваше рабочее дерево не станет чистым.

· Продолжите перебазирование с помощью git rebase --continue.

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

ВОССТАНОВЛЕНИЕ от ДОБЫЧА ПЕРЕБАЗИРОВАТЬ

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

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

o --- o --- o --- o --- o --- o --- o --- o --- o мастер
\
о --- о --- о --- о --- о подсистема
\
*---*---* тема

If подсистема перебазирован против мастерпроисходит следующее:

o --- o --- o --- o --- o --- o --- o --- o мастер
\ \
o --- o --- o --- o --- o o '- o' - o '- o' - o 'подсистема
\
*---*---* тема

Если вы сейчас продолжите разработку в обычном режиме и в конечном итоге объедините тема в подсистема,
совершает от подсистема останется дублированным навсегда:

o --- o --- o --- o --- o --- o --- o --- o мастер
\ \
o --- o --- o --- o --- o o '- o' - o '- o' - o '- Подсистема M
\ /
*---*---*-..........-*--* тема

Такие дубликаты обычно не одобряются, потому что они загромождают историю, делая ее
труднее уследить. Чтобы навести порядок, вам нужно перенести коммиты на тема до
new подсистема подсказка, т. е. перебазировать тема. Это становится волновым эффектом: любой, кто ниже по течению
от тема тоже принудительно переустанавливается и так далее!

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

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

Жесткий случай: изменения не совпадают.
Это произойдет, если подсистема rebase имел конфликты или использовался --interactive для пропуска,
коммиты редактирования, сквоша или исправления ошибок; или если восходящий поток использовал одно из commit --amend, reset,
или фильтр-ветвь.

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

В этом случае исправить это легко, потому что мерзавец перебазировать знает, что нужно пропустить изменения, которые уже
присутствует в новом апстриме. Итак, если вы скажете (при условии, что вы тема)

Подсистема $ git rebase

вы получите фиксированную историю

o --- o --- o --- o --- o --- o --- o --- o мастер
\
o '- o' - o '- o' - o 'подсистема
\
*---*---* тема

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

Внимание
Хотя «легкое восстановление» иногда оказывается успешным даже в сложных
В этом случае это может иметь непредвиденные последствия. Например, коммит, который был удален через
git rebase - интерактивный будет воскресший!

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

· С подсистема reflog: после мерзавец получать, старый наконечник подсистема Я сидел
подсистема @ {1}. Последующие выборки увеличат число. (Видеть git-reflog(1)).

· Относительно кончика тема: зная, что твой тема есть три коммита, старый совет
of подсистема должна быть тема ~ 3.

Затем вы можете перенести старую подсистему..тему на новую подсказку, сказав (для рефлога
случае, и предполагая, что вы на тема уже):

$ git rebase --onto subsystem subsystem @ {1}

Эффект пульсации от восстановления в «жестком кейсе» особенно плох: все члены вниз по течению от
тема теперь придется также выполнить восстановление в "жестком случае"!

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