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

* Merged feature-2
|\
| * (any intermediate work if necessary)
| * Added the new component
| * (any intermediate work if necessary)
| * Removed the old component
| * (any intermediate work if necessary)
|/
* Merged feature-1
|\
| * Bla-bla-blah

Он предпочитает:

* Merged feature-2
|\
| * Replaced the component
|/
* Merged feature-1
|\
| * Bla-bla-blah

Хотя, очевидно, были разговоры и о таком раскладе:

* Replaced the component
* Bla-bla-blah

Я в этом не вижу большого смысла в git, потому что:

• Отдельные коммиты позволяют проще отслеживать изменения, их логическую разбивку, а также ход разработки вообще.
  
• Я могу грубо оценить временную шкалу изменений на ветке + ретроспектива.
  
• Если коммиты разделены, я практически в любое время могу откатить любой коммит с помощью git revert, что весьма проблематично в случае больших squash-нутых коммитов.
  
• Я в любой момент могу увидеть по сути такой же лог с помощью git log --merges --oneline --graph.
  
• Кроме того, git diff между ветками также позволяет увидеть, что появилось и пропало на ветке.

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

• git rebase поверх основной ветки иногда может усложняться, но, с другой стороны, при маленьких коммитах справляться с конфликтами проще ввиду их меньших размеров.
  
• Кривая настройка (или отсутствие поддержки) со стороны всяких там BitBucket и т.д. засоряет слияния неинформативными сообщениями типа Merge pull request #PULL_REQUEST_ID in REPOSITORY from BRANCH_NAME to BRANCH_NAME. Конечно, такие сообщения -- мусор.

Какие ещё преимущества предлагают и недостатки тянут за собой мой и его подход?

Здравствуйте, halo, Вы писали:

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

Если разбивать на два коммита, то требование что-бы каждый был коммит рабочий идет лесом: разработчику, что из-за этой хотелки стабы начать писать? Функционально продукт всё равно не будет иметь нужной функциональности, ценность становится мнимой.

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

Я бы предпочел 2-3 коммита: выпил компонента, добавление компонентна, и непосредственно портинг, но, в этом случае промежуточные коммиты будут поломаны. Ну или добавление компонента, портинг, затем "clean-up".

В любом случае если вы одобряете часы и работу ради красоты в git — то так и скажите коллегам, а если их в шею гонят, да ещё и ерунду требуют, то

Здравствуйте, Mystic Artifact, Вы писали:

MA>Если разбивать на два коммита, то требование что-бы каждый был коммит рабочий идет лесом: разработчику, что из-за этой хотелки стабы начать писать? Функционально продукт всё равно не будет иметь нужной функциональности, ценность становится мнимой.

Конечно, в пределах ветки нужной функциональности не будет сначала при таком подходе. Но это и не очень важно. Под "рабочим" имеется в виду, что каждое изменение хотя бы какой "mvn test" или хотя бы "mvn compile" позволяет прогнать.

MA>Я бы предпочел 2-3 коммита: выпил компонента, добавление компонентна, и непосредственно портинг, но, в этом случае промежуточные коммиты будут поломаны. Ну или добавление компонента, портинг, затем "clean-up".

Да, например, так, если рабочее состояние ветки до слияния не очень, как я говорил, важно.

MA>В любом случае если вы одобряете часы и работу ради красоты в git — то так и скажите коллегам, а если их в шею гонят, да ещё и ерунду требуют, то

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

Здравствуйте, halo, Вы писали:

H> Скорее, логическая стройность и простота поддержки такого подхода. Поэтому мне интересно, почему многие предпочитают squash.

Мои 2 cents:

* каждый коммит решает ровно одну таску минимальным числом изменений, так чтобы на ревью никто не устал это все отсматривать
* соответственно жырные таски пилятся на более мелкие (обозримые на ревью)
* ни какой коммит в мастера 100% не ломает сборку -- это важно! (как вы собираетесь `git bisect`ом искать виновника регрессии, если оно даже не собирается?)
* в релиз уходит пачка решенных тикетов + какое-то число "косметических" коммитов (без тикетов, типа там `.gitignore` поправить или что-то подобное)
* таким образом `git log` между 2 мя тэгами по сути есть changelog релиза
* коммиты в мастере не "перемешаны" -- одна фича/багфикс идет за другой
* реверт в случае регрессии это 1 коммит
* разработка конкретной фичи идет на девелоперском бранче
* в нем девелопер, до выхода не ревью пилит свою задачу за любое число коммитов с любыми комментариями... "сохраню ка я это перед сном/праздниками" или там "опс а сборка на платформе XYZ оказывается завалилась"... но как правило это нечто похожее на "фикс для теста", "фикс для теста #2", "фикс для теста (окончательный)", "фикс для другого теста после предидущего фикса" %)
* как правило даже самые простые таски не могут быть сделаны хорошо за 1 коммит
* но видеть все эти муки в общей истории (после того как готовая таска rebase'ится после squash'a в мастер) нафиг никому не надо -- в общей истории инересен только конечный результат
* комменты к коммиту, даже самому мелкому, описывают "как было" и "что стало", чтобы было что почитать в случае регрессии (ну это окромя номера таски, где может быть более детальное обсуждение)

на вскидку вот что приходит на ум...

Здравствуйте, zaufi, Вы писали:

z> * комменты к коммиту, даже самому мелкому, описывают "как было" и "что стало", чтобы было что почитать в случае регрессии (ну это окромя номера таски, где может быть более детальное обсуждение)
Вы просто "неклассически" используете git. Лучше всего такой процесс контролировать например через Gerrit. Там такой подход — как родной, притом без потери информации. Например, один большой коммит, который делает всё — не только сложнее ревьювить, но и хуже отслеживается по истории, особенно если были перемещения кусков кода между файлами.
Классически же когда ты мержишь или отправляешь на ревью ветку, то ты готовишь её специально с помощью rebase&Co. Тогда никаких "фиксов для фиксов теста" никто кроме тебя не будет видеть.
Оба подхода "всё сквошим" и "мержим что есть" — две крайности, обе плохие. Идеал в балансе.

Здравствуйте, zaufi, Вы писали:

Не соглашусь со следующими тезисами:

Z>* каждый коммит решает ровно одну таску минимальным числом изменений, так чтобы на ревью никто не устал это все отсматривать
Но ведь для этого существуют ветки, а не коммиты. Коммиты отвечают за итеративное достижение результата, а также позволяют отслеживать ход мыслей разработчика (иногда очень даже выручает, особенно если разработчик покинул проект). К тому же, независимо от количества коммитов, работает git diff upstream..topic, если кто-то из ревьюеров "может устать". Я понимаю, что нужно просматривать также и промежуточные коммиты, но не считаю это проблемой.

Z>* таким образом `git log` между 2 мя тэгами по сути есть changelog релиза
git log --merges: По смыслу и будет changelog-ом, независимо от количества коммитов, если напрямую фиксировать изменения в основные ветки запрещено.

Z>* коммиты в мастере не "перемешаны" -- одна фича/багфикс идет за другой
Слияния этому никак не противоречат. Другое дело, когда собщения merge-коммитов составляет какой-нибудь криво настроенный BitBucket -- тогда да, ад.

Z>* реверт в случае регрессии это 1 коммит
git revert -m. К тому же: а как откатить часть такого коммита без дополнительной возни с командами git и анализом всего (я так понимаю, может быть, и огромного) коммита?

Z>* в нем девелопер, до выхода не ревью пилит свою задачу за любое число коммитов с любыми комментариями... "сохраню ка я это перед сном/праздниками" или там "опс а сборка на платформе XYZ оказывается завалилась"... но как правило это нечто похожее на "фикс для теста", "фикс для теста #2", "фикс для теста (окончательный)", "фикс для другого теста после предидущего фикса" %)
git rebase -i. Это даже обсуждать не нужно.

Z>* но видеть все эти муки в общей истории (после того как готовая таска rebase'ится после squash'a в мастер) нафиг никому не надо -- в общей истории инересен только конечный результат
Частично согласен, но считаю, что git предоставляет средства получить желаемое представление логов, не меняя саму историю.

Здравствуйте, zaufi, Вы писали:

H>> Скорее, логическая стройность и простота поддержки такого подхода. Поэтому мне интересно, почему многие предпочитают squash.

Z>Мои 2 cents:

Z>* каждый коммит решает ровно одну таску минимальным числом изменений, так чтобы на ревью никто не устал это все отсматривать
Z>* соответственно жырные таски пилятся на более мелкие (обозримые на ревью)
Z>* ни какой коммит в мастера 100% не ломает сборку -- это важно! (как вы собираетесь `git bisect`ом искать виновника регрессии, если оно даже не собирается?)
Z>* в релиз уходит пачка решенных тикетов + какое-то число "косметических" коммитов (без тикетов, типа там `.gitignore` поправить или что-то подобное)

Пока всё нормально. Хотя эта "косметика" может помешать выделению для cherry-pick или реверта.

Z>* таким образом `git log` между 2 мя тэгами по сути есть changelog релиза

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

Z>* коммиты в мастере не "перемешаны" -- одна фича/багфикс идет за другой

Часто удобно, но гнаться за этим — бессмысленно.

Z>* реверт в случае регрессии это 1 коммит

Отловить все коммиты одного тикета по логу — банально. Поэтому не аргумент.

Z>* разработка конкретной фичи идет на девелоперском бранче
Z>* в нем девелопер, до выхода не ревью пилит свою задачу за любое число коммитов с любыми комментариями... "сохраню ка я это перед сном/праздниками" или там "опс а сборка на платформе XYZ оказывается завалилась"... но как правило это нечто похожее на "фикс для теста", "фикс для теста #2", "фикс для теста (окончательный)", "фикс для другого теста после предидущего фикса" %)

И что с того? Его задача потом — экспортировать в хорошо понятные изменения без внутренних проблем.

Z>* как правило даже самые простые таски не могут быть сделаны хорошо за 1 коммит
Z>* но видеть все эти муки в общей истории (после того как готовая таска rebase'ится после squash'a в мастер) нафиг никому не надо -- в общей истории инересен только конечный результат

Если коммиты были разных типов: реформатирование, рефакторинг, функциональное изменение — то после сквоша получится нечитаемая грязная каша.

Z>* комменты к коммиту, даже самому мелкому, описывают "как было" и "что стало", чтобы было что почитать в случае регрессии (ну это окромя номера таски, где может быть более детальное обсуждение)

Да, подробные сообщения полезны и недороги.

Здравствуйте, halo, Вы писали:

Z>>* каждый коммит решает ровно одну таску минимальным числом изменений, так чтобы на ревью никто не устал это все отсматривать
H>Но ведь для этого существуют ветки, а не коммиты. Коммиты отвечают за итеративное достижение результата, а также позволяют отслеживать ход мыслей разработчика (иногда очень даже выручает, особенно если разработчик покинул проект).

Из "мыслей разработчика" есть то, что нужно другим, и то, что не нужно.
Например, нафиг не нужно, что при изменении некоей сигнатуры он отработал это в трёх местах, а ещё в одном забыл. Или что он случайно зацепил клавишу и стёрлась какая-то строка, а потом он её возвращал. Или дебаг, который не должен поступать в ветку, а был нужен только локально, чтобы понять, что происходит в конкретном месте.
Такие вещи экспортировать не нужно. Нужно экспортировать другим уже законченное действие, вычищенное от подобных рабочих моментов (или его часть, если полное изменение слишком глобальное — например, несколько сотен файлов — но тогда надо, чтобы автотесты не ломались посредине).

А если это отделить, то как раз и получится, что коммит должен максимально описывать одно, логически атомарное изменение.

H> К тому же, независимо от количества коммитов, работает git diff upstream..topic, если кто-то из ревьюеров "может устать".

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

H> Я понимаю, что нужно просматривать также и промежуточные коммиты, но не считаю это проблемой.

Именно промежуточные как раз не проблема.

Здравствуйте, netch80, Вы писали:

N>Из "мыслей разработчика" есть то, что нужно другим, и то, что не нужно.
N>Например, нафиг не нужно, что при изменении некоей сигнатуры он отработал это в трёх местах, а ещё в одном забыл. Или что он случайно зацепил клавишу и стёрлась какая-то строка, а потом он её возвращал. Или дебаг, который не должен поступать в ветку, а был нужен только локально, чтобы понять, что происходит в конкретном месте.
N>Такие вещи экспортировать не нужно. Нужно экспортировать другим уже законченное действие, вычищенное от подобных рабочих моментов (или его часть, если полное изменение слишком глобальное — например, несколько сотен файлов — но тогда надо, чтобы автотесты не ломались посредине).

N>А если это отделить, то как раз и получится, что коммит должен максимально описывать одно, логически атомарное изменение.

Я ничего не говорил о шуме в истории, и тем более — в таком ключе. Если хочется пошуметь, то после веселья нужно убрать за собой помощью git rebase -i. Пока ветка живёт отдельно — пусть делают на ней что угодно, но пусть будут добры приведут в порядок до того, как ветку сольют в апстрим.

N>Не работает, если там начинают сочетаться изменения разного характера.
N>Отследить раздельно переформатирование для стиля, переименование, рефакторинг более сложного плана (типа, вынос общего кода) и целевое изменение функциональности — достаточно легко. Разобрать их в общей каше суммарного диффа — нереально.

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

Здравствуйте, halo, Вы писали:

H>Я ничего не говорил о шуме в истории, и тем более — в таком ключе. Если хочется пошуметь, то после веселья нужно убрать за собой помощью git rebase -i. Пока ветка живёт отдельно — пусть делают на ней что угодно, но пусть будут добры приведут в порядок до того, как ветку сольют в апстрим.

Оно было достаточно неясно описано, поэтому я решил прокомментировать. Если так — тем лучше.

H>Я вёл к тому, что изменение истории с помощью сквоша не стоит того, что дёшево достигается с помощью git diff. После сквоша при слиянии я вообще потеряю возможность разобрать коммит на составляющие, особенно если в ветке были массивные изменения.

Безусловно. Но тогда и по диффу цепочки коммитов вы фиг что поймёте.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, zaufi, Вы писали:

H>>> Скорее, логическая стройность и простота поддержки такого подхода. Поэтому мне интересно, почему многие предпочитают squash.

Z>>Мои 2 cents:

Z>>* каждый коммит решает ровно одну таску минимальным числом изменений, так чтобы на ревью никто не устал это все отсматривать
Z>>* соответственно жырные таски пилятся на более мелкие (обозримые на ревью)
Z>>* ни какой коммит в мастера 100% не ломает сборку -- это важно! (как вы собираетесь `git bisect`ом искать виновника регрессии, если оно даже не собирается?)
Z>>* в релиз уходит пачка решенных тикетов + какое-то число "косметических" коммитов (без тикетов, типа там `.gitignore` поправить или что-то подобное)

N>Пока всё нормально. Хотя эта "косметика" может помешать выделению для cherry-pick или реверта.

Z>>* таким образом `git log` между 2 мя тэгами по сути есть changelog релиза

N>Тут уже нет, если не делать принудительный сквош.

как раз и делается... (о чем и пишу). squash настроен в репе как единственный option влить фичу/багфикс с ветки в мастера.

N>Но можно в финальных коммитах фичи писать сообщение для changelog.

на squash'e оформляется единственное сообщение согласно последнему предписанию из моего списка

Z>>* коммиты в мастере не "перемешаны" -- одна фича/багфикс идет за другой

N>Часто удобно, но гнаться за этим — бессмысленно.

никто и не гонится, это получается само собой. фичи/багфиксы (1 коммит, после squash'a) просто вливаются в мастера (после прохождения review)... вот и получается...

Z>>* реверт в случае регрессии это 1 коммит

N>Отловить все коммиты одного тикета по логу — банально. Поэтому не аргумент.

ох... вот уж я бы не был так уверен %)

Z>>* разработка конкретной фичи идет на девелоперском бранче
Z>>* в нем девелопер, до выхода не ревью пилит свою задачу за любое число коммитов с любыми комментариями... "сохраню ка я это перед сном/праздниками" или там "опс а сборка на платформе XYZ оказывается завалилась"... но как правило это нечто похожее на "фикс для теста", "фикс для теста #2", "фикс для теста (окончательный)", "фикс для другого теста после предидущего фикса" %)

N>И что с того? Его задача потом — экспортировать в хорошо понятные изменения без внутренних проблем.

вот и я говорю, что как именно там дев что-то пилит никому не интересно -- важно чтобы после review и squash в мастера попал 1 коммит с вменяемым сообщением
и сразу отвечая на параллельные сообщения: *никому и никогда не интересно ни для какой истории* -- часто понять ход мыслей глядя на эти муки творчества попросту не реально... более менее реально на ревью получить комментарии о *финальном* ходе его мыслей, и попросить аккуратно все записать в финальном коммите... (тот что на squash'e)

Z>>* как правило даже самые простые таски не могут быть сделаны хорошо за 1 коммит
Z>>* но видеть все эти муки в общей истории (после того как готовая таска rebase'ится после squash'a в мастер) нафиг никому не надо -- в общей истории инересен только конечный результат

N>Если коммиты были разных типов: реформатирование, рефакторинг, функциональное изменение — то после сквоша получится нечитаемая грязная каша.

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

Здравствуйте, zaufi, Вы писали:

N>>Если коммиты были разных типов: реформатирование, рефакторинг, функциональное изменение — то после сквоша получится нечитаемая грязная каша.

Z>поэтому все эти "типы" это разные таски! во время багфиксинга (например) ни в коем случае не нужно пытаться переформатировать что-то (см. первый пункт про *минимальные изменения*). это отдельная задача и у нее будет отдельное ревью, впрочем не требующее особой концентрации внимания (это в том случае, если форматированием занимается не "робот", который снимает подобные вопросы вообще).

Что делать если при сохранение код отформатировался в соответствии с новыми правилами ?
Коммитить код без правильного форматирования, проект не пройдёт ревью, а с ним будут много изменений ?

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

Здравствуйте, zaufi, Вы писали:

со всем согласен, кроме:

N>>Отловить все коммиты одного тикета по логу — банально. Поэтому не аргумент.
Z>ох... вот уж я бы не был так уверен %)

Что мешает?

N>>Если коммиты были разных типов: реформатирование, рефакторинг, функциональное изменение — то после сквоша получится нечитаемая грязная каша.

Z>поэтому все эти "типы" это разные таски! во время багфиксинга (например) ни в коем случае не нужно пытаться переформатировать что-то (см. первый пункт про *минимальные изменения*). это отдельная задача и у нее будет отдельное ревью, впрочем не требующее особой концентрации внимания (это в том случае, если форматированием занимается не "робот", который снимает подобные вопросы вообще).

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

А на тему "во время багфиксинга не нужно пытаться переформатировать что-то" — вот тут как раз момент принципиальный. Это типичная ситуация, что добавление новой функциональности или багфиксинг требуют рефакторинга, а можно и зацепить место с наследственно кривыми форматированием, именованием переменных и т.п.; в таком случае тоже совершенно нормально отложить целевое изменение и уйти в прерывание, чтобы сделать новообнаруженную задачу. Потом по возврату из прерывания — восстановить контекст и продолжить отработку цели. А иногда бывает и 3-4 уровня вложенности такого прерывания — ну вот пришло время активно "потрогать" какой-то код.
Причём выделение может происходить на ходу, после того, как замечено, что вот эти 10 мест изменений из уже сделанных 30 логически оказывается другой операцией — и тогда начинаешь понимать, зачем в git сделали индекс.
Но выделять под это отдельную задачу на формальном уровне, только чтобы тегировать ею коммит? Анакойхер такое сдалось?

Здравствуйте, _NN_, Вы писали:

Z>>поэтому все эти "типы" это разные таски! во время багфиксинга (например) ни в коем случае не нужно пытаться переформатировать что-то (см. первый пункт про *минимальные изменения*). это отдельная задача и у нее будет отдельное ревью, впрочем не требующее особой концентрации внимания (это в том случае, если форматированием занимается не "робот", который снимает подобные вопросы вообще).

_NN>Что делать если при сохранение код отформатировался в соответствии с новыми правилами ?

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

Здравствуйте, zaufi, Вы писали:

z> поэтому все эти "типы" это разные таски! во время багфиксинга (например) ни в коем случае не нужно пытаться переформатировать что-то (см. первый пункт про *минимальные изменения*). это отдельная задача и у нее будет отдельное ревью, впрочем не требующее особой концентрации внимания (это в том случае, если форматированием занимается не "робот", который снимает подобные вопросы вообще).
Ну вот, всё понятно теперь. Обычно эти "таски" в git и являются коммитами. А так как вы всё сквошите и коммиты по прямому назначению не используете, вам теперь пришлось перемещать эту информацию в таск-трекер. Так себе решение, ибо всё стало только сложнее, т.к. в двух местах.

Здравствуйте, ·, Вы писали:

·>Здравствуйте, zaufi, Вы писали:

z>> поэтому все эти "типы" это разные таски! во время багфиксинга (например) ни в коем случае не нужно пытаться переформатировать что-то (см. первый пункт про *минимальные изменения*). это отдельная задача и у нее будет отдельное ревью, впрочем не требующее особой концентрации внимания (это в том случае, если форматированием занимается не "робот", который снимает подобные вопросы вообще).
·>Ну вот, всё понятно теперь. Обычно эти "таски" в git и являются коммитами. А так как вы всё сквошите и коммиты по прямому назначению не используете, вам теперь пришлось перемещать эту информацию в таск-трекер. Так себе решение, ибо всё стало только сложнее, т.к. в двух местах.

говоря "задача" в вырванном контесте выше, я не имел ввиду ticket в bug tracker... %)

раз это не столь очевидно поясню: конечно же нет смысла делать в трэкере таски, на выполнение которых не требуется серьезного времени или их суть тривиальна -- например вот форматирование, или исправить что-нибудь по мелочи. Такие коммиты просто помечаются "тэгом" в subject'e (первая строка комментария отделяемая от остальных пустой строкой):

— "Documentation: Rephrase the introduction paragraph"
— "Build: Fix the pattern for file glob expression on install"
— "Reformat: Fix the legacy file code style"
— "Misc: Update linter config to include features of the latest release"

но все равно проходят review, ибо даже простые вещи делаются с недочетами...

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, zaufi, Вы писали:

N>со всем согласен, кроме:

N>>>Отловить все коммиты одного тикета по логу — банально. Поэтому не аргумент.
Z>>ох... вот уж я бы не был так уверен %)

N>Что мешает?

например

— вам никогда не доводилось разгребать чужое ммм... ну назовем это витееватый ход мысли оригинального автора.
— или запуская скажем `git log` вам открывается просто список хэшей и самый длинный коментарий это "я устал и пошел спать" %)

и как бы вы ни старались найти в этой пустоте номер тикета... ну не получается от слова "никак" %)


N>Но выделять под это отдельную задачу на формальном уровне, только чтобы тегировать ею коммит? Анакойхер такое сдалось?

кажется волну негодования вызывает недопонимание значения слово "задача", когда речь начиналась о "тикетах" и потом появилось это неоднозначное "задача" %)

чтобы успокоить всех участников дискуссии: не для каждой задачи, создается отдельный ticket/issue в bug tracker -- создавать или нет, решайте для себя сами %)

Здравствуйте, zaufi, Вы писали:

Z>например

Z>- вам никогда не доводилось разгребать чужое ммм... ну назовем это витееватый ход мысли оригинального автора.
Z>- или запуская скажем `git log` вам открывается просто список хэшей и самый длинный коментарий это "я устал и пошел спать" %)

Z>и как бы вы ни старались найти в этой пустоте номер тикета... ну не получается от слова "никак" %)

Извините, это уже подтасовка тезиса. Если есть сколь-нибудь реальный контроль со всякими peer review, пристальным взглядом начальства и т.п., то коммиты без номера тикета и с "пошёл спать" не пройдут этот самый входной контроль. И при этом уже неважно, был один коммит на тикет или их было 100500 и не подряд в истории.
А если нет такого контроля, и нет нормального самоконтроля, то там любой мусор будет и говорить вообще не о чем.

N>>Но выделять под это отдельную задачу на формальном уровне, только чтобы тегировать ею коммит? Анакойхер такое сдалось?
Z>кажется волну негодования вызывает недопонимание значения слово "задача", когда речь начиналась о "тикетах" и потом появилось это неоднозначное "задача" %)

Вполне возможно, да.

Здравствуйте, zaufi, Вы писали:

z> но все равно проходят review, ибо даже простые вещи делаются с недочетами...
А как же вы отличаете "таски", которые вроде как "настоящие" коммиты, от каких-то ходов мысли "фикс фикса теста"?
И причём тут вообще squash? По уму squash/rebase/whatever делать должен тот кто отправляет коммиты на ревью; а ревьювер это должен контролировать, что каждый коммит, попадающий в мастер соответствующего качества.