git перебазировать все вхождения - PullRequest
Новая
       24

git перебазировать все вхождения

0 голосов
/ 20 апреля 2020

филиалов:

  • мастер
  • функция

мастер : commit: 'm1' 

function add(a, b){
    return a + b;
}

функция (на основе фиксации 'm1'): commit: 'f1' 

function add(a, b){
    return a + b;
}
+ function mult(a, b){
+   return a * b;
+ }
+ let a = 5, b = 2, c = 10;
+ const result = mult(add(a, b), c);

включить master: commit: 'm2' 

+ function addTo(a, b){
    return a + b;
}

После включения функции и ввода ветки 'git rebase master' были зафиксированы коммиты (m1 - m2 - f1), и файл изменился следующим образом: 

function addTo(a, b){
    return a + b;
}
function mult(a, b){
    return a * b;
}
let a = 5, b = 2, c = 10;
const result = mult(add(a, b), c);

Как вы можете см. изменил название функции только в 1-й строке с ' add ' на ' addTo ', но имя той же функции ' add ' в последней строке hasn не изменяется на ' addTo '. Так что код не будет работать правильно. Есть ли способ изменить имя функции во всех точках кода, используя ' rebase ' или что-то подобное?

1 Ответ

2 голосов
/ 20 апреля 2020

Короткий ответ - нет: rebase не знает семантику и не может исправить ваш код за вас.

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

Помните, что rebase принципиально работает, копируя некоторые оригинальные серии коммитов в новые и (предположительно) улучшенные коммиты. Это эквивалентно использованию git cherry-pick по одному на каждом обычном (без слияния) коммите (и коммиты слияния обычно удаляются полностью). Между тем Git в общем находит коммиты, используя тот факт, что имя ветки указывает на последний коммит в этой ветке. Каждый коммит, независимо от того, сколько веток его содержит, указывает на свой родительский коммит, который формирует обратную цепочку коммитов; каждый коммит в цепочке может быть скопирован.

Так что git rebase работает - «меняет» ветвь путем:

  1. Выводит список коммитов для копирования (их идентификаторы ha sh) ). Этот список заканчивается коммитом, который идентифицирует имя ветви.
  2. Проверка указанного c перебазирования целевого коммита как отдельного HEAD.
  3. Использование cherry-pick или эквивалента для копирования одного коммита в время из списка, сделанного в шаге 1.
  4. Перемещение имени ветви, чтобы оно идентифицировало окончательный скопированный коммит, и повторное присоединение HEAD.

Когда вы запускаете git rebase Вы можете добавить -x <em>command</em> (или более длинное написание, --exec <em>command</em>) в качестве опции. Это запустит выбранную команду после копирования каждого коммита. Если выбранная команда сообщает об успехе, 1 rebase переходит к следующему коммиту как обычно. Если он сообщает о сбое, в этот момент перебазирование прекращается, возвращая управление человеку.

Теперь человек должен исследовать сбой и внести необходимые исправления. Он / она / они / местоимение могут запускать тесты, если / при необходимости, git add файлов и git commit --amend. Как только проблема будет решена, они могут просто git rebase --continue перейти к следующему коммиту.

Этот трюк -x работает особенно хорошо, если у вас есть набор тестов, который предоставляет правильный статус. В этом конкретном случае тест может быть таким же простым, как и запуск make, который обычно предоставляет правильный статус, хотя фактические тесты являются хорошей идеей.

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

1 «Успех» означает exit 0; сбой означает, что состояние выхода было ненулевым. Ну, разве что вы находитесь в VMS, где выход с кодом 0 или 1 из C кода должен сообщать об успехе, и только четные числа, начинающиеся с 2, должны сообщать об ошибке.

...