Сообщение Преимущества не-squash+merge и squash+merge/squash в Git от 08.10.2018 10:09
Изменено 10.10.2018 7:11 halo
:)
Re[2]: Преимущества не-squash+merge и squash+merge/squash в Git
Здравствуйте, Mystic Artifact, Вы писали:
MA>Если разбивать на два коммита, то требование что-бы каждый был коммит рабочий идет лесом: разработчику, что из-за этой хотелки стабы начать писать? Функционально продукт всё равно не будет иметь нужной функциональности, ценность становится мнимой.
Конечно, в пределах ветки нужной функциональности не будет сначала при таком подходе. Но это и не очень важно. Под "рабочим" имеется в виду, что каждое изменение хотя бы какой "mvn test" или хотя бы "mvn compile" позволяет прогнать.
MA>Я бы предпочел 2-3 коммита: выпил компонента, добавление компонентна, и непосредственно портинг, но, в этом случае промежуточные коммиты будут поломаны. Ну или добавление компонента, портинг, затем "clean-up".
Да, например, так, если рабочее состояние ветки до слияния не очень, как я говорил, важно.
MA>В любом случае если вы одобряете часы и работу ради красоты в git — то так и скажите коллегам, а если их в шею гонят, да ещё и ерунду требуют, то
Не то чтобы красота (тем более, она разной может быть). Скорее, логическая стройность и простота поддержания такого подхода. Поэтому мне интересно, почему многие предпочитают squash.
MA>Если разбивать на два коммита, то требование что-бы каждый был коммит рабочий идет лесом: разработчику, что из-за этой хотелки стабы начать писать? Функционально продукт всё равно не будет иметь нужной функциональности, ценность становится мнимой.
Конечно, в пределах ветки нужной функциональности не будет сначала при таком подходе. Но это и не очень важно. Под "рабочим" имеется в виду, что каждое изменение хотя бы какой "mvn test" или хотя бы "mvn compile" позволяет прогнать.
MA>Я бы предпочел 2-3 коммита: выпил компонента, добавление компонентна, и непосредственно портинг, но, в этом случае промежуточные коммиты будут поломаны. Ну или добавление компонента, портинг, затем "clean-up".
Да, например, так, если рабочее состояние ветки до слияния не очень, как я говорил, важно.
MA>В любом случае если вы одобряете часы и работу ради красоты в git — то так и скажите коллегам, а если их в шею гонят, да ещё и ерунду требуют, то
Не то чтобы красота (тем более, она разной может быть). Скорее, логическая стройность и простота поддержания такого подхода. Поэтому мне интересно, почему многие предпочитают squash.
Преимущества не-squash+merge и squash+merge/squash в Git
Здравствуйте, Mystic Artifact, Вы писали:
MA>Если разбивать на два коммита, то требование что-бы каждый был коммит рабочий идет лесом: разработчику, что из-за этой хотелки стабы начать писать? Функционально продукт всё равно не будет иметь нужной функциональности, ценность становится мнимой.
Конечно, в пределах ветки нужной функциональности не будет сначала при таком подходе. Но это и не очень важно. Под "рабочим" имеется в виду, что каждое изменение хотя бы какой "mvn test" или хотя бы "mvn compile" позволяет прогнать.
MA>Я бы предпочел 2-3 коммита: выпил компонента, добавление компонентна, и непосредственно портинг, но, в этом случае промежуточные коммиты будут поломаны. Ну или добавление компонента, портинг, затем "clean-up".
Да, например, так, если рабочее состояние ветки до слияния не очень, как я говорил, важно.
MA>В любом случае если вы одобряете часы и работу ради красоты в git — то так и скажите коллегам, а если их в шею гонят, да ещё и ерунду требуют, то
Не то чтобы красота (тем более, она разной может быть). Скорее, логическая стройность и простота поддержки такого подхода. Поэтому мне интересно, почему многие предпочитают squash.
MA>Если разбивать на два коммита, то требование что-бы каждый был коммит рабочий идет лесом: разработчику, что из-за этой хотелки стабы начать писать? Функционально продукт всё равно не будет иметь нужной функциональности, ценность становится мнимой.
Конечно, в пределах ветки нужной функциональности не будет сначала при таком подходе. Но это и не очень важно. Под "рабочим" имеется в виду, что каждое изменение хотя бы какой "mvn test" или хотя бы "mvn compile" позволяет прогнать.
MA>Я бы предпочел 2-3 коммита: выпил компонента, добавление компонентна, и непосредственно портинг, но, в этом случае промежуточные коммиты будут поломаны. Ну или добавление компонента, портинг, затем "clean-up".
Да, например, так, если рабочее состояние ветки до слияния не очень, как я говорил, важно.
MA>В любом случае если вы одобряете часы и работу ради красоты в git — то так и скажите коллегам, а если их в шею гонят, да ещё и ерунду требуют, то
Не то чтобы красота (тем более, она разной может быть). Скорее, логическая стройность и простота поддержки такого подхода. Поэтому мне интересно, почему многие предпочитают squash.