Имеется следующая ситуация. В ветке, при замене одного компонента на другой, один из разработчиков реализовал выпил старого и запил нового в одном коммите. На мои возражения, что такие изменения лучше делать в отдельных коммитах (причём, промежуточные коммиты не ломают сборку), он отказался от разбивки коммита на два до слияния его в основную ветвь. Хорошо, пускай, мне и для процесса разработки это не принципиально, и тратить время на споры я совсем не хочу. Я приверженец следующего подхода:
* 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
Хотя, очевидно, были разговоры и о таком раскладе:
* 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 — то так и скажите коллегам, а если их в шею гонят, да ещё и ерунду требуют, то
Преимущества не-squash+merge и squash+merge/squash в 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 в мастер) нафиг никому не надо -- в общей истории инересен только конечный результат
* комменты к коммиту, даже самому мелкому, описывают "как было" и "что стало", чтобы было что почитать в случае регрессии (ну это окромя номера таски, где может быть более детальное обсуждение)
на вскидку вот что приходит на ум...
Re[2]: Преимущества не-squash+merge и squash+merge/squash в Git
Здравствуйте, zaufi, Вы писали:
z> * комменты к коммиту, даже самому мелкому, описывают "как было" и "что стало", чтобы было что почитать в случае регрессии (ну это окромя номера таски, где может быть более детальное обсуждение)
Вы просто "неклассически" используете git. Лучше всего такой процесс контролировать например через Gerrit. Там такой подход — как родной, притом без потери информации. Например, один большой коммит, который делает всё — не только сложнее ревьювить, но и хуже отслеживается по истории, особенно если были перемещения кусков кода между файлами.
Классически же когда ты мержишь или отправляешь на ревью ветку, то ты готовишь её специально с помощью rebase&Co. Тогда никаких "фиксов для фиксов теста" никто кроме тебя не будет видеть.
Оба подхода "всё сквошим" и "мержим что есть" — две крайности, обе плохие. Идеал в балансе.
Не соглашусь со следующими тезисами:
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 предоставляет средства получить желаемое представление логов, не меняя саму историю.
Re[2]: Преимущества не-squash+merge и squash+merge/squash в 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>* комменты к коммиту, даже самому мелкому, описывают "как было" и "что стало", чтобы было что почитать в случае регрессии (ну это окромя номера таски, где может быть более детальное обсуждение)
Да, подробные сообщения полезны и недороги.
The God is real, unless declared integer.
Re[3]: Преимущества не-squash+merge и squash+merge/squash в Git
Здравствуйте, halo, Вы писали:
Z>>* каждый коммит решает ровно одну таску минимальным числом изменений, так чтобы на ревью никто не устал это все отсматривать H>Но ведь для этого существуют ветки, а не коммиты. Коммиты отвечают за итеративное достижение результата, а также позволяют отслеживать ход мыслей разработчика (иногда очень даже выручает, особенно если разработчик покинул проект).
Из "мыслей разработчика" есть то, что нужно другим, и то, что не нужно.
Например, нафиг не нужно, что при изменении некоей сигнатуры он отработал это в трёх местах, а ещё в одном забыл. Или что он случайно зацепил клавишу и стёрлась какая-то строка, а потом он её возвращал. Или дебаг, который не должен поступать в ветку, а был нужен только локально, чтобы понять, что происходит в конкретном месте.
Такие вещи экспортировать не нужно. Нужно экспортировать другим уже законченное действие, вычищенное от подобных рабочих моментов (или его часть, если полное изменение слишком глобальное — например, несколько сотен файлов — но тогда надо, чтобы автотесты не ломались посредине).
А если это отделить, то как раз и получится, что коммит должен максимально описывать одно, логически атомарное изменение.
H> К тому же, независимо от количества коммитов, работает git diff upstream..topic, если кто-то из ревьюеров "может устать".
Не работает, если там начинают сочетаться изменения разного характера.
Отследить раздельно переформатирование для стиля, переименование, рефакторинг более сложного плана (типа, вынос общего кода) и целевое изменение функциональности — достаточно легко. Разобрать их в общей каше суммарного диффа — нереально.
H> Я понимаю, что нужно просматривать также и промежуточные коммиты, но не считаю это проблемой.
Именно промежуточные как раз не проблема.
The God is real, unless declared integer.
Re[4]: Преимущества не-squash+merge и squash+merge/squash в Git
Здравствуйте, netch80, Вы писали:
N>Из "мыслей разработчика" есть то, что нужно другим, и то, что не нужно. N>Например, нафиг не нужно, что при изменении некоей сигнатуры он отработал это в трёх местах, а ещё в одном забыл. Или что он случайно зацепил клавишу и стёрлась какая-то строка, а потом он её возвращал. Или дебаг, который не должен поступать в ветку, а был нужен только локально, чтобы понять, что происходит в конкретном месте. N>Такие вещи экспортировать не нужно. Нужно экспортировать другим уже законченное действие, вычищенное от подобных рабочих моментов (или его часть, если полное изменение слишком глобальное — например, несколько сотен файлов — но тогда надо, чтобы автотесты не ломались посредине).
N>А если это отделить, то как раз и получится, что коммит должен максимально описывать одно, логически атомарное изменение.
Я ничего не говорил о шуме в истории, и тем более — в таком ключе. Если хочется пошуметь, то после веселья нужно убрать за собой помощью git rebase -i. Пока ветка живёт отдельно — пусть делают на ней что угодно, но пусть будут добры приведут в порядок до того, как ветку сольют в апстрим.
N>Не работает, если там начинают сочетаться изменения разного характера. N>Отследить раздельно переформатирование для стиля, переименование, рефакторинг более сложного плана (типа, вынос общего кода) и целевое изменение функциональности — достаточно легко. Разобрать их в общей каше суммарного диффа — нереально.
Я вёл к тому, что изменение истории с помощью сквоша не стоит того, что дёшево достигается с помощью git diff. После сквоша при слиянии я вообще потеряю возможность разобрать коммит на составляющие, особенно если в ветке были массивные изменения.
Re[5]: Преимущества не-squash+merge и squash+merge/squash в Git
Здравствуйте, halo, Вы писали:
H>Я ничего не говорил о шуме в истории, и тем более — в таком ключе. Если хочется пошуметь, то после веселья нужно убрать за собой помощью git rebase -i. Пока ветка живёт отдельно — пусть делают на ней что угодно, но пусть будут добры приведут в порядок до того, как ветку сольют в апстрим.
Оно было достаточно неясно описано, поэтому я решил прокомментировать. Если так — тем лучше.
H>Я вёл к тому, что изменение истории с помощью сквоша не стоит того, что дёшево достигается с помощью git diff. После сквоша при слиянии я вообще потеряю возможность разобрать коммит на составляющие, особенно если в ветке были массивные изменения.
Безусловно. Но тогда и по диффу цепочки коммитов вы фиг что поймёте.
The God is real, unless declared integer.
Re[3]: Преимущества не-squash+merge и squash+merge/squash в Git
Здравствуйте, 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>Если коммиты были разных типов: реформатирование, рефакторинг, функциональное изменение — то после сквоша получится нечитаемая грязная каша.
поэтому все эти "типы" это разные таски! во время багфиксинга (например) ни в коем случае не нужно пытаться переформатировать что-то (см. первый пункт про *минимальные изменения*). это отдельная задача и у нее будет отдельное ревью, впрочем не требующее особой концентрации внимания (это в том случае, если форматированием занимается не "робот", который снимает подобные вопросы вообще).
Re[4]: Преимущества не-squash+merge и squash+merge/squash в Git
Здравствуйте, zaufi, Вы писали:
N>>Если коммиты были разных типов: реформатирование, рефакторинг, функциональное изменение — то после сквоша получится нечитаемая грязная каша.
Z>поэтому все эти "типы" это разные таски! во время багфиксинга (например) ни в коем случае не нужно пытаться переформатировать что-то (см. первый пункт про *минимальные изменения*). это отдельная задача и у нее будет отдельное ревью, впрочем не требующее особой концентрации внимания (это в том случае, если форматированием занимается не "робот", который снимает подобные вопросы вообще).
Что делать если при сохранение код отформатировался в соответствии с новыми правилами ?
Коммитить код без правильного форматирования, проект не пройдёт ревью, а с ним будут много изменений ?
Я знаю, что такое починка бага без рефакторинга в случае, когда он требуется.
Получается файл монстр в котором спустя годы не разобраться и проще переписать, но переписать нет времени.
со всем согласен, кроме:
N>>Отловить все коммиты одного тикета по логу — банально. Поэтому не аргумент. Z>ох... вот уж я бы не был так уверен %)
Что мешает?
N>>Если коммиты были разных типов: реформатирование, рефакторинг, функциональное изменение — то после сквоша получится нечитаемая грязная каша.
Z>поэтому все эти "типы" это разные таски! во время багфиксинга (например) ни в коем случае не нужно пытаться переформатировать что-то (см. первый пункт про *минимальные изменения*). это отдельная задача и у нее будет отдельное ревью, впрочем не требующее особой концентрации внимания (это в том случае, если форматированием занимается не "робот", который снимает подобные вопросы вообще).
То есть вы просто перемаркировали сущности. Раз что-то требует отдельного коммита, чтобы разобраться — помечаем его отдельной задачей. Подход понятен, но по сути ничем не отличается от троллейбуса из буханки: все необходимые цели достигаются точно так же и без формального выделения задачи.
А на тему "во время багфиксинга не нужно пытаться переформатировать что-то" — вот тут как раз момент принципиальный. Это типичная ситуация, что добавление новой функциональности или багфиксинг требуют рефакторинга, а можно и зацепить место с наследственно кривыми форматированием, именованием переменных и т.п.; в таком случае тоже совершенно нормально отложить целевое изменение и уйти в прерывание, чтобы сделать новообнаруженную задачу. Потом по возврату из прерывания — восстановить контекст и продолжить отработку цели. А иногда бывает и 3-4 уровня вложенности такого прерывания — ну вот пришло время активно "потрогать" какой-то код.
Причём выделение может происходить на ходу, после того, как замечено, что вот эти 10 мест изменений из уже сделанных 30 логически оказывается другой операцией — и тогда начинаешь понимать, зачем в git сделали индекс.
Но выделять под это отдельную задачу на формальном уровне, только чтобы тегировать ею коммит? Анакойхер такое сдалось?
The God is real, unless declared integer.
Re[5]: Преимущества не-squash+merge и squash+merge/squash в Git
Здравствуйте, _NN_, Вы писали:
Z>>поэтому все эти "типы" это разные таски! во время багфиксинга (например) ни в коем случае не нужно пытаться переформатировать что-то (см. первый пункт про *минимальные изменения*). это отдельная задача и у нее будет отдельное ревью, впрочем не требующее особой концентрации внимания (это в том случае, если форматированием занимается не "робот", который снимает подобные вопросы вообще).
_NN>Что делать если при сохранение код отформатировался в соответствии с новыми правилами ?
Выделить это форматирование (если оно тут автоматическое) в отдельную операцию, отдельным коммитом, причём обязательно _перед_ более сущностными изменениями, даже такими, как переименование.
Обязательно пометить, что это изменение сделано автоматически — это поможет ревьюерам правильно настроить взгляд на поиск именно последствий неверной работы автомата.
Если коммит с изменением по сути уже состоялся — он должен быть перебазирован поверх того, что меняет форматирование.
The God is real, unless declared integer.
Re[4]: Преимущества не-squash+merge и squash+merge/squash в Git
Здравствуйте, 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, ибо даже простые вещи делаются с недочетами...
Re[5]: Преимущества не-squash+merge и squash+merge/squash в
Здравствуйте, 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>кажется волну негодования вызывает недопонимание значения слово "задача", когда речь начиналась о "тикетах" и потом появилось это неоднозначное "задача" %)
Вполне возможно, да.
The God is real, unless declared integer.
Re[6]: Преимущества не-squash+merge и squash+merge/squash в Git
Здравствуйте, zaufi, Вы писали:
z> но все равно проходят review, ибо даже простые вещи делаются с недочетами...
А как же вы отличаете "таски", которые вроде как "настоящие" коммиты, от каких-то ходов мысли "фикс фикса теста"?
И причём тут вообще squash? По уму squash/rebase/whatever делать должен тот кто отправляет коммиты на ревью; а ревьювер это должен контролировать, что каждый коммит, попадающий в мастер соответствующего качества.