Комментарии 31
Описывать флоу по скриншотам одной IDE — плохая идея (тем более, что в статье даже не упоминается, что это за IDE). Такая статья должна называться "Работа с git в webstorm" или вроде того.
Из чего я делаю вывод, что вы никогда не работали в крупных проектах и тем паче в opensource-проектах. Попросить поправить history в PR — элементарно. У ansible, например, есть даже спецпроверка, чтобы не присылали PR из 100500 коммитов "typo" или "pleasing ci".
Commit, push, сборка упала, commit "typo fix" ещё раз — разве так не бывает?
Конечно, бывает. В вашем личном бранче/репе — да. А когда вы приходите в большой проект с тысячами коммитеров и десятками тысяч коммитов в месяц, никому ваши typo не нужны. Присылаете код на PR, вам указывают на недостатки, устраняете, воююете с CI, ублажаете linter'ов, выполняете капризы reviewer'ов. После этого идёте и делаете умный rebase в один-два-три коммита, каждый из которых содержит 5-10 строк описания. Пушаете с форсом (можете старую историю сохранить для истории где-то в другом бранче), после этого оно мержится в основной апстрим.
У нас вот есть мелкий проект на 2 млн строк кода. commit,push, commit - не запрещено технически но в правила четка сказано - squash
кстати merge дева тоже запрещен - rebase
Из этого я делаю вывод о том, какой проект вы считаете "крупным". Ваши локальные корпоративные 300к строк js фронт/бэкэнда — это не крупный проект.
Условный — postgres, ansible, react — это крупные проекты.
И в этом замечательном проекте у вас коммиты вида 'typo'? Ух. А сколько у вас коллег в git'е? И сколько PR'ов за последний месяц было смержено?
IMHO, порочная практика. Она маскирует реальную картину происходящего
Можете пояснить мысль?
У нас был спор, про обратную сторону. Поясню на грубом примере — Мы долгое время спорили, можно ли рабочий код и его тестирование разделять отдельными коммитами? Лучше так не делать. Когда вы решаете откатить фичу, то прыгая по хистори коммитов, очень легко погрязнуть в фантазии автора и забыть вырезать некоторые части. Те ваша функциональность и ее тестирование должны быть поданы одной неделимой частью.
А в тему реальной картине происходящего — тут скорее про правильную декомпозицию задач стоит вести речь.
Как правило его просто выкидывают. Потому что без документации с говнокодом не может разобраться даже сам автор через пол года и не остается ничего кроме как выбросить код и написать заново.
Впрочем подавляющее большинство компаний вообще не выделяет время на написание документации и даже если ты нормальный программист — либо документируй за счет собственного времени, либо никак.
Отредактируем файл project/.idea/vcs.xml:
Зачем лезть в файлы, когда для этого есть настройка?
Rebase вы тоже как-то странно вызываете, когда есть меню:
По работе с VCS в IDEA-образных могу отметить лишь удобное side-by-side разрешение конфликтов и diff при коммите, из которого можно достаточно удобно отделять нужные изменения от тех, которые либо должны уйти в другой коммит, либо и вовсе написаны для отладки.
В остальном интерфейс локализован довольно плохо относительно того, что git делает под капотом, местами неочевиден и ИМХО вообще вреден тем, кто не очень знаком с git.
— Заскво… Что?Тонкий юмор
после апрува пул реквеста
Именно как настроить формирование commit-message по шаблону?
Подключите pre-commit hook, проанализируйте входящее сообщение и доработайте его. Пример можно найти здесь.
И может ли сформированное сообщение появляться в окошке commit changes перед комитом?
Да, можно все что угодно. На что хватит Вашей фантазии.
На одном проекте, видел хуки, которые вырезали номер задачи из наименования ветки(а на ее формирование стояли свои правила) и подставляли префикс номера задачи в коммит мессадж.
ПШЕ AndroidStudio или как использовать VCS Tools по полной