Не предоставляет функций, которые могут вызывать другие модули — т.е. не выполняет никакого своего кода в чужом потоке выполнения (нити, горутине, etc.), таким образом изолируя от вызывающего кода даже исключения, которые могут возникать в коде модуля.
Не могли бы вы привести пример нарушения этого правила?
Трудно прогонять тесты? Да, трудно. Это доказывает преимущества ребейса перед мерджем? Нет, не доказывает.
Пре ребейсе нужно прогнать тесты для каждого коммита, при мёрже — только один раз. Таким образом, на ребейс уйдёт значительно больше времени. Поэтому мёрж — быстрее. Преимущество в скорости доказано.
Т.е. переписать историю? Вы же вроде против этого.
Но это придётся сделать, чтобы все коммиты были нормальными. Я как раз предлагаю так не делать :).
Правда, я не против переписывания истории, если коммиты не успели попасть в апстрим. Я против огромных коммитов. И ещё я против возни с проверкой коммитов, которые можно не проверять, если делаешь мёрж.
Пример в студию.
Сложно это :). Но давайте попробуем
В коммите H есть функция mult, которая принимает int и умножает на 2
int mult(int number) {
return number*2;
}
В коммите G мы её используем в одном месте
return mult(res);
В коммитах E и С используем в двух других местах, не связанных с местом в G.
А в коммите D в мастере стало понятно, что нужно добавлять множитель в параметры.
- int mult(int number) {
- return number*2;
+int mult(int number, int multiplier) {
+ return number*multiplier;
}
Потом сделали ребейс ветки на B
И получили несобираемый код. Причём не собирается ни один коммит в ветке. Нужно каждый изменить.
Если делать мёрж из мастера, то можно изменить только мёрж коммит перед тем, как мёржить ветку в мастер.
Зачем исправлять каждый коммит если достаточно исправлять те где поймали ошибку?
Если ошибка только в одном коммите, то нужно поправить только один. Но она может быть и в нескольких, например, если после создания ветки в мастере поменялся соства аргументов какого-нибудь метода, который используется в нескольких коммитах. В худшем случае придётся поправить все коммиты.
И, так как потенциально ошибка может быть в любом коммите — нужно каждый собрать и прогнать на каждом тесты.
В статье описаны надуманные проблемы людей, которые не умеют и не хотят учиться использовать rebase
В статье описаны проблемы людей, которые не хотят во время rebase исправлять каждый коммит, потому что это долго и непонятно зачем нужно.
Хочу обратить ваше внимание, что вы делаете замечания о том, что причина в том, что люди чего-то не умеют, хотя они вам несколько раз озвучили причины.
С таким же успехом я могу начать рассказывать вам, что надуманы ваши проблемы и вы просто не умеете и не хотите учиться пользоваться нелинейной историей.
Под кодом мастера я имел в виду те коммиты, которые были в мастере до мёржа. Под кодом ветки — коммиты, которые были в ветке.
А если Вы не согласны с утверждением про наследование проблемы, код коммитов D, E в студию, плиз.
После мёржа коммиты, которые были в ветке не изменятся. Их можно будет чекаутить и спокойно собирать код. Ни один из них поломан не будет. Будет поломан мёрж коммит, но его можно поправить перед тем, как пушить.
После ребейза на основе этих коммитов будут созданы новые коммиты, которые будут содержать проблему. Потенциально каждый из них может оказаться несобираемым, поэтому для того, чтобы в апстриме не было битых коммитов возможно каждый из них придётся поправить руками.
Оттуда что сначала идёт merge, а потом уже проверка. И, как тут уже писали, придётся доп.коммит с исправлениями после merge делать.
Нет, не придётся. Нужно смёржить мастер в ветку, прогнать тесты, поправить код, сделать git commit --amend, а потом уже мёржить ветку в мастер. И не будет битых коммитов.
Чтобы не было битых коммитов и чтобы была удобная в работе история коммитов.
Вы вроде не выступаете за то, чтобы делать squash при мёрже? Видимо под удобной в работе историей вы имеете в виду линейную. Чем она удобна? В чём преимущество перед нелинейной?
Вам нужно интегрировать в свою ветку критический фикс, который приехал с третьим мерждом, но при этом те большие фичи вам не нужны (вы не хотите возиться с сайд-эффектами). Вы категорически не приемлете rebase. Ваши действия
Мёржу к себе в код багфикс ветку с критическим фиксом и работаю дальше.
Нет такой проблемы. Проблема конфликтов решается человеком, а не ребейзом или мерджем.
А автор статьи пишет — что есть. И вместо того, чтобы написать ему, что проблемы из его статьи не существует вы пишите ему как решить совершенно другую проблему, которая автора вроде как и не беспокоит.
Я глянул оригинал и по ходу автор (не переводчик) не вдупляет, что есть get merge --no-ff и выдаёт мердж-коммиты за "хорошо", когда их после ребейза итак можно сделать без fast-foward'а.
Как это всё решает проблему поломанных ребейзом коммитов?
Не, ну практически — понятно, что нельзя. Но судя по примеру из Go — как-то также можно было бы сокет слушать.
То есть концептуально можно было бы и через loopback интерфейс общаться?
Это получается, что модули предполагается писать именно на Go?
Это вообще стратегия emacs :)
Не совсем понял вот этот момент
Не могли бы вы привести пример нарушения этого правила?
Пре ребейсе нужно прогнать тесты для каждого коммита, при мёрже — только один раз. Таким образом, на ребейс уйдёт значительно больше времени. Поэтому мёрж — быстрее. Преимущество в скорости доказано.
С начала времён не вижу смысла, но какое-то время можно смело хранить.
Но это придётся сделать, чтобы все коммиты были нормальными. Я как раз предлагаю так не делать :).
Правда, я не против переписывания истории, если коммиты не успели попасть в апстрим. Я против огромных коммитов. И ещё я против возни с проверкой коммитов, которые можно не проверять, если делаешь мёрж.
Сложно это :). Но давайте попробуем
В коммите H есть функция mult, которая принимает int и умножает на 2
В коммите G мы её используем в одном месте
В коммитах E и С используем в двух других местах, не связанных с местом в G.
А в коммите D в мастере стало понятно, что нужно добавлять множитель в параметры.
Потом сделали ребейс ветки на B
И получили несобираемый код. Причём не собирается ни один коммит в ветке. Нужно каждый изменить.
Если делать мёрж из мастера, то можно изменить только мёрж коммит перед тем, как мёржить ветку в мастер.
Ну так в статье и написано, что rebase используют там, где нужно использовать merge
Если ошибка только в одном коммите, то нужно поправить только один. Но она может быть и в нескольких, например, если после создания ветки в мастере поменялся соства аргументов какого-нибудь метода, который используется в нескольких коммитах. В худшем случае придётся поправить все коммиты.
И, так как потенциально ошибка может быть в любом коммите — нужно каждый собрать и прогнать на каждом тесты.
Редактированием всех предыдущих коммитов в пределе. Со сборкой каждого и прогоном тестов на каждом.
В статье описаны проблемы людей, которые не хотят во время rebase исправлять каждый коммит, потому что это долго и непонятно зачем нужно.
Хочу обратить ваше внимание, что вы делаете замечания о том, что причина в том, что люди чего-то не умеют, хотя они вам несколько раз озвучили причины.
С таким же успехом я могу начать рассказывать вам, что надуманы ваши проблемы и вы просто не умеете и не хотите учиться пользоваться нелинейной историей.
Но я так не делаю.
Автору не хочется вносить правки в каждый коммит при ребейзе.
Под кодом мастера я имел в виду те коммиты, которые были в мастере до мёржа. Под кодом ветки — коммиты, которые были в ветке.
После мёржа коммиты, которые были в ветке не изменятся. Их можно будет чекаутить и спокойно собирать код. Ни один из них поломан не будет. Будет поломан мёрж коммит, но его можно поправить перед тем, как пушить.
После ребейза на основе этих коммитов будут созданы новые коммиты, которые будут содержать проблему. Потенциально каждый из них может оказаться несобираемым, поэтому для того, чтобы в апстриме не было битых коммитов возможно каждый из них придётся поправить руками.
Нет, не придётся. Нужно смёржить мастер в ветку, прогнать тесты, поправить код, сделать git commit --amend, а потом уже мёржить ветку в мастер. И не будет битых коммитов.
Вы вроде не выступаете за то, чтобы делать squash при мёрже? Видимо под удобной в работе историей вы имеете в виду линейную. Чем она удобна? В чём преимущество перед нелинейной?
Мёржу к себе в код багфикс ветку с критическим фиксом и работаю дальше.
А автор статьи пишет — что есть. И вместо того, чтобы написать ему, что проблемы из его статьи не существует вы пишите ему как решить совершенно другую проблему, которая автора вроде как и не беспокоит.
Как это всё решает проблему поломанных ребейзом коммитов?
Зачем делать эту тривиальнейшую процедуру, если её можно и не делать?
Откуда им взяться в случае c merge?
В случае с rebase надо будет делать rebase много раз. В случае с мёржем — не придётся.