Вот, как-то увидел историю коммитов одного проекта — и мне стало стыдно. Эту историю можно было читать как книгу — как летопись. Одна строчка за другой.
Коммиты делались только кода добавлено что-то значительное.
Видимо в какой-то момент количество коммитов стало одной из метрик живости проекта и стало модно делать коммит на каждый чих.
С другой стороны, если еще не доделал, но хочешь на всякий случай забекапить работу — то тоже разумно сделать коммит.
Здравствуйте, Shmj, Вы писали:
S>Видимо в какой-то момент количество коммитов стало одной из метрик живости проекта и стало модно делать коммит на каждый чих. S>С другой стороны, если еще не доделал, но хочешь на всякий случай забекапить работу — то тоже разумно сделать коммит.
S>Как делаете вы?
А что, выбранная система контроля версий не поддерживает squash? Может тогда в топку её?
По ходу пьесы коммитишь, чтобы не потерять изменения в процессе экспериментов.
Потом сквошишь до необходимого числа значимых коммитов и отправляешь в репу.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Shmj, Вы писали:
S>Как делаете вы?
Одно цельное логическое изменение — один коммит. Размер изменений абсолютно неважен. Да, исправить опечатку это почти всегда отдельный коммит.
Когда только начинаю работать над проектом — вообще ничего не коммичу. Иногда делаю бэкапы вручную.
Когда готова какая-то версия, которую можно кому-то показывать — делаю первый коммит. После этого обычно коммичу каждую мелочь. Иногда, если устраиваю большие переработки кода, то не коммичу в это время. Но вообще стараюсь этим не увлекаться, считаю, что большинство больших переработок кода можно разбить на несколько маленьких.
В целом я не отношусь к истории коммитов как-то серьёзно. Я в курсе, что многим она помогает, но я никогда в такой ситуации не оказывался, чтобы мне приходилось разбираться с историей коммитов. Поэтому тратить на подготовку коммита какое-то нетривиальное время считаю избыточным. Моё сообщение о коммите обычно это краткое описание изменений, чтобы можно было его прочитать, а не лезть в diff-ы, вот и всё.
Здравствуйте, Shmj, Вы писали:
S>Вот, как-то увидел историю коммитов одного проекта — и мне стало стыдно. Эту историю можно было читать как книгу — как летопись. Одна строчка за другой.
S>Коммиты делались только кода добавлено что-то значительное.
А мелочи как шли? Молча прикреплялись к чему-то значительному? Или авторы проекта были столь велики, что у них никогда не возникало необходимости вносить мелкие правки?
Здравствуйте, Shmj, Вы писали:
S>С другой стороны, если еще не доделал, но хочешь на всякий случай забекапить работу — то тоже разумно сделать коммит. S>Как делаете вы?
Хотел ответить. Почитал ветку и по схожести ответов понял, что более-менее опытные разработчики делают примерно одинаково. Сам бы я ответил также.
Что опять натолкнуло меня на мысль, что ты опять флудишь: создаешь какие-то пустые темы на каждый элементарный чих.
Ну это, как, например, спрашивать: вы набираете двумя руками или одним пальцем. Или: зажимать левый шифт или правый. Ну какой смысл
Да как удобно — так и комить. С опытом (если еще не) придет понимание, как у других ответивших выше.
А если есть конкретный вопрос: почему надо группировать коммиты по смыслу, зачем сквош или почему очепятки надо отдельным коммитом — то так и спрашивай.
Здравствуйте, vsb, Вы писали:
vsb>В целом я не отношусь к истории коммитов как-то серьёзно. Я в курсе, что многим она помогает, но я никогда в такой ситуации не оказывался, чтобы мне приходилось разбираться с историей коммитов.
Даже если работаешь один, есть как минимум 3 очень полезных момента от хороших коммитов:
1. git bisect и поиск коммита в котором появился баг
2. объснение какой-то нетревиальной логики. Это лучше, чем комментарий в коде, т.к. видно к каким именно изменениям он относится (которые могут быть в разных файлах)
3. необходимость точного формулирования изменений и их причин.
Здравствуйте, Shmj, Вы писали:
S> стало модно делать коммит на каждый чих.
S>С другой стороны, если еще не доделал, но хочешь на всякий случай забекапить работу — то тоже разумно сделать коммит.
Видимо, придётся работать по-старинке: коммитить только полностью завершённую фичу, а по вечерам ежедневно делать отдельный zip и сохранять где-то в облаке — так наиболее оптимально.
По идее, коммитить надо чуть ли не каждый чих, потому что если ты изменил DTO, к примеру, а на следующий день понял, что ошибся, ты должен спокойно восстановить этот файл. Но факт тот, что мне проще тупо залезть в zip и достать файл, чем лазить по истории, искать нужный коммит, а потом ещё аккуратно откатываться, боясь, что всё к хренам потеряется (тем более, что помимо изменения DTO, ты мог опосля ещё много чего накоммитить). Другими словами, VCS хоть и пришла на помощь, "ручное версионирование" никуда не делось, у нас по прежнему нет УДОБНОГО способа управлять сорсами.
Здравствуйте, Skorodum, Вы писали:
S>2. объснение какой-то нетревиальной логики. Это лучше, чем комментарий в коде, т.к. видно к каким именно изменениям он относится (которые могут быть в разных файлах)
Кстати, это не обязательно хорошо. Я в таких случаях пишу по комментарию в каждом месте в каждом файле, где это всё сдеално. Если я соберуь менять отдельно какой-то файл через год, ни в какую историю коммитов я не полезу, если не увижу комментарий прямо в коде. А если уже есть комментарий в коде, то непонятно, зачем нужно что-то особенное писать в коммите.
S>Вот, как-то увидел историю коммитов одного проекта — и мне стало стыдно. Эту историю можно было читать как книгу — как летопись. Одна строчка за другой.
Давай вспомним, что говорят по поводу комментариев в языках программирования. А название коммитов это тоже комментарии, которые создают люди. Причём создают они их именно для кода, который явно отслеживается на вкладке Patch программы gitk или запросом к git вручную. В других системах контроля версий примерно всё тоже самое.
1. Комментарии врут.
Написанное в них может запросто не соответствовать коду. Люди ошибаются и могут написать, что угодно. Это может быть как один человек даже если и думающий ошибочно, то по крайне мере везде совершающий одни и те же ошибки. Так и группа людей, каждый из которых думает иначе. Потому только код патча это критерий истины, а не комментарий описывающий коммит.
2. Комментарии устаревают.
В будущем может произойти переосмысление и надо будет изменить комментарии к коммитам, но как. Не проще ли тогда использовать те же теги как в Git. Можно обозвать всё, что угодно, но именно важное с возможностью изменить своё описание в будущем.
3. Комментарии тратят время.
Каждый раз нужно анализировать, что делал. А зачем, что это даёт кроме траты времени и мозговых усилий. Тем более уровни детализации разных коммитов всё равно не согласованы.
4. Комментарии не дают сохранить работу.
Можно изменить код где угодно во многих несвязанных местах. И как потом это называть в комментариях коммита. Может быть слишком мало изменений, а может быть слишком много. И тогда человек предпочитает не сохранять работу в репозитории, что может привести к фатальным последствиям.
5. Комментарии не помогают навигации.
Опять же речь о том, чтобы ориентироваться на время создания или попробовать дать осмысленный комментарий. Осмысленный комментарий как раз и не поможет найти проблему, потому что вместо того, чтобы примерно прикинуть когда что-то было сделано, надо будет читать все комментарии и ориентироваться на выдумки их авторов.
Ничто не помогает так, как уместный комментарий. Ничто не загромождает модуль так, как бессодержательные и безапелляционные комментарии. Ничто не приносит столько вреда, как старый, утративший актуальность комментарий, распространяющий ложь и дезинформацию.
Комментарии — не список Шиндлера. Не стоит относиться к ним как к «абсолютному добру». На самом деле комментарии в лучшем случае являются неизбежным злом.
...
Грамотное применение комментариев должно компенсировать нашу неудачу в выражении своих мыслей в коде. Обратите внимание на слово «неудачу». Я абсолютно серьезно. Комментарий — всегда признак неудачи.
...
Почему я так настроен против комментариев? Потому что они лгут. Не всегда и не преднамеренно, но это происходит слишком часто. Чем древнее комментарий, чем дальше он расположен от описываемого им кода, тем больше вероятность того, что он просто неверен. Причина проста: программисты не могут нормально сопровождать комментарии.
Программный код изменяется и эволюционирует. Его фрагменты перемещаются из одного места в другое, раздваиваются, размножаются и сливаются. К сожалению, комментарии не всегда сопровождают их — и не всегда могут сопровождать их. Слишком часто комментарии отделяются от описываемого ими кода и превращаются в пометки непонятной принадлежности, с постоянно снижающейся точностью.
...
Иногда с самыми лучшими намерениями программист делает в комментариях заявления, неточные и не соответствующие истине.
...
Также в программах нередко встречаются комментарии, не содержащие ничего, кроме «шума». Они лишь утверждают очевидное, не предоставляя никакой новой информации.
S>Коммиты делались только когда добавлено что-то значительное.
Выше я уже писал про то, что что-то значительное можно обозначить тегами в Git или чем-то подобным в других системах управлениям версиями. А незначительное не требует тщательного обдумывания. Удобство от неудобства порой отличает какая-нибудь мелочь, которая задалбывает и не даёт пользоваться программой.
Мультирепозитории и монорепозитории
S>Видимо в какой-то момент количество коммитов стало одной из метрик живости проекта и стало модно делать коммит на каждый чих.
Здесь я бы выделил такой вид репозиториев как монорепозитории.
В системе контроля версий монорепозиторий («mono» от греческого μόνος, мо́нос, 'единственный, одинокий' и репозиторий) является стратегией разработки программного обеспечения, когда код множества подпроектов хранится в одном и том же репозитории.
В них те же комментарии описывающие что-то без указания проекта вряд ли имеют смысл. А прочитать потом мешанину из кучи комментариев к разным проектам тоже будет очень не просто. И чем тогда является монорепозиторий. Может быть неким беспрерывным бекапом с тегами обозначающими только самые важные этапы.
Если же взять мультирепозитории, то может быть и проще заниматься каждый своим проектом в отдельности, но по мере роста компонентов очень много сил тратится на создание коммитов и комментариев к ним на каждый входящий репозиторий.
Непрерывная интеграция
S>С другой стороны, если еще не доделал, но хочешь на всякий случай забекапить работу — то тоже разумно сделать коммит.
Но какой бы тип репозиторий не выбрали основной минус это трата людского времени на коммиты. Люди существа ленивые, особенно те кто ещё не втянулся в работу по заданным правилам.
Непрерывная интеграция (CI, англ. Continuous Integration) — практика разработки программного обеспечения, которая заключается в постоянном слиянии рабочих копий в общую основную ветвь разработки (до нескольких раз в день) и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем.
В этом плане алгоритм работы с репозиторями будет основан на идее "Сделал, сохранись." и не важно, что это нужно делать по несколько раз в день. Если программист закончил работу, то любое даже самое незначительное изменение требует сохранения.
Причём мой репозиторий является монорепозиторием, в котором хранится сразу всё. Не только страницы, но и изображения, вложения документов, исходный код программ.
Чисто для примера. D:\git\zim\Программирование\Библиотеки\Q\Библиотека_-_Qt5\Примеры\2\2dpainting\Исходный_код . Подробнее можно посмотреть в Начальный уровень осмысления кода
Здравствуйте, Sharowarsheg, Вы писали:
S>Кстати, это не обязательно хорошо. Я в таких случаях пишу по комментарию в каждом месте в каждом файле, где это всё сдеално.
1. Нарушение DRY.
2. Вы во всех комментарих будут перекрестные ссылки? Что-то типа "See also foo.cpp:158, bar.h:357, asdf.cpp:843"? Или будете строку из комментария искать, чтобы найти все релевантные изменения?
S>Если я соберуь менять отдельно какой-то файл через год, ни в какую историю коммитов я не полезу, если не увижу комментарий прямо в коде.
Когда есть нормальная история — коммит это первое на что смотрят, чтобы понять кто, когда и зачем сделал изменения и что при этом было затронуто. Даже IDE его по умолчанию начинают показывать (instant git blame).
Здравствуйте, Baiker, Вы писали:
B>Видимо, придётся работать по-старинке: коммитить только полностью завершённую фичу, а по вечерам ежедневно делать отдельный zip и сохранять где-то в облаке — так наиболее оптимально.
Да, что уж там: электронное письмо самаму себе отправлять с исходниками
Или модно-молодежно: час с самим собой в телеграме
B>По идее, коммитить надо чуть ли не каждый чих, потому что если ты изменил DTO, к примеру, а на следующий день понял, что ошибся, ты должен спокойно восстановить этот файл. Но факт тот, что мне проще тупо залезть в zip и достать файл, чем лазить по истории, искать нужный коммит, а потом ещё аккуратно откатываться, боясь, что всё к хренам потеряется (тем более, что помимо изменения DTO, ты мог опосля ещё много чего накоммитить). Другими словами, VCS хоть и пришла на помощь, "ручное версионирование" никуда не делось, у нас по прежнему нет УДОБНОГО способа управлять сорсами.
Коллеги, ужаснитесь!
V>Написанное в них может запросто не соответствовать коду. Люди ошибаются и могут написать, что угодно. Это может быть как один человек даже если и думающий ошибочно, то по крайне мере везде совершающий одни и те же ошибки. Так и группа людей, каждый из которых думает иначе. Потому только код патча это критерий истины, а не комментарий описывающий коммит.
Как ты определишь, это комментарий не соответствует коду или код не соответствует комментарию?
Если ничего, сложнее перекладывания байтов из СУБД в json, делать не приходится, то комментарии действительно избыточны.
Попробуй разобраться в этом коде без комментариев и найти в нём ошибку:
function line(int x0, int x1, int y0, int y1)
int deltax := abs(x1 - x0)
int deltay := abs(y1 - y0)
int error := 0
int deltaerr := (deltay + 1)
int y := y0
int diry := y1 - y0
if diry > 0
diry := 1
if diry < 0
diry := -1
for x from x0 to x1
plot(x,y)
error := error + deltaerr
if error >= (deltax + 1)
y := y + diry
error := error - (deltax + 1)
Не зная, что это Брезенхем, ты хрен разберёшься. И даже говорящие имена переменных тут не помогут.
Вот всё, что нужно знать о противниках комментариев в коде.
_____________________
С уважением,
Stanislav V. Zudin
SVZ>Если ничего, сложнее перекладывания байтов из СУБД в json, делать не приходится, то комментарии действительно избыточны. SVZ>Попробуй разобраться в этом коде без комментариев и найти в нём ошибку: SVZ>Не зная, что это Брезенхем, ты хрен разберёшься. И даже говорящие имена переменных тут не помогут. SVZ>Вот всё, что нужно знать о противниках комментариев в коде.
Проблема отсутствия документации известна давно. Именно в документации может быть описано почему было принято то или иное решение, и что хотели получить от текущего алгоритма.
Вот смотри, какие у тебя есть варианты узнать почему было сделано так или иначе.
1. Помнить без каких-либо записей (мозг).
2. Записать простые комментарии в коде (// и т.д.).
3. Записать комментарии в виде самодокументируемого кода прямо в коде (doxygen и т.д.).
4. Записать комментарии отдельно от кода, в некой документации (папка с документами, личная база знаний, самодокументируемый код в отдельных от кода файлах и т.д.).
Эти циферки по сути говорят об уровне развития организации работ. Записывая посторонние мысли в код, ты условно находишься на втором уровне организации. Да, иногда это лучше, чем сказать, а я и так всё помню. Но ты заставляешь людей читать твои каракули в коде. А они могут этого как хотеть, так и не хотеть.
В больших проектах слияние кода и документации несёт в себе ещё один минус, а именно сложность перевода документации. По факту исходный код должен быть один, а вот документацию можно переводить на разные разговорные языки.
Лично для меня комментарии уместнее писать в документации. Идея в том, чтобы сделать разделение.
Название проекта
Архитектура
Знания
Интерфейсы
Использование
Испытания
Исходный код
Планирование
Разработка
Сборка
Сопровождение
Требования
Я ещё размышляю над тем, как это организовать у себя, но я не игнорирую эту проблему. Просто я тебе объясняю как она выглядит с моей точки зрения.
Сохранение в репозитории
Нынешняя же тема относится к культуре записи изменений в репозиторий. Давай представим, что я заменю кнопку "Сохранить", которая есть во множестве редакторов, или даже автосохранение, на несколько кнопок, а то и консольных команд.
Чтобы сохранить документ тебе придётся каждый раз.
1. Его получать (git pull origin master), чтобы произвести правильное слияние перед отправкой.
2. Выбрать, что сохранять, всё (git add --all), или какую-то часть.
3. Выдумывать название коммита (git commit -m "").
4. И наконец само сохранение (git push origin master).
Люди ведь не против сохраняться, но это уже форменное издевательство. И тогда мы начинаем говорить о культуре коммитов, вот этих названий. Лично для себя я решил пренебречь этими шагами и просто сохраняться. Синхронизация личной базы знаний по программированию в Zim.
В любом случае тема интересная и в ней есть над чем поразмыслить, может быть что-то переосмыслить.
Здравствуйте, Skorodum, Вы писали:
S>>Кстати, это не обязательно хорошо. Я в таких случаях пишу по комментарию в каждом месте в каждом файле, где это всё сдеално. S>1. Нарушение DRY.
DRY для меня, а не я для DRY. К тому же таких случаев не так много.
S>2. Вы во всех комментарих будут перекрестные ссылки? Что-то типа "See also foo.cpp:158, bar.h:357, asdf.cpp:843"? Или будете строку из комментария искать, чтобы найти все релевантные изменения?
Ссылки, только не такие, а без номеров строк — "See __My_Cool_Class._111 and _My_More_Cool_Class.__111OneOneOne".
S>>Если я соберуь менять отдельно какой-то файл через год, ни в какую историю коммитов я не полезу, если не увижу комментарий прямо в коде. S>Когда есть нормальная история — коммит это первое на что смотрят, чтобы понять кто, когда и зачем сделал изменения и что при этом было затронуто. Даже IDE его по умолчанию начинают показывать (instant git blame).
Я один работаю. Изменял его я. И обычно вопрос не в том, что что-то не работает, а в том, что нужно или добавить что-то или оптимизировать.
SVZ>>Если ничего, сложнее перекладывания байтов из СУБД в json, делать не приходится, то комментарии действительно избыточны. SVZ>>Попробуй разобраться в этом коде без комментариев и найти в нём ошибку: SVZ>>Не зная, что это Брезенхем, ты хрен разберёшься. И даже говорящие имена переменных тут не помогут. SVZ>>Вот всё, что нужно знать о противниках комментариев в коде.
V>Проблема отсутствия документации известна давно. Именно в документации может быть описано почему было принято то или иное решение, и что хотели получить от текущего алгоритма.
Это не проблема документации Это особенность оформления кода алгоритмов.
В документации пишется обоснование, допустим, почему для поиска пути выбрали алгоритм "А*". Описываются требования к целевой функции.
Рисуются диаграммы, формулы.
А дальше начинаются суровые трудовыебудни.
Как сопоставить написанное с кодом?
Как проверить, что код делает именно то, что ожидается?
Комментарии в коде (если пишутся раньше, чем код) как раз и определяют правильность работы алгоритма.
Если в коде выполняется не то, что написано в комментарии, значит в коде ошибка.
V>Вот смотри, какие у тебя есть варианты узнать почему было сделано так или иначе. V>1. Помнить без каких-либо записей (мозг). V>2. Записать простые комментарии в коде (// и т.д.). V>3. Записать комментарии в виде самодокументируемого кода прямо в коде (doxygen и т.д.). V>4. Записать комментарии отдельно от кода, в некой документации (папка с документами, личная база знаний, самодокументируемый код в отдельных от кода файлах и т.д.).
Комментарии отдельно от кода никому не нужны.
Доскиген нужен для оформления документации на АПИ. Не представляю, где ещё его можно применить.
_____________________
С уважением,
Stanislav V. Zudin
Когда что-то значительное и/или перед обедом и в конце дня. То есть, скорее как бекап. В публичный репозиторий для публичного проекта не вижу смысла часто комитить, оно даже вредно может быть. Только по достижении какой-то функциональности.
Здравствуйте, Sharowarsheg, Вы писали:
S>DRY для меня, а не я для DRY.
Этот аргумент был бы уместен, если бы у комментариев в гите были бы какие-то недостатки.
S>Ссылки, только не такие, а без номеров строк — "See __My_Cool_Class._111 and _My_More_Cool_Class.__111OneOneOne".
1. Нарушение DRY опять: при переименовании класса придется ручками обновлять комментарий.
2. Как ссылка это не работает. (Из коммита гита можно сразу перейти в нужное место.)
S>Я один работаю. Изменял его я. И обычно вопрос не в том, что что-то не работает, а в том, что нужно или добавить что-то или оптимизировать.
Понятно, что лично для тебя это работает, и переучиваться тебе поздно/лень/не даст пользы.
Но эта задача объективно решается гитом гораздо лучше, и это стандарт в отрасли.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Попробуй разобраться в этом коде без комментариев и найти в нём ошибку: SVZ>
SVZ> function line(int x0, int x1, int y0, int y1)
SVZ> int deltax := abs(x1 - x0)
SVZ> ....
SVZ>
SVZ>Не зная, что это Брезенхем, ты хрен разберёшься. И даже говорящие имена переменных тут не помогут.
В нормально коде "Брезенхем" будет отражен в названии файла и/или функции и/или пространства имен и коммите.
SVZ>Вот всё, что нужно знать о противниках комментариев в коде.
Комментарии подобного рода — это кривой костыль.
