Comments 17
Сначала подумал точно так же, но потом сходил почитать про git add -i.
Почему-то не приходило в голову, что такую мелочь уже интегрировали в Git, и раньше не пользовался по незнанию, но определённо полезная вещь, которая сэкономила бы немало времени и лаконичности коммитам, если бы прошлый я озаботился чтением мануала.
Каждый коммит должен содержать только одно изменение — избегайте небольших несвязанных изменений в одном коммите (в этом отношении я мог бы почаще прислушиваться к собственным советам).
Как-то следовал я этому правилу пока не потеря работу целого дня после сбоя кобмпьютера. И тогда я подумал что лучше коммитов будет больше. По бренчам — да — один бренч одна фича.
Не буду додумывать за автора, но зачастую это имеет место быть для staging/stable веток и в принципе это довольно хороший тон — не засорять основные ветки мусорными коммитами. Но почему-то мало кто из "гуру статей по гиту" оговаривает, что всем пофигу, что творится с историей коммитов в ветках с фичами и воспринимать это как общее руководство не стоит. Ничто не мешает потом влить одним коммитом в мастер.
Возможно, из-за того что эти материалы расчитаны на новичков, которые в пет-проектах используют одну (или две) ветки, и версионируют всё подряд, при этом перенося такой опыт на профессиональные проекты в будущем.
Это со времен текстовых видеорежимов и «алфавитно-цифровых печатающих устройств», знакоместа в которых образовывали прямоугольную матрицу и адресовались строкой и столбцом (колонкой). Сейчас так адресуют пиксели.
До появления SuperVGA таких столбцов на экране IBM-совместимых компьютеров было 80 или 40.
Мы используем 72 символа, потому что это стандартная ширина сообщения электронной почты
При этом в RFC по ссылке про длину строки сказано: «should be no more than 78 characters, excluding the CRLF», а «72» не встречается нигде. (И да, «should be» здесь значит рекомендуется", а жесткое ограничение прописано так: «MUST be no more than 998 characters»).
Это, разумеется, претензия в сторону автора, а не переводчика.
а «72» не встречается нигде
это Вы, конечно, погорячились (или речь только про RFC?)
см. официальную книгу по Git 5.2 Contributing to a Project: Here is a template originally written by Tim Pope (в русской версии этой ссылки нет)
Let’s start with a few of the reasons why wrapping your commit messages to 72 columns is a good thing.
Также How to Write a Git Commit Message#Wrap the body at 72 characters (русский перевод на Хабре)
Советы по организации работы c Git