Comments 62
Простите, но вы предлагаете неверный выход из известной ситуации.
"Для наглядности я создала небольшой проект и сделала в нём пять коммитов с соответствующими названиями."
Вот тут главная ошибка. НИКТО не должен коммитить в мастер. В него должны делать пулл реквесты.
Мне даже сложно найти сейчас проекты, где используется чистый гит, а не гит с любой code-review система, настолько Code-review сейчас распространен.
Все эти bitbucket, github, gitlab и так далее - все предлагают пользоваться Pull Request, который перед merge в мастер как раз и будет грамотно оформлен, просмотрен, сжат (merge squeeze), проверен на конфликты и добавлен в основную ветку единым коммитом с правильным коммит мессадж.
Почитайте также git workflow, и посмотрите несколько вариантов. Это и есть правильный путь.
А внутри своей feature ветки, разработчик вполне имеет право делать хоть десять коммитов с непонятным сообщением. Он человек, он может допускать опечатки, он должен иметь возможность проверить какие-то мелочи, если проект создан так, что билд и автотесты нельзя выполнить на своей локальной машине, а где-то в CI.
Начну с того, что методологии Git Workflow относятся к организации рабочего процесса внутри гита, зачастую даже к организации ветвления, но никак не к наименованию и количеству коммитов. Это во-первых
Во-вторых, ревью хоть и требует качественной проверки, но человеческий фактор никто не отменял, тут как ни крути. Тем более автор отмечает
Внимание! Перед пушем с флагом обязательно проверьте ветку, в которую вы пушите. Ни в коем случае это не должна быть master!
Да и в целом в статье не говорилось ни слова о том, что коммиты нужно сразу писать в мастер. Однако, как-то же коммиты попадают в мастер :)
В-третьих, не стоит забывать, что у многих разработчиков существуют свои небольшие pet-проекты. И уж не знаю, как вам, но мне было много и много лень создавать самому себе пулл-реквесты на первых этапах развития проекта. Так что чем данная стадия развития проекта не идеальна для того, чтобы вести (или, если ты начинающий разработчик, приучаться вести) чистую историю Git и пользоваться теми способами, которые описал автор. Тем более, что упомянутый вами Git Workflow вообще вряд ли применим для проекта, который разрабатывается одним человеком для локального использования. Пусть это будет и канонично, однако абсолютно не практично.
Ну и наконец, скажу, что далеко не во всех компаниях и проектах принято делать сквош коммитов перед мерджем ветки. Причин на это может быть множество, хотя бы возможность отката не всей новой функциональности, а какой-то ее части, содержащей баг или что иное. В таком случае при правильной организации истории и коммитов (о чем в первую очередь данная статья), данный подход может иметь весьма и весьма полезное применение в некоторых ситуациях
Привет!
Спасибо большое за комментарий!
Да, вы как раз и написали обо всём, что я хотела сказать :)
И отличное замечание о небольших проектах. Действительно, так как методологий git workflow бывает много, одна из них как раз и предполагает пуш сразу в мастер. Поэтому это всё скорее не про то, как правильно и неправильно, а про то, от чего будет больше пользы в определенном проекте и с чем самим разработчикам удобнее работать.
к организации рабочего процесса внутри гита, зачастую даже к организации ветвления
Ну я бы сказал не гита, а внутри проекта. Но именно это и есть та проблема, которую описывает топик стартер.
В любом случае, как только появляется pull request, это уже показывает, что есть code review система, а значит над гитом уже есть именно то, в чем можно строить и организовывать свою работу.
Тем более что git workflow это одновременно и сама идея установить некий flow и самоназвание одних из workflow. Можно же поискать различные варианты, или посмотреть на них и придумать свой собственный.
Привет!
Спасибо большое за комментарий!
Да, полностью с вами согласна, при описанном вами подходе, когда feature branch мерджится в master со сквошем всех коммитов, данная статья будет скорее неактуальна.
Однако git workflows бывают ведь разные и каждая команда вольна выбирать свой. Это дело вкусовщины и устоев команды. Например, у нас тот самый GitFlow Git workflow, о котором вы говорите, единственное отличие - мы не сквошим коммиты при мердже в master. Поэтому нам так важно, чтобы история коммитов, которая потом окажется в мастере, была чистой.
Я так же поддерживаю запрет коммитов напрямую в мастер (в обсуждаемых воркфлоу), поэтому сделала ремарку об этом в блоке про запрет пушей сразу в мастер. Там же и расписала, что весь код, оказывающейся в мастере, должен пройти ревью и тестирование - это как раз про pull (merge) реквесты.
А разработчик тоже, конечно, имеет права работать со своей веткой как ему нравится и удобно. Это отлично работает, если потом все его коммиты все равно сожмуться в один, как вы и описали. Но если в команде не принято мерджить в мастер со сквошем коммитов, то тут уже, после всех экспериментов разработчика, стоит привести историю коммитов ветки в аккуратный вид. Именно о том, как это проще сделать я и написала.
Это хорошее замечание, я добавлю заметку о том, для какого git workflow подойдет данная статья, сейчас это действительно не очень очевидно.
Если вдруг я что-то упустила или не верно поняла - пишите, я буду только рада улучшить материал :)
Большое спасибо!
Ну OSS pet-проекты можно поначалу и в мастер настреливать, по 150 коммитов за 2 недели)
Вот тут главная ошибка. НИКТО не должен коммитить в мастер. В него должны делать пулл реквесты.
Я работаю в Gerrit и коммичу в мастер. Каждый коммит проходит ревью конечно. Почему нельзя использовать такой процесс остаётся загадкой. Ему даже модное имя дали — trunk based development
То есть у вас master это dev, а релизы в отдельной ветке живут? В таком случае у вас релизная ветка должна быть защищённой и никто в неё не должен коммитить напрямую.
Другое исключение это когда у у репозитория три с половиной разраба которые дружно конопатят какой-нибудь некритичный функционал.
Если вы делает ревью, то вы не коммитете в мастер. `git push origin HEAD:refs/for/master` создаёт на каждый ваш пуш новую ветку.
Откройте любое ревью здесь и нажмите DOWNLOAD, вы увидите что там под капотом ветки. https://gerrithub.io/c/redhat-openstack/infrared/
При ревью вы вообще не мерджите, вы ставите флаг что можно мерджить и Геррит делате это сам, когда все остальные условия выполнены. (родительские ветки вмерджены, топики готовы).
Естественно я имел ввиду не все варианты использования, а конкретную ситуацию у топикстартера.
Естественно каждый может сделать свой флоу, и не пользоваться code review системой вообще.
Но если ревью делается, то это удобно делать в pull request-ах, а не в коммитах.
Gerrit, как одна из самых первых систем код ревью, достаточно гибкий и функциональный, чтобы на нем можно было настроить любой флоу. Но насколько я помню, он тоже создает pull реквесты автоматом на каждый ваш пуш в мастер, и код ревью делает внутри этого пулл реквеста, используя временные ветки
А если взят большинство современных code review систем - они из коробки предлагают простые и удобные флоу именно на базе pull request
Комментатор выше правильно написал. Работа с репозиторием осуществляется через гитлаб/гитхаб, где есть мерж/пулл-реквесты. При таком раскладе что там в коммитах — не принципиально. Ну, можно сквош еще включить для пущей красоты
Ага, потом открываешь git blame в IDE напротив какой-то строчки, и там везде сообщения вроде "fix bug", и не понятно вообще к какой задаче оно относилось и с какой целью было сделано.
Помимо --force-with-lease есть ещё --force-if-includes - недостаточно хорошо задокументированная и освещённая но очень нужная фича
гитхуки могут локально давать по рукам при попытке коммитать напрямую в мастер или писать безинформативное fix в коммите
Спасибо за полезную статью.
НИКТО не должен коммитить в мастер.
Поддерживаю - в настройках проекта нужно запрещать коммиты в master.
За push --force в origin предлагаю расстреливать на месте :) Пушим в репозиторий только когда все локально причесали и на 200% уверены.
А внутри своей feature ветки, разработчик вполне имеет право делать хоть десять коммитов с непонятным сообщением
Только до тех пор, пока это его локальная ветка. Репозиторий - не винегрет, а код единого проекта. Дисциплина должна быть как в стиле кода, так и в истории изменений.
Код пишут, чтобы читать. Историю Git пишут, чтобы читать. Через год в вашу фичу полезет другой и проклянет вашу лень.
Читайте ссылки по запросу git commit message best practices и чистой вам Git-истории :)
8 правил, которые пригодятся при описании Git-коммитов
Отличная идея - добавлять номер задачи в начало сообщения: облегчает чтение, когда веток много. prepare-commit-msg hook автоматически достанет номер задачи из имени ветки и добавит к сообщению, а commit-msg hook умеет бить по рукам за плохие сообщения.
push -f - это прямой результат действительно совместной работы.
Если вы наделали изменений, и ваш коллега параллельно наделал изменений, которые могут повлиять на ваши, - то у вас есть два путя:
сделать спагетти из неизменяемой истории: мержкоммит свежего мастера в вашу ветку, героическую борьбу с массовыми конфликтами и обратно мержкоммит ваших трудов в мастер, и пусть затем люди читают всё это и думают - вот здесь вы исправляли баг по существу, или же исправляли конфликты, или исправляли последствия кривых исправлений конфликтов?
сделать ребейз своей ветки на свежий мастер, исправить конфликты (в каждом вашем коммите лично вам будет очевидно, какие правки как накатывать), push -f ветки в ориджин, и уже предлагать пулреквест с мержкоммитом.
В итоге, мержкоммиты есть только в мастере и черипики этих мержкоммитов из мастера в релиз-кандидаты, и больше нигде и никак.
Мы с коллегой работали так: завели ветку dev - в нее мержили те feature, что запланированы на следующий релиз. В случае конфликтов мы садились у одного монитора и разрешали конфликты локальным merge, а после коммитили.
Проектировщики самолетов прячут рычаг катапультирования в кабине пилота так, чтобы пилот случайно его не зацепил. Флаг --force - тот же рычаг катапультирования - дергать без нужды не стоит :)
Команды на удаление или перезапись - всегда риск. Удаленный репозиторий у вас один, берегите его.
Удалённый репозиторий, как правило, трудно сломать, особенно, если правильно настроены права доступа. Максимум можно сломать свою ветку, в которую вы коммитите. Не понимаю такого страха перед форсом, если вы знаете что делаете, и, особенно, если удалённый репозиторий правильно настроен, то никаких проблем с его использованием быть не должно. Поправьте меня, если я ошибаюсь.
П.С. И «форс пуш в ориджин» выше — имели в виду в мастер? Что плохого чтобы пушить всё что угодно в свою ветку? А если своих веток нет (нельзя создать), значит, и пушнуть не должно получиться. Значит, форкнуть и создать PR со своего репозитория. Спасибо что хоть туда разрешили форспушить:)
За push --force в origin предлагаю расстреливать на месте :)
Это вопрос выбора git merge vs git rebase. Вы только что предложили расстрелять добрую половину разработчиков, которые выбрали второй подход и рибейзнули себе в фичабранч то, что попало в мастер после создания ветки.
Пушим в репозиторий только когда все локально причесали и на 200% уверены.
У вас винты на локальной машине никогда не умирали?
У вас с веткой всегда 1 разработчик только работает?
Как оттестировать промежуточные результаты, если пушить нельзя, а тесты запускаются на сервере?
Только до тех пор, пока это его локальная ветка. Репозиторий - не винегрет, а код единого проекта. Дисциплина должна быть как в стиле кода, так и в истории изменений.
После мержа фичи в мастер ветка удаляется, зачем она нужна дальше?
если правильно настроены права доступа ... если вы знаете что делаете ... если удалённый репозиторий правильно настроен
Увы, закон Мерфи все еще работает :) Хорошо не всё и не всегда.
У вас винты на локальной машине никогда не умирали?
Моим винтам умирать строго воспрещается :) А если серьезно, то у нас пушили по несколько раз в день, но предельно осторожно.
У вас с веткой всегда 1 разработчик только работает?
Да, одна ветка - одна фича.
Как оттестировать промежуточные результаты, если пушить нельзя, а тесты запускаются на сервере?
Мы тесты локально запускали перед коммитом.
Вашу мысль я понял, просто у нас разной величины проекты, команды и раздача полномочий к репозиторию. Мы работали без rebase, мержили локально.
Да, одна ветка - одна фича.
Фича одна, а разработчиков несколько. Например, фронт и бэк пилят разные люди и одно без другого вливать нельзя.
Мы работали без rebase
Ну, вы просто по другой схеме работали. У нее есть свои преимущества и недостатки, как и у рибейза.
Мы тесты локально запускали перед коммитом
Это работает только если тесты идут быстро. Если они идут десятки минут/часы, локально запускать их довольно накладно.
Кто пользовался меркуриалом – знает, зачем :-). Очень не хватает у каждого коммита пометки, в рамках какой ветки он делался.
Постоянно делаю push —force в свою ветку, потому что стараюсь придерживаться правила минимального merge-request’а - в этом случае у меня почти всегда в mr’е 1 коммит, но случаются мелкие фиксы которые как раз летят с —amend —no-edit и требуют push —force
Я бы ещё упомянул изобилие бесполезных мёрдж-коммитов, когда мёрджат ветку с одним коммитом в master вместо того, чтобы просто черри-пикнуть один коммит. По-моему такое оправдано разве что при наличии какой-то полезной информации в названии ветки или комментарии у самого мёрдж-коммита, иначе просто засоряет историю (хотя можно конечно исключить мёрдж-коммиты при просмотре лога через какой-то флаг).
Насчёт patch - мне кажется, что проще создать отдельную локальную ветку, чем мучаться с патч-файлами, т. к. их можно случайно закоммитить, если оставить в репозитории.
На мерж реквест в CI настроен прогон тестов (юнит/юай/интеграционные/снапшот). То есть, чтобы в мастер (или develop) закоммитить мелкую праву в стринге (например поменяли "hello world" на "Hello world") то должен пройти каскад всех тестов на созданном МР, в данном случае если поменялась просто строка, то скорее всего упадут снапшот тесты если строка отображалась юзеру и тесты тоже нужно будет поправить))
То есть оно делает мерж с мастером, гоняет тесты, и если что-то пошло не так ревертит этот коммит и пушит эти два коммита в мастер или как? Звучит как минимум не очень адекватно.
Там, как я понимаю, проще (конкретно как это сделано я не знаю). Локально на CI мержится в мастер и запускаются задачи, в моем случае несколько наборов различных тестов. Если все (обязательно) прошли успешно, то на CI на мерж реквесте загорается кнопка "замерить в мастер" и только после нажатия на нее произойдет реальный мерж. Но у нас на кнопку "Замержить в мастер" еще висит условие - чтобы она стала активной определенные ревьюверы должны это подтвердить, иначе кнопка будет выключена. Итого, чтобы мерж реквест прошел в мастер нужно чтобы обязательно прошли все тесты и это было подтверждено как минимум 1-2 ревьюверами.
Ну то есть от rebase версии буквально ничем не отличается кроме наличия мерж коммита в мастере по итогу.
Да, всё верно)
Но я больше отвечал на
изобилие бесполезных мёрдж-коммитов, когда мёрджат ветку с одним коммитом в master вместо того, чтобы просто черри-пикнуть один коммит.
Мы конечно делаем черри-пики, но это скорее исключение. Много раз уже были ситуации когда, казалось бы, мелкое изменение влекло за собой какие-то баги. Теперь всё без исключения через МР с тестами и код ревью, а иногда и ручными тестами.
Вы, наверное, ищете как мержить с fast-forward, чтобы не плодить чери-пики. Но тогда придётся регулярно перед пушем делать git fetch и git rebase origin/master
Не, я скорее сетую на тех разработчиков, которые не могут осилить такую сложную комбинацию команд ))
Жизнь бывает чуть сложнее.
Нужно пушнуть код. Получить аппрув. Должны пройти тесты и прочие проверки на CI.
Если в процессе этого, кто-то пушнул свои изменения, всё по новой. Не для всех проектов такое подойдёт.
А для проектов которым норм на GitHub есть запрет для мерджей если выша ветка на обновлена до мастера.
git pull --rebase?
Утро начинается не с кофе, а с ребейза текущей ветки на мастер.
У меня глаз начинает дёргаться, когда я у коллег вижу мерж мастера в фичеветку. Такие МРы я мержу без зазрения совести со сквошем, даже если разработчик пытался там что-то разбить по коммитам.
Патчи хороши, если какой-то файл надо закоммитить по кусочкам.
Например, внёс в файл пять правок, но логично было бы сделать их тремя коммитами (сгруппировать с правками других файлов, например).
Вот только руками редактировать патчфайл - это мрачный труд.
Но уважающие себя графические клиенты (и/или компоненты IDE) умеют формировать патч построчно.
Конечно, если правки нахлестнулись, то придётся страдать и как-то выкручиваться из ситуации.
(Либо плюнуть на красивую историю и жахнуть всё одним коммитом).
git add -p тоже может стейджить построчно
Как минимум GitExtensions позволяет ложить в stash изменения по частям без боли и путаницы
gitui или lazygit если вы из терминала выходить не хотите. Ну или например git-cola, если вам гуи нравятся больше. Выбираем файл с изменениями и жмакаем s на интересующих вас строчках - вуаля, она ушла на этап стеджинга.
Странные дела творятся в комментариях. Хорошие, дельные комментарии минусуют, при этом демонстрируя совершенное невежество в ответах. Складывается ощущение, что в очередной раз собрались те, кто не всегда отличает гит от гитхаба, и начали учить.
Ещё надо было про --fixup коммиты и --autosquash ребейз рассказать.
$ git commit --fixup e1c231c568
$ git log --oneline 4
276371ccba fixup! Add blabla to foobar
aa7371c3b1 Do some bar staff
da73c1b8b8 Do some qux staff
e1c231c568 Add blabla to foobar
$ git rebase --interactive --autosquash HEAD~4
pick e1c231c568 Add blabla to foobar
fixup 276371ccba fixup! Add blabla to foobar
pick da73c1b8b8 Do some qux staff
pick aa7371c3b1 Do some bar staffСпасибо, что напомнили, я про это и забыл.
Сейчас работаю с Герритом, а там приходится менять старые коммиты.
Привет!
Да, спасибо большое, что упомянул!
Это тоже очень полезная история. Я так же про это думала-думала, но в итоге оставила. Решила, что тут, в принципе, допустимо сказать, что это относится к `rebase --interactive`. Но я теперь подумаю над упоминанием и такого кейса.
При работе в GitHub можно запретить пушить в мастер, а мердже разрешить через Pull Request только чере Squash & Merge. То есть не важно, что там у разработчика, в мастере будет красивенько.
Там же сможно сдалать обязательную проверку на наличие тикета в сообщенит. Я обычно добавляю проверку сообщений (https://github.com/jorisroovers/gitlint
) в хуки от https://pre-commit.com/.
Не люблю правила которые должна соблюдать команда, требуется много усилий на то, чтобы все следовали им. По возможности всё должно быть автоматизированно.
Например делать `git push --force` в ветку, где работает вся команда плохо, но остановило ли меня это? Нет, я это сделал не умышленно.
Повторил ли кто-то мой подвиг? Нет, включили автоматическую защиту.
Привет!
При работе в GitHub можно запретить пушить в мастер, а мердже разрешить через Pull Request только чере Squash & Merge. То есть не важно, что там у разработчика, в мастере будет красивенько.
Да, это правда. Тогда вся статья становится неактуальна, как заметил первый комментатор. Однако как раз в начале подчеркнула, что тут рассмаривается именно кейс, когда коммиты не сквошатся при мердже в мастер. Например, мы с командой обоюдно пришли к этому, нам так удобнее. Поэтому нам эти правила и актуальны :)
Там же сможно сдалать обязательную проверку на наличие тикета в сообщенит. Я обычно добавляю проверку сообщений (https://github.com/jorisroovers/gitlint
) в хуки от https://pre-commit.com/.
Да, хуки - это вообще отлично! С ними все куда проще и приятнее.
По возможности всё должно быть автоматизированно.
Что правда, то правда. Но все равно пока остаётся небольшая часть, которую пока могут контролировать только разработчики.
Например делать
git push --forceв ветку, где работает вся команда плохо
Это, конечно. Хотя опять-таки, смотря какой git workflow используется. Если это пет-проект одного разработчика и ему так удобнее - то, почему бы и нет. Главное, чтобы всем, кто с этим работает, было комфортно.
Но в любом случае, при нашем git flow мы как раз в мастер не пушим никогда. У нас так же все через Merge Requests, а форс пуши только в свою feature ветку, пока она не вмерджена в мастер.
Да, это правда. Тогда вся статья становится неактуальна, как заметил первый комментатор. Однако как раз в начале подчеркнула, что тут рассмаривается именно кейс, когда коммиты не сквошатся при мердже в мастер. Например, мы с командой обоюдно пришли к этому, нам так удобнее. Поэтому нам эти правила и актуальны :)
В этом есть и свои плюсы. Чем меньше надо знать и уметь чтобы эффективно работать тем лучше.
На прошлой работе у нас был моно-репозиторий на 100 человек. И большая часть были датасаентисты. Договориться чтобы работать правильно было слишком накладно.
Сейчас разные команды и Геррит. В нем из коробки одно ревью - один коммит. Но тоже есть пользователи которые кроме 5 команд ничего не знают.
В маленькой команде можно сделать процесс посложнее и обучить всех быть на тёмной стороне.
Но в любом случае, при нашем git flow мы как раз в мастер не пушим никогда. У нас так же все через Merge Requests, а форс пуши только в свою feature ветку, пока она не вмерджена в мастер.
У нас тоже такой процесс был. Просто защиту на ветку не поставили.
# например, начнём процесс rebase с четвёртого коммита от ведущего $ git rebase --interactive HEAD~4 # следующая команда аналогична предыдущей $ git rebase --interactive fb7ab419 # fb7ab419 — хеш первого коммита (commit 1)
git rebase -i masterБазовую ветку обычно проще запомнить, чем искать коммит. Перед использованием можно git rebase master сделать, чтобы убрать мердж коммиты и уменьшить число, того что нужно сквашить.
Хотя я обычно через git reset master, git add, git commit делаю. Если у вас с десяток коммитов это может быть быстрее чем s перед каждым ставить.
Резет еще полезен, когда хочется на ревью отпарвить только часть кода, а не всё что есть.
О, моя любимая тема) Всё ниже относится конечно же к закрытым проектам.
Вот бывает, смотришь ты историю коммитов проекта — и всё, казалось бы, хорошо и понятно, но вдруг натыкаешься на такое:
зачем туда смотреть? чтобы что?)
Особенно страшно видеть подобное в исполнении опытных разработчиков.
Может потому что "чистая история коммитов" никому на самом деле не нужна и ни на что не влияет?, и это просто какая-то религия.
в случае неполадок будет легче откатиться
используйте гит-тэги.
Если нужна история проекта - читайте релиз-ноутсы написанные по-человечески для людей от тех-райтеров, вместо чтения истории срезов состояний кодовой базы от уходящих-приходящих но-нейм разработчиков.
Новый разработчик в команде может глянуть на историю чисто ради оценки интенсивности разработки, ну и принципов именования коммитов. А так, вникай в предметную область, изучай кодовую базу, общайся(!) с коммандой, проходи онбординг, делай таски, оставляй после себя код лучше чем был.
Гит и коммиты - это как источник истины\база\хранилище\блокчейн если угодно, а коммиты - типа миграций что-ли. Но точно уж не для чтения глазами истории проекта или "коммуникаций"
Ах, удобно вырезать\вставить\черри-пикнуть какой-то красивый понятный атомарный коммит. Обычно это делается в рамках одного разработчика, в рамках одной фичи, в рамках небольшого промежутка времени, в общем в рамках одного понятного контекста. Никто не будет перемещать коммиты годичной давности.
Ещё миф - понятные атомарные коммиты годичной давности помогут что-то там разобраться в каком-то забагованном бизнес-процессе.. ага. Иди, и общайся (лучше ртом вживую), распутывай код, двигай проект вперёд. Есть шанс сделать лучше. В этом твоя ценность как прикладного разработчика. История коммитов - это то что уже было, прошло, надо забыть, оно никому не надо (можно даже подчистить их чтоб места освободить).
О, гит-коммиты можно привязывать к таск-треккеру. Типа удобно посмотреть начальную таску в одну строчку, которая три раза успела эволюционировать в процессе разработки. А если этот трекер поменяется. High cohesion или как-там правильно.
Всё ниже относится конечно же к закрытым проектам
Я бы сказал, что не надо делить по закрытости-открытости. Хотя некоторая корреляция наверно есть.
Есть два подхода к решению проблем в коде.
Первый копание в истории с использованием bisect, второй копаться в коде.
Первый работает только на нормальной истории. Второй универсален.
зачем туда смотреть? чтобы что?)
В история я заглядываю с вопросом почему это поменялось. И это может быть написано только в коммит сообщении. Из всех коммитов в ветку обычно один содержит полезную информацию, а остальные всякие фиксы и ответы на ревью. В общем может понадобиться походить по истории взад вперёд.
С чистой историей это всё сводится к одному коммиту, навигация быстрее.
О, гит-коммиты можно привязывать к таск-треккеру. Типа удобно посмотреть начальную таску в одну строчку, которая три раза успела эволюционировать в процессе разработки.
Именно так, чистая история ни как не гарантирует, что в коммит сообщении будет что-то полезное. И ни как не защищает от затащить 10 фич в один коммит. Без окружающей культуры разработки и автоматизации, это просто усложнение, которое не даёт никакой пользы.
Пишут сеньоры и архитекторы "грязную" историю и пусть себе пишут — Вы сами хорошую и чистую историю создаёте — у вас явно не горят сроки — хвала вам и слава. Я сам коммиты в коммерческом проекте обычно создаю по правилу "Коммит должен отражать что я делал в каждый конкретный момент рабочего дня". Следуя этому правилу вы сможете сказать, за что вам платят зарплату и чем вы занимались на прошлой неделе.
Пусть я написал фичу в своей локальной ветке и запушил в удаленный репозиторий.
Я точно знаю, что другие разработчики не работали с моей веткой, однако они могли сделать git fetch -all (тем самым загрузив себе историю всех веток, в том числе моей).
Безопасно ли будет сделать Interactive rebase моей ветки с последующий git push -f?
А как же правило "никогда не посылай человека туда, куда можно послать пулю"? В смысле, если что-то может быть сделано один раз за счёт развития инструмента, а не много раз руками при каждом очередном коммите – так и надо делать.
К примеру, все эти коммиты "fix" из вашего примера при просмотре мастера нафиг не нужны, и в истории было бы достаточно видеть один коммит вместо них (что приводит к желанию сквошить). Но при просмотре изменений может понадобиться именно конкретный коммит (что приводит к тому, что на момент создания надо в каждом написать, что именно "fix").
Моя боль при работе с git – что он не сохраняет принадлежность коммитов к веткам, как это делал mercurial. Влил ветку в мастер – всё, все коммиты из неё теперь часть мастера. Есть обходные пути добиться этого (например, запрет fast-forward merges и просмотр истории только по первому родителю), но как-то всё криво...
Мне приходиться работать в парадигме один коммит одно ревью (с Gerrit по другому никак). Вещь которая меня жутко бесит, это то: что нужно всегода знать, что ты сейчас должен сделать commit или commit --amend. Лишняя когнетиваня нагрузка когда ветка не на 10 минут и если падают прекоммит хуки, а падают они практически всегда, так как форматируют код.
При работе с гитхабом проще, просто всегда делаешь коммит.
@LittleRunaway сталкиваетесь ли вы и ваша команда с такой проблемой?
Clean Git History, или Тёмная сторона VCS