Как стать автором
Обновить

Комментарии 30

Описывать флоу по скриншотам одной IDE — плохая идея (тем более, что в статье даже не упоминается, что это за IDE). Такая статья должна называться "Работа с git в webstorm" или вроде того.

Пардон, название IDE со второй попытки отыскал, но статью все равно лучше переименовать :)

Да, Вы правы, спасибо. Исправил, совсем забыл про смежные продукты.
Вы создали большой PR с большим количеством коммитов, да перед пушем заметили, что одно из сообщений некорректно и было бы неплохо его отредактировать, пока жесткий ревьювер не четвертовал Вас за такую оплошность

Э… Если код ревьювер докопается до моего коммита с комментарием "#ля, очепятка", я приложу все усилия, чтобы его гнали ссаными тряпками.

Из чего я делаю вывод, что вы никогда не работали в крупных проектах и тем паче в opensource-проектах. Попросить поправить history в PR — элементарно. У ansible, например, есть даже спецпроверка, чтобы не присылали PR из 100500 коммитов "typo" или "pleasing ci".

Commit, push, сборка упала, commit "typo fix" ещё раз — разве так не бывает?

НЛО прилетело и опубликовало эту надпись здесь

Конечно, бывает. В вашем личном бранче/репе — да. А когда вы приходите в большой проект с тысячами коммитеров и десятками тысяч коммитов в месяц, никому ваши typo не нужны. Присылаете код на PR, вам указывают на недостатки, устраняете, воююете с CI, ублажаете linter'ов, выполняете капризы reviewer'ов. После этого идёте и делаете умный rebase в один-два-три коммита, каждый из которых содержит 5-10 строк описания. Пушаете с форсом (можете старую историю сохранить для истории где-то в другом бранче), после этого оно мержится в основной апстрим.

Из чего я делаю вывод, что вы никогда не работали в крупных проектах

Неправильный вывод :)
и тем паче в opensource-проектах

Это да, то есть не имел дело настолько серьёзно.

Правка истории коммитов, IMHO, порочная практика. Она маскирует реальную картину происходящего. Коммент коммита поправить — да, но и только.

Из этого я делаю вывод о том, какой проект вы считаете "крупным". Ваши локальные корпоративные 300к строк js фронт/бэкэнда — это не крупный проект.


Условный — postgres, ansible, react — это крупные проекты.

$ find . -name '*.[cpp|h]' | wc -l 
14330
$ find . -name '*.[cpp|h]' | xargs cat | wc -l                                                        
5282953


Это прошлый. Нынешний поскромней, примерно вот такой:

$ find . -name '*.[c|h]' | wc -l                                                                       
12290
$ find . -name '*.[c|h]' | xargs cat | wc -l 
1374514

И в этом замечательном проекте у вас коммиты вида 'typo'? Ух. А сколько у вас коллег в git'е? И сколько PR'ов за последний месяц было смержено?

В обоих проектах структура тянется давно. В первом с 1994, во втором с 1979 :) Конечно, не всегда был гит. Но были (и есть) подпроекты, у каждого своя команда. В данный момент в моём подпроекте 8 человек. Всего в проекте около 200. Тестировние, вливание «под» в общее целое — отдельный вопрос. Но никогда «вопрос typo» не стоял. Вплоть до того, что исправление одной циферки в копирайте делается отдельным коммитом уже после code review в PR (но до принятия, само собой). Без правки истории.

Циферка в копирайте вполне тянет на отдельный коммит. А вот исправление pritnf на printf в свежем PR — нет.


История неизменна в master и прочих shared branches. А вот в личной песочнице (т.е. до мержа PR) нужно и можно ребейзить, сквошить и приводить историю в такой вид, с которым можно работать.

print не прорвётся через unit-тест, мимо.
нужно и можно

Можно. Но живы же как-то до сих пор :) И нормально живём.
IMHO, порочная практика. Она маскирует реальную картину происходящего

Можете пояснить мысль?

У нас был спор, про обратную сторону. Поясню на грубом примере — Мы долгое время спорили, можно ли рабочий код и его тестирование разделять отдельными коммитами? Лучше так не делать. Когда вы решаете откатить фичу, то прыгая по хистори коммитов, очень легко погрязнуть в фантазии автора и забыть вырезать некоторые части. Те ваша функциональность и ее тестирование должны быть поданы одной неделимой частью.
А в тему реальной картине происходящего — тут скорее про правильную декомпозицию задач стоит вести речь.
можно ли рабочий код и его тестирование разделять отдельными коммитами?

Вот тут я совсем потерял мысль :) Есть юнит-тесты, в моём случае это CUnit на каждый чих (хоть и ненавижу эту бюрократию, но надо, и оно оправдывается — иногда такие банальные ляпы бывают). Вот буквально сегодня столкнулся с тем, что попросили поправить аж на уровне pull request. А коммиты… дело интимное. Ну, не на уровне Ctrl+S, но близко.
Счастливчик… GIT… Раньше я не любил его. А потом поработал с перфорсом…
«сократит время разработки в разы» — пишу код 8 часов, commit/push 1 мин
В корне с Вами несогласен. Писать код/документацию/структурировать процесс и результат — это все есть результат вашей работы. Писать код — это одна часть повседневных будней.
Регулярно доводится работать с кодом таких писателей.
Как правило его просто выкидывают. Потому что без документации с говнокодом не может разобраться даже сам автор через пол года и не остается ничего кроме как выбросить код и написать заново.
Впрочем подавляющее большинство компаний вообще не выделяет время на написание документации и даже если ты нормальный программист — либо документируй за счет собственного времени, либо никак.
Компромисс — работай 8 часов, пиши код 4.
Да, Вы абсолютно правы.
Я лишь хотел обратить внимание на то, где хранятся такие настройки и что файл с настройками легко может попасть под юрисдикцию .gitignore

Rebase вы тоже как-то странно вызываете, когда есть меню:


По работе с VCS в IDEA-образных могу отметить лишь удобное side-by-side разрешение конфликтов и diff при коммите, из которого можно достаточно удобно отделять нужные изменения от тех, которые либо должны уйти в другой коммит, либо и вовсе написаны для отладки.


В остальном интерфейс локализован довольно плохо относительно того, что git делает под капотом, местами неочевиден и ИМХО вообще вреден тем, кто не очень знаком с git.

— Заскво… Что?
после апрува пул реквеста
Тонкий юмор
Спасибо за статью, кое-что почерпнул для себя. Можно про git-hooks более подробно рассказать? ИМХО менее очевидная штука, чем IssueNavigationLink. Именно как настроить формирование commit-message по шаблону? И может ли сформированное сообщение появляться в окошке commit changes перед комитом?
Это больше на другую статью тянет. Проблема в том, что знакомые мне GUIни, не поддерживают форму работы с git hook-ами(хотя я и сам слабо представляю как это можно «продать» красиво). Подробно описано здесь.

Именно как настроить формирование commit-message по шаблону?

Подключите pre-commit hook, проанализируйте входящее сообщение и доработайте его. Пример можно найти здесь.

И может ли сформированное сообщение появляться в окошке commit changes перед комитом?

Да, можно все что угодно. На что хватит Вашей фантазии.
На одном проекте, видел хуки, которые вырезали номер задачи из наименования ветки(а на ее формирование стояли свои правила) и подставляли префикс номера задачи в коммит мессадж.
Спасибо за подсказку!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.