Должен ли я изменить коммиты слияния для прохождения тестов? - PullRequest
Новая
       24

Должен ли я изменить коммиты слияния для прохождения тестов?

1 голос
/ 01 мая 2019

Недавно я наткнулся на эту статью.В нем упоминается, что:

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

Это заставило меня задуматься.Иногда после слияния develop в ветку feature, хотя у меня нет конфликтов, мне все равно приходится корректировать некоторый код, чтобы он работал с моими изменениями и все тесты проходили.

Мой вопрос в том, что было бы предпочтительным способом сделать это?

  • внесение изменений в коммит слияния
  • или создание нового коммита

Я не думаю, что это хорошая идея, чтобы красть дополнительный код в коммитах слияния, но если я этого не сделаю, этот коммит будет иметь "известные ошибки", которых мне следует избегать, верно?

I 'Я хотел бы услышать некоторые практические / реальные аргументы, как это влияет на работу с git-bisect?(Я еще не использовал его, но знаю, что он существует и может пригодиться однажды)

1 Ответ

0 голосов
/ 01 мая 2019

Как уже отмечалось, идеальный способ справиться с этим - поместить коммиты исправлений в ветку разработки / функции перед слиянием.Например: 

...--o---------------------M   <-- master
      \                   /
       o--o--o--o--o--o--*   <-- develop

, где commit * - исправление, необходимое для плавного слияния и создания рабочего коммита слияния M.

На практике часто это неэто большое дело в любом случае.Если commit M провалит существующие тесты, система CI будет применять эту передовую практику, и все будет хорошо, но что, если вещь, которая на самом деле терпит неудачу в M, это new , отказ, который никогда не будетнаблюдалось раньше и было неожиданным?Система CI не заметит, и вы тоже не заметите, пока не доберетесь до коммита X: 

                                o--o--X   <-- topic
                               /
...--o------------------M--o--o--...-o   <-- master
      \                /
       o--o--o--o--o--o

, и теперь вы обнаружите, что, к сожалению, у нас должен был быть тест для этого.Итак, теперь вы можете добавить тест, но вы не можете вернуться и изменить M, ни одного из его потомков.Идеальный способ исправить это - проверить первую точку, в которой возникает ошибка, в новой ветви test-and-fix, написать тест и исправления и сохранить его в качестве удобной ветви, например: 

                                o--o--X   <-- topic
                               /
...--o------------------M--o--o--...-o   <-- master
      \                /
       o--o--o--o--o--o
                    \
                     F1--F2   <-- test-and-fix

Commit F1 имеет новый тест (который не проходит) и F2 исправляет его.Теперь вы можете git checkout master; git merge test-and-fix и git checkout topic; git merge test-and-fix, чтобы внести исправления в master и каждую тему / ветку разработки.

(На самом деле рисование результирующего графика становится болезненным.)

На практике многие люди просто выбирают исправление, сделанное в конце master: 

                                o--o--X--F12'   <-- topic
                               /
...--o------------------M--o--o--...-o-------F12   <-- master
      \                /              \      /
       o--o--o--o--o--o                F1--F2   <-- test-and-fix

, где F12' - выбор вишни комбинации / слияния F12и это, как правило, работает хорошо.Но раннее внесение исправления в тот момент, когда ошибка была впервые создана, теоретически лучше на .См. блог Раймонда Чена для получения дополнительной информации об этом.

...