Comments 187
Вообще я битбакет и выбрал в свое время ради меркуриала, нафиг они без него нужны тогда если есть гитхаб.
нафиг они без него нужны тогда если есть гитхаб.
Неограниченное кол-во приватных репозиториев, интеграция Trello / Jira c доской. В конце-концов, есть люди, которые принципиально не хотят пользоваться продуктами Microsoft.
Неограниченное кол-во приватных репозиториев
На сколько знаю, на GitHub недавно тоже появились. На bitbucket мне ещё интерфейс как-то больше нравится, но сейчас, как активный адепт Mercurial, тоже думаю, а не съехать ли на GitHub?
Ещё rm, checkout, clone и branch. Говорю как тот самый человек, избалованный UI и теряющийся, когда его нет в нестандартной ситуации =)
git, клиент которого выполнен в худших традициях
А что с ним?
Набрал в консоли git ... и в бой.
Ещё и набор стандартных *nix-овых утилит всегда под рукой.
Основной причиной перехода с меркуриала на гит были именно тормоза. Нельзя тянуть гигабайтный проект со скоростью 100-150 кб/с.
У нас в Bitbucket+git включены branch permissions. В некоторые ветки нельзя сделать push.
Это конечно надстройка, а не функуионал из коробки, но мне кажется что и в SVN это что то сверху
Не знал что в git есть управление привилегиями
Это потому, что его там нет. Управление привилегиями есть у платформ, построенных поверх git: GitHub, GitLab, Bitbucket. А есть оно там потому, что разные корпоративные клиенты, которые платят деньги за коммерческие версии, очень любят настроить разных корпоративных заборов. Почему бы и не продать им это.
Хоть кто-то не мешает Git и GitHub в одну кучу.
все коммиты сохраняются в единственном файле-базе sqlite формата
Эта особенность в ней очень заинтересовала. Кстати, а не знаете, есть ли инструментарий конвертации репозиториев в этот формат? Я бы ряд своих перевёл.
Кстати, а не знаете, есть ли инструментарий конвертации репозиториев в этот формат?
fossil help importЯ использую только fossil. Это вообще единственное нормальное решение для самохостинга. Простота установки, единственный исполняемый файл, весь репозиторий в БД SQLite (ACID!) есть issue/bug tracker, а напоследок сделали и форум.
Усилия поддержки системы нулевые. Просто работает, не трогаешь годами. Производительность очень высокая.
Почему не взлетел, мне просто непонятно...
Плагины для IntelliJ IDEA есть?
Еще вопрос, он умеет работать только с текстом или небольшие бинарные файлы тоже умеет адекватно обслуживать?
"адекватно обслуживать" это как?
А ну да, конечно. А разве есть и такие, которые портят? Я постоянно включаю бинарники в репозиторий. Хотя это и плохая практика, потому что ухудшает компрессию, но никак не могу сдержаться. :)
Для «домашних» проектов — до сих пор отличный выбор.
Есть плагины под IDE.
git init (или hg init) в папке myproject сделать, и эту же всю папку потом и забэкапить (унести конкурентам) прям со всей историей — это так сложно что ли?)Я помню .cvs папочки были по всем подпапочкам проекта (впрочем как и .svn потом), а толку с них было ноль, так как история в них-то как раз и не хранилась
В них хранятся указания на репозиторий, конфликты мержинга, настройки игнорирования типов файлов и т.п.
Я имел в виду переносимость репозитория.
На одной машине — git push
На другой — git pull
Или что вы имели в виду под «переносимостью»?
С учетом того что сейчас у всех основных кампаний есть бесплатные приватные репозитории — нафига какой-то VPS покупать? Особенно для «домашних проектов».
я говорил про весь репозиторий проектов, который можно перенести простым копированием на другую машину.
Объяснять разницу между своим сервером и серверами «основных кампаний» не буду. На мой взгляд она вполне очевидна.
я говорил про весь репозиторий проектов, который можно перенести простым копированием на другую машину.
Во-первых гит тоже локально все изменения хранит в корне проекта в директории `.git` — точно так же берете и переносите.
Во-вторых никто так не делает, т.к. гит распределенный. Там ты просто форкаешь куда угодно какой удогно репозиторий.
Объяснять разницу между своим сервером и серверами «основных кампаний» не буду. На мой взгляд она вполне очевидна.
Конечно очевидна, и не в пользу собственного сервера.
За свой сервер надо платить и самому его поддерживать. И шансы вашего хостера закрыться примерно такие-же (а то и выше) как у кoмпаний предоставляющих место для репозиториев.
Плюс ко всему, на свой сервер можно просто поставить гит и даже никакой «гит-сервер» поднимать не надо, главное чтобы место на диске было.
Так что все равно нужен где то сервер.
С этой точки зрения, что «поднимать гит», что «поднимать cvs» — затраты одинаковые, но для небольших проектов (про что я упомянул в исходном своем топике) CVS прекрасно удовлетворяет всем требованиям к СКВ. Настроил в IDE и никакой разницы. Что не так то?
Плюс, лично у меня репозиторий включен в план бекапов и есть возможность управления пользователями на уровне обычных пользователей linux, что лично для меня очень удобно.
Локальное хранение кода, с точки зрения СКВ, это не самая разумная мысль
Ну да, это старый подход, где надо быть подключенным к инету чтобы с кодом работать. В гите так не обязательно.
Так что все равно нужен где то сервер.
Заходите на Гитхаб/Гитлаб/Битбакет, создаете приватный репозиторий, отправляете приглашения кому хотите. Ну явно же проще чем свой сервер покупать / настраивать и т.д. Вы просто никогда не пробовали.
Настроил в IDE и никакой разницы. Что не так то?
Гораздо меньше полезных функций чем в гите, производительность ниже, не распределенный репозиторий.
Плюс сейчас очень мало кто использует cvs, если пилите опенсорс проект — куда труднее будет найти контрибьютеров.
Ну явно же проще чем свой сервер покупать / настраивать и т.д.Гораздо проще, чем настроить новый смартфон после покупки. Я не понимаю, о какой сложности идет речь.
Вы с CVS работали? я вот и с CVS и с Git работаю. Я просто имею возможность сравнить, о чем выше и написал.
PS: производительность кстати не ниже, зачастую выше. У меня в CVS лежит 2..3 проекта числом около 300..400т строк кода каждый. Иногда при глобальном рефакторинге порядка 100..120 классов сразу коммитятся, не замечал трудностей. А вот с бесплатным гитом — как повезет. Не особо парит это, я просто ради истины упомянул.
Для cvs нужен свой сервер и подключение к интернету. Гиту не нужно ни то не другое.
Я не говорю что настроить сервер трудно, я говорю что не настраивать — проще.
Особенно для «домашних» проектов.
А если уж есть сервер — то гит будет работать точно так же с разделением на юзеры и прочее. Это ж просто директории проектов. Не говоря уже о том что гит поддерживается большим сообществом, имеет кучу фич, оффлайн работу, и отличную производительность.
Вы с CVS работали? я вот и с CVS и с Git работаю.
С cvs я не работал, но работал с svn лет 10 назад. Разницу себе представляю.
Я просто имею возможность сравнить, о чем выше и написал.
Вы можете написать хоть одно преимущество cvs перед git?
Вы можете написать хоть одно преимущество cvs перед git?
1. приватность на уровне приватности самого сервера. В моем случае, наличие сервера (VPS или дедикейт) это необходимое условие. Работу то надо же как то показывать клиентам. Несанкционированный доступ к репозиторию можно получить только если будет взломан сам сервер. Бесплатные гит этого никак не гарантируют. Пруфы искать не буду, но они были и неоднократно.
Вдобавок, если у меня уже есть сервер (и не один) и там уже есть СКВ, то зачем мне переходить на еще одну СКВ с возможностью рассылать приглашения? Это закрытые проекты, никаких контрибьюторов там нет и не будет. Помимо кода, там совершенно спокойно лежат файлы со спецификациями/описаниями и тп. Мне гораздо спокойней спится, если я знаю, что они размещены не на «бесплатных» хостингах.
2. «ни одного разрыва» с начала нулевых. Вот реально ни одной проблемы с текстовым контентом. Я не понимаю, зачем мне менять одну, прекрасно работающую вещь, на другую, которая безусловно тоже прекрасно работает, но в случае небольших приватных проектов, она же будет использоваться ровно с таким же набором фич, что и первая, что мне это даст?
При всем при этом, если мне надо принять участние в каком-то другом проекте со стороны, у которого репозиторий на гит, я просто ставлю галочку у Git в настройках проекта GoLand/IntelliJ и использую Git.
Подключение к интернету нужно чтобы сделать коммит в репозиторий или получить свежие апдейты из него.
А еще чтобы сделать ветку, смержить ее, сделать дифф и так далее… Короче для всего.
То что вы используете свой сервак — это не плюс cvs.
Знаете как настроить гит на сервере? apt-get install git. Все!
Несанкционированный доступ к репозиторию можно получить только если будет взломан сам сервер. Бесплатные гит этого никак не гарантируют. Пруфы искать не буду, но они были и неоднократно.
Это полный бред, давайте пруфы. На гитхабе например хостится линукс и куча энтерпрайза. Сломать ваш хостинг вероятность куда больше чем гитхаб.
Kстати, в отличие от cvs, гит проверяет хеши того что вы в него кладете, и сразу вам скажет если файлы были изменены без его ведома.
Я не понимаю, зачем мне менять одну, прекрасно работающую вещь, на другую
Так бы сразу и сказали что по историческим причинам.
Но если у вас нет системы версионирования — то выбирать cvs вместо гита нет абсолютно никаких причин, с этим то вы согласитесь?
Какую систему управления версиями вы используетемой ответ: в данный момент CVS. Где тут вопрос «порекомендуйте СКВ»? Где тут рекомендация использовать CVS как единственную систему?
надежность бесплатного гит?
за 5 минут нашел https://habr.com/ru/post/211845/, https://habr.com/ru/post/319786/
еще тут же на хабре была новость просто утечку дефолтного пароля в ряде прошивок популярных маршрутизаторов из сорцов на том же гитхабе. И про самсунг тоже было.
И еще будет. Потому что, любая большая сложная широкоизвестная и всем доступная система всегда будет подвержена такого рода багам и отверствиям.
Но если у вас нет системы версионирования — то выбирать cvs вместо гита нет абсолютно никаких причин, с этим то вы согласитесь?нет, не согласен. потому что это зависит от размера команды, стартовых условий, в конце концов NDA может быть таким, что там нельзя будет использовать ни гит ни что то иное. Как хочешь так и крутись.
Для личных проектов SVN
Возможно, там и правда что-то сделано проще, но почему в 10 раз-то?
Потому что нет detached head, потому что сабмодули работают лучше, потому что hg lfs работает лучше (не даст склонить если нет подключенного lfs модуля, в отличие от гита). И еще по куче причин которые я сейчас не смогу вспомнить. Минус — сам hg медленный достаточно и с серверами типа гилаба всё хуже, калитея так себе.
А в чём проблема с detached head? Последний раз в состоянии detached head мой локальный репозиторий оказывался два года назад...
И да, разве всё перечисленное на "в 10 раз" тянет?
Перечисленно на 10 не тянет. Я ж сказал что уже не упомню.
bfDeveloper, приди!
При активном использовании субмодулей голова у них отрывается довольно часто, тк родительский репозиторий ссылается лишь на хэш дочернего.
меньше всего проблем запомнилось с SVN
Я использую perforce но бесплатно. Вроде для небольших студий бесплатно. Хостинг свой только.
Не хватает варианта: сами себе написали свою VCS и ее используем :-)
Дома использую Mercurial+Bitbucket, но вот в обозримом будущем — не знаю, что будет. Пока нашёл некоторый изврат в виде Hg-Git (локально будут Mercurial, а удалённо Git), но там свои камни. Из тех, на которые пока наткнулся:
- Разные SSH ссылки. На самом деле, не большой камень.
- Разное понятие веток. Ветки Mercurial совсем не совместимы с ветками Git. Поэтому дабы этим плагином соорудить Git ветку, делается закладка (ну, то есть любая Mercurial закладка превращается в Git ветку), при этом именно ветки не заливаются (проекты с несколькими ветками пока не переносил и сильно не тестил, так что какой уровень огребания с этого будет — пока не знаю).
Плюс понимаете, да, можно взять Git, можно сидеть его неделями настраивать, писать алиасы, скрипты ещё что-то, но зачем? Я хочу инструмент, которым берёшь и пользуешься, не отвлекаясь на его настройку под себя. Вот таким инструментом и является Mercurial. Если я захочу повозиться just for fun, я поступлю как товарищи из SQLite: возьмусь писать свой велосипед.
Я не спорю, что Git кому-то полезен, я ничего не имею против этого инструмента. Но мне кажется, он избыточен для домашних проектов, реаализуемых в одиночку или с другом, когда делать нечего. Сейчас же для меня в нём единственный плюс — это широкая его поддержка.
я хочу просто пользоваться ложкой и вилкой, а не тратить недели на настройку примитивных, в принципе, инструментов
Каждый проект под свои задачи. Сейчас на работе например SVN. Проанализировали возможность переезда на Git, оказалось не удобно и не целесообразно. Вот так тоже бывает.
я хочу просто пользоваться ложкой и вилкой, а не тратить недели на настройку примитивных, в принципе, инструментов
В смысле? Что в гите вообще нужно настраивать?
Установил — и поехали.
До сих пор на одной машине не работает автоматическая авторизация в SourceTree — каждый раз вводи пароль.
Накрылась и работает через раз интеграция в VStudio — тупо (иногда) не видит изменений, не формируется коммит.
Пару раз из-за изменений проекта в двух разных местах (последний раз — изменение локального текстового файла, не выполнив пулл) привело к отказу пулл/мердж и вообще всей работоспособности гита, пришлось пересоздавать локальный репо — решение не нагуглил, точнее нагугленное не помогло.
Да я с отладкой столько не е**сь, сколько с гитом.
P.S.И да, я не хочу проходить курс повышения квалификации для использования ложки и вилки.
Пару раз из-за изменений проекта в двух разных местах (последний раз — изменение текстового файла) привело к отказу пулл/меррдж и вообще всей работоспособности гита, пришлось пересоздавать — решение не нагуглил.
Это вообще как?
Поднял машину, где возникала проблема — логов не нашел, видимо СурсТри и гит полные логи не хранят.
И даже сообщение об ошибке не помните? Они у гита, вообще-то, вполне человекочитаемые.
Если у вас на локальной машине был изменен файл и не закоммичен, а на другой закоммитили изменения в том же файле, то Git вам не даст сделать pull/merge, в отличие от SVN. Надо сделать git stash save, потом git pull, потом git stash pop, и разрешить конфликты если они будут. Как по мне, такая строгость удобнее, чем в SVN, просто всё более детерминировано.
Постоянно пользуюсь Git для домашних проектов, ни разу никакие скрипты не настраивал. Есть GUI клиенты, там все настроено, берешь и пользуешься)
Да куча хороших: SourceTree, SublimeMerge, но для меня самый удобный — GitExtensions.
SourceTree под виндой когда то был очень хороший, а потом они его основательно так попортили.
Сравнить версию под мак и под винду — так вообще небо и земля. SourceTree под маком это ИМХО, идеальный GUI для гита.
К GitExtensions под виндой у меня только 1 претензия — он выглядит как привет из 2000-х.
Может знаете, можно ли его как нибудь облагородить?
Знаю — у него есть страница с пожертвованиями :) https://opencollective.com/gitextensions Ну а еще лучше — пофиксить какие-нибудь баги из трекера: https://github.com/gitextensions/gitextensions/issues
При push необходимо указывать что и куда вливать.
А у hg push что, параметр DEST отсутствует?
Просто из интереса: а о каком велосипеде от товарищей из SQLight идёт речь? Они написали свою систему контроля версий?
Вдимо, https://www.fossil-scm.org/
Тут уже несколько раз это название упоминалось.
Ну на велосипед fossil никак не похож. Одна из лучших VCS в мире, с карточными играми и красивыми леди в придачу. И все это размером в спичечный коробок.
Пусть и самый лучший.
Потому что когда Хипп обнаружил, что его не устраивают существующие СКВ, он не приспособился, а сделал систему под себя и свои проекты.
Если это дефиниция велосипеда, то все СКВ – велосипеды, так как все они созданы потому что кого нибудь не устраивали существующие.
Ну, только SCCS не велосипед.
Давай посмотрим на fossil, что там сделано своего:
- Своя реализация NoSQL на базе самописного SQL–движка (SQLite)
- Свой скриптовый язык TH1 очень похожий на TCL
- Свой формат wiki
- Свой формат и стиль багтрекера
Понятно, что это всё дало основу для самодостаточности fossil'а, но велосипедом, пусть и очень хорошим, он от этого быть не перестал.
Команда маленькая, все имеют доступ ко всем веткам, code review всегда делается пост-фактум и пр. особенности workflow маленькой команды, поэтому никаких плюсов переход на git не дает.
Делают PR, исправляют одну опечатку, и для исправления одного символа создают еще commit, т.к. git commit --amend или git rebase -i не осилили.
А что, в Mercurial это делается как-то принципиально по-другому и легче? По-моему изменение истории — дополнительная фича.
а до Яндекса и в своих pet-project-ах: Git, но в текущих реалиях это банально. Возможно и голосовалку нужно было делать: какой системой контроля версий вы пользуетесь помимо git, ну или хотя бы давать выбирать два варианта ответа или больше.
Ещё интереснее было бы увидеть от от Яндекса собственный SaaS аля GitHub/GitLab/Bitbucket, где под капотом Arcanum, но чтобы и git протокол был доступен для клиентов. Плюс провязка с Яндекс Трекером. Всё это можно замаркетить под соусом импортозамещения и «национальной безопасности исходников». Хотя коммерческая оправданность такого сервиса всё ещё под вопросом.
Я бы скорее к JetBrains обратился с предложением построить хостинг кода на базе UpSource + Git.
А если вам хочется узнать больше — то вы всегда можете устроиться в Яндекс. В том числе и в отдел технологий разработки.
Работал с Mercurial и Git, Git мне больше нравится. На работе перешли с Mercurial на Git, в основном из-за всяких devops штук, интеграций, и т.д., но как по мне, разработка с ним тоже удобнее.
Можно перезаписывать ветки на сервере (git push --force-with-lease). Опечатки, доработки по pull-реквесту, в Git не надо это делать отдельным коммитом. В Mercurial вроде тоже так можно, но надо ставить отдельное расширение на сервер и клиент (Evolve Extension), и работает оно немного по-другому. У нас версия была старая (работает — не трогай), это расширение не поддерживалось, поэтому подробностей не знаю.
В Mercurial проще запушить то, что не надо. В сочетании с тем, что перезаписать историю на сервере нельзя, это немного неприятно. Для управления этим есть фазы коммитов, можно поставить фазу secret, и изменения не попадут в push, но в Git организовано удобнее — есть своя ветка, делай в ней что хочешь. Залил не то, можно перезаписать.
Можно править историю локальных коммитов перед push (git rebase). Делаешь много мелких коммитов — основные шаги, промежуточные шаги, мелкие исправления — потом их объединяешь в нормальные законченные коммиты. В Mercurial тоже можно, опять же через расширение, которое надо включить (MQ extension), но в Git управление более удобное. Можно задать действия сразу для всех коммитов, для любого diff посмотреть, а в Mercurial надо каждым шагом вручную управлять, и diff для следущих коммитов не показывается (тут я имею в виду TortoiseGit и TortoiseHg Workbench, может в другом GUI клиенте по-другому). Также в Git можно сделать бэкап ветки перед rebase, в Mercurial я не разобрался, как это сделать (иногда при каком-нибудь большом рефакторинге бывает надо пару раз rebase сделать, и бывает, что первый раз объединил неправильно).
В Mercurial есть именованные ветки, которые часто представляют как преимущество перед Git, но разработчики официально рекомендуют ими пользоваться только для долгих веток.
"It is best used for features which will be developed side by side with default for some time (and many commits), so tracking the default branch against the feature is relevant. To mark single-commit features as belonging to a feature, just use the commit message."
Не очень понятно, как предполагается делать pull-реквесты и ревью таких single-commit features. Там же ниже упоминаются bookmarks, которые являются аналогом веток в Git. Если делать через них, то можно тогда сразу Git использовать. Тут есть сравнение разных подходов к организации веток.
Мы для задач использовали именованные ветки. В той же документации говорят, что может быть "certain performance problems", но похоже это касается только листинга веток. У нас проблем не было, но мы пользовались этим где-то полгода, потом перешли на Git. При этом в коммите все равно приходится писать номер задачи, так как Annotate в PHPStorm не показывает название ветки Mercurial.
hg rebase работает превосходно. Если rebase проходит с конфликтом, то нечго его делать. Надо делать merge двух голов одной ветки отдельным коммитом. Тогжа всё чётко и понятно, было такое, смержили вот так.
Неизменность публичных коммитов — отлично.
в этом нет проблемы
Так дело в том, что не все изменения на сервере являются публичными и законченными, чтобы их в камне высекать. Процесс, определяющий надо или нет — это код-ревью. А для него надо, чтобы изменения уже были на сервере, чтобы их мог просмотреть кто-то другой. Изменения по задаче жестко зафиксированы когда они смержены в главную ветку, а до этого нужна возможность их менять. Вот проблема в том, что жестко фиксируются изменения, которые не должны.
hg rebase работает превосходно
Насколько я знаю, hg rebase берет изменения с одной ветки и просто переставляет их на другую, без возможности влиять на результат. Интерактивный rebase в Git это редактирование истории коммитов. Его аналогом является MQ. Я говорил не про конфликты, а про ошибку в редактировании истории, когда проще откатить как было и заново начать.
hg rebase берет изменения с одной ветки и просто переставляет их на другую, без возможности влиять на результат.Помоему при конфликте он предложит вам это решить. В наших гайдлайнах это запрещено. Ребейс это как раз для просто переставть. Есть переставить просто не получается, то нужен мерж. Именно мёрж покажет два рабочих состояния до и отдельно зафиксирует коммит их слияния и правки которые потребовались для этого.
Я говорю не про конфликт, а про изменение истории. Когда 2 коммита надо объединить в один, потому что там логически связанные изменения, 1 разбить на 2, потому что там много логически несвязанных изменений, и 1 пропустить, потому что там тестовые изменения случайно закоммитились.
Опечатки, доработки по pull-реквесту, в Git не надо это делать отдельным коммитом.
А что в этом хорошего-то? По факту есть изменение, которое не зафиксировано. С таким же успехом можно всю разработку какого-то элемента вести, сохраняя файлы в локальной папке, ее же отослать на ревью, а потом итог закинуть в СКВ одним махом. Толку-то?
Толк тут в том, что PR — штука публичная, её можно посмотреть и изучить через web-интерфейс или скачать "поиграться" к себе. Локальную папку так скачать не получится. Или, другими словами, когда вы "отсылаете на ревью" локальную папку, она перестаёт быть вашей локальной.
В то же время, открытый PR ещё не является частью проекта, а потому его история изменений пока что никого не интересует.
По факту есть изменение, которое не зафиксировано.
Почему не зафиксировано? Сделали допустим коммит, "Change text messages in logs", потом оказалось, что одну строчку не поменяли, появился еще один коммит "Change missed text message". Если их объединить, все изменения будут зафиксированы в одном коммите. Зачем их оба в истории хранить, если было намерение поменять все сообщения?
Зачем их оба в истории хранить, если было намерение поменять все сообщения?
Например чтобы можно было поучится на чужих ошибках.
Так это случайная ошибка, чему там учиться? Что не надо пропускать строчки, которые надо поменять? Так это и так все знают. Случайности все равно происходят.
Ошибки, они разные бывают. А редактирование истории – одно на всех.
Вот у вас есть история в 20000 коммитов, вот есть мерж полугодовой давности на 20 коммитов по некоторой задаче. В третьем куча изменений, в седьмом исправление опечатки в этих изменениях, в девятнадцатом исправление бага, в остальных промежуточные изменения. По каким признакам вы выберете именно третий и девятнадцатый коммит именно в этом мерже для обучения на чужих ошибках?
Если я бы знал какие коммиты понадобится мне в будущем, то оставил бы только их, а всех остальных выпилил бы. Чтобы уменьшить энтропию.
Но тогда и система контроля версии не понадобилась бы. Зачем она мне если я точно знаю что мне потребуется и что нет?
Но так как я не Ванга (хоть и из Болгарии) и в будущем смотрю очень плохо, то пусть VCS отслеживает историю так как она случилась. Зачем упрощать ей работу? Она и так справляется прекрасно.
Я говорил про конкретное утверждение "чтобы можно было поучится на чужих ошибках". Хранение двух коммитов с интервалом в 10 минут вместо одного никак этой цели не способствует, так как найти в истории 2 таких коммита довольно сложно.
А я говорил, что историю трогать нельзя, как бы хороша эта идея не казалась нам сегодня.
Потому что история, это на завтра, а не на сегодня.
Ну так вы же не в первый раз с системой контроля версий работаете. Приведите пример, когда изменение сообщений в логах в 2 разных коммитах оказалось полезным, или любой другой аналогичный. Я свой привел, даже два, и для полезности и для проблем.
И как по вашему дать пример, который относится к будущем??? Я не знаю понадобится ли мне чтобы были два коммита наместо один.
И так как не знаю, то лучше чтобы были два. Потому что сделать из двух один проще-простого. А сделать два из одного, принципиально невозможно.
Пусть история документируется так, как произошла, а не так как субъективно больше кому-то нравится.
И как по вашему дать пример, который относится к будущем???
Так у вас сейчас будущее по отношению к ситуации в прошлом. Если вы работаете с системами контроля несколько лет, и ни разу не было ситуации, когда 2 коммита вместо одного оказалось лучше, значит вероятность такой ситуации крайне мала, и не надо каждый день по каждой задаче принимать меры, которые будут полезны в такой ситуации, но создают проблемы в другой.
Пусть история документируется так, как произошла
Почему тогда не делать коммиты по одной строке? Программист же по одной строке за раз редактирует.
Зачем упрощать ей работу?
Это упрощение работы программиста при анализе кода.
Так у вас сейчас будущее по отношению к ситуации в прошлом.
Это конечно так. Только дело в том, что моя VCS всегда пишет история так как она случилась. Поэтому я всегда нахожу то что мне нужно. Пусть скажем, коммиты -А-Б-В-. И мне пришлось возвратится к коммиту Б. Так, вот, если кто нибудь слил бы его в прошлом например так: -АБ-В-, -А-БВ- или даже -АБВ-, то мне это не понравилось бы, потому что мне понадобился именно Б. Но это потому что у меня история непереписанная. А если у кого нибудь переписанная, то он даже и не задумался бы, не лучше ли было-бы если вот этот коммит был-бы менее объемистом.
В будущем, история всегда воспринимается так, как задокументирована. И история не знает сослагательное наклонение. Так что лучшее что можно вообще сделать с этим – писать то что случилось и не писать то, что не случилось.
Это упрощение работы программиста при анализе кода.
Система контроля версии, кроме записи истории, предназначена и для проведения анализа этой истории. Если инструменты VCS недостаточно продвинутые, то да упрощение истории упрощает работы программиста вручную анализировать историю. А вообще-то, анализ должен быть автоматическим и тогда гранулярность истории значения не имеет.
Почему тогда не делать коммиты по одной строке?
А что такое? Иногда именно так и делается. Когда логика изменения таковая.
А если у кого нибудь переписанная, то он бы даже и не задумался бы, не лучше ли было-бы если вот этот коммит был-бы менее объемистом.
Зато если не переписанная, то он бы часто задумывался о том, что было бы лучше, если бы эти 2 коммита были бы одним более объемистым. Именно поэтому и появляется мысль, что лучше делать логически связанные изменения одним коммитом, а не несколькими — когда сталкиваешься с проблемами поиска таких изменений, которые разбросаны по разным коммитам.
Проверять, нужно ли делать коммит менее объемистым, нужно при его создании. И в этом редактирование истории тоже помогает — решил, что написал много, взял и разделил.
В будущем, история всегда воспринимается так, как задокументирована.
Так что лучшее что можно вообще сделать с этим — писать то, что намеревались написать. Потому что история изменений это форма документации. Вы когда текстовую документацию пишете, или комментарий на Хабре, тоже все предыдущие варианты текста всем показываете? Нет, вы показываете законченный сформированный текст. Вот и тут так же, в истории должен быть законченный сформированный коммит, а не исправление опечаток.
А вообще-то, анализ должен быть автоматическим и тогда гранулярность истории значения не имеет.
Ну как это не имеет. Автоматические инструменты пока что не умеют оценивать логику кода, значит поиском связанных изменений будет заниматься программист. Для него удобнее, если они связанные изменения находятся вместе.
А что такое? Иногда именно так и делается. Когда логика изменения таковая.
А причем тут иногда? Разговор же про всегда. Вот например в этом коммите, по каким причинам вы сразу несколько десятков строк закоммитили? Вы же их по отдельности в редакторе изменяли, а не одновременно. Это ведь то, что случилось, значит по вашим словам и в истории они должны быть по отдельности.
Так что лучшее что можно вообще сделать с этим — писать то, что намеревались написать.
То-есть:
- В реальности хотели как лучше, но получилось как всегда.
- В истории записали что хотели как лучше и получили как лучше.
- ........
- Профит!!!
:D :D :D
Почему? В реальности тоже получили как лучше, только выполнили команду "commit" два раза вместо одного. Реальность это всегда конечное состояние истории, история не может давать отличающийся от реальности результат.
история не может давать отличающийся от реальности результат.
Конечно, но путь по котором был достигнут этот результат, весьма важен.
А вы утверждаете, можно просто соединить точки прямыми и все будет в порядке. Путь гладок и прямолинеен.
А то что овраги потерялись – кому нужны эти овраги? Так?
Смотря что вы подразумеваете под оврагами. Я привел пример — одна пропущенная строчка с сообщением лога. Я считаю, что ее надо добавлять в основной коммит.
Смотрите, если бы программист не торопился, он бы нашел все строчки, и только потом закоммитил, одним коммитом. Потом бы сделал еще пару коммитов для другой функциональности по той же задаче, и только потом отправил всё вместе на сервер. Это нормальный вариант событий, причин специально делать 2 коммита для изменения логов нет. Ну так почему он не может так сделать, если выполнил команду "commit" раньше чем нужно, не проверив все досконально, и еще не залил на сервер? Это все еще его личные изменения, они находятся только на его машине.
Он ведь может редактировать файлы на своей машине как угодно, пробовать разные варианты, не фиксируя в истории каждую строчку, и только потом сделать коммит. Почему эти изменения можно не отражать в истории, а аналогичные сделанные после локального commit нужно обязательно?
Поэтому путь остается тот же самый, какой и должен быть — есть один коммит с изменением сообщений лога, привязанный к задаче. Путь важен, и он есть в истории.
На всякий случай повторю — я не сторонник делать squash в один коммит при мерже. В одном коммите должно быть одно логическое изменение функциональности. Если задача требует несколько коммитов, должно быть несколько коммитов. Но не больше, чем нужно.
Смотря что вы подразумеваете под оврагами.
Под оврагами я подразумеваю когда что-то пошло не так. Например когда кто-то торопился и поэтому пропустил строчку в логе. Мало ли что интересного можно увидеть, если не редактировать историю?
Мне это интересно. Мне вообще интересно иногда поизучать ошибки других, чтобы сам их не допускать.
И вот пришел я в вашем проекте, начал рассматривать историю, а ошибок то и нет. Все причесано, все красиво, все безгрешны.
И в результате, получу я депрессию и синдром самозванца в придачу – ведь все безгрешны и только я все время делаю ошибки в коммитах. :P :P :P
И как по вашему дать пример, который относится к будущем???
Ну вы даже предположить не можете нафига вам в будущем будет такая история:
— add feature
— fix typo
— fix typo
— fix typo
Если последние три относятся к самой фиче.
A теперь еще представьте что вы работаете в большой команде, там где у каждого участника будут такие «мусорные» коммиты.
Нахрена они в истории?
История должна выглядеть так, чтобы в ней было легко ориентироваться.
История должна выглядеть так, чтобы в ней было легко ориентироваться.
Инструменты исследования истории должны быть такие, чтобы в историю было легко ориентироваться.
А иначе история получается:
Мы строили, строили и наконец построили. Ур-а-а-а!
Мы строили, строили и наконец построили. Ур-а-а-а!
У нас на проекте например история выглядит примерно так:
- LOS-1042: Feature / Make all Celery tasks work with Python 3
- PROD-2231: Fix / Missing user avatar
- PROD-2165: Feature / Add base client unique validation
- PROD-2246: Fix /Remove duplicate client logos in admin panel
- LOS-1039: Fix / Flake issues and update invalid code to pep8
...Т.е. каждый коммит — это либа фича, либо фикс, который делался одним определенным человеком.
Чем мне поможет если их будет не 1 на каждую фичу, а 500?
Автор один, код относится логически к одной фиче/фиксу. Кроме того есть номер таски в джире, где можно почитать детали. Вы можете объяснить чем разбиение каждой фичи на 100 коммитов реально могло бы быть полезным, кроме как «я считаю так правильно»?
И еще вопрос — вы работате один или в команде?
Чем мне поможет если их будет не 1 на каждую фичу, а 500?
Вопрос неправильно задаете. А чем вам навредит, если 500?
Может навредит лишь отсутствие информации. Больше информации навредит не может в принципе.
А очевидно, 1 коммит несет меньше информации, чем 500 коммитов.
Вопрос неправильно задаете. А чем вам навредит, если 500?
Ну для начала, надо понять что их именно 500, а не 497, и не 508. И понять где фича начинается, а где кончается. Или все сообщения коммитов предлагаете «префиксить» какой-нибудь строкой (очень удобно)
А очевидно, 1 коммит несет меньше информации, чем 500 коммитов.
А вы лучше скажите, как вы будете использовать историю коммитов при ревью пулл реквеста.
Вот вам приходит на ревью фича. Зачем вам история коммитов? Будете смотреть как человек писал этот код, исправлял опечатки и т.д. Или будете просто оценивать что в итоге получилось?
И на второй вопрос вы не ответили. Мне что-то подсказывает что вы работатете в основном в одиночку. При таком подходе можно сколько угодно комитить и не париться. И конфликтов то особо не будет скорее всего. А когда вам приходит по 50 коммитов от 10 разработчиков — это совсем другая история.
Больше информации навредит не может в принципе.
Может. На обработку информации требуется время. Чем больше информации, тем больше времени. И ресурсов для выполнения этой обработки.
Здесь разницы в количеству информации небольшое (буквально сотни байтов) и не имеет значение для обработки.
Проблема в том, что при слияния коммитов и редактирования истории теряется класс информации. Например информации об ошибках. Или то насколько часто делались коммиты, в какое время сутки. И как на самом деле происходила разработка.
Если вам все это неинтересно, то все это можно отфильтровать используя подходящие инструменты на этапе анализа. Но ведь, кому нибудь в будущем вся эта информация возможно будет интересна?
Или вы думаете: "Раз мне это не интересно, значит никому никогда не будет интересно."
Я думаю, история нужна для документирования, а не для интересных игр. В документации должно быть только то, для чего эта документация сделана. В случае СКВ это взаимосвязанные изменения в файлах проекта, привязанные в свою очередь к внешнему источнику причин этих изменений (к задаче). Все остальное это мусор, и его в документации быть не должно. Если взаимосвязанные изменения разделены, это неправильная документация, она не соответствует реальному положению дел.
А уж ошибок в документации вообще быть не должно. Представьте, что вы читаете документацию, там есть большой и сложный абзац, который вам нужен, вы потратили полчаса на то, чтобы разобраться, а потом в конце написано "это все было неправильно, теперь работает вот так", и еще один такой же абзац. Это хорошая документация? Я считаю, нет.
Кроме того, изменения в состоянии проекта должны быть атомарными, чтобы можно было их легко откатить, повторить, сделать аналогичные, но чем-нибудь отличающиеся. Когда связанное изменение разбито на разные части, или несколько независимых изменений объединены в одно, это сделать сложнее.
История разработки, это не документация! Это лог событии. И как каждый лог, она должна быть предельно точной.
А документацию можно и нужно синтезировать обрабатывая этого лога. Можно даже и в реальном времени.
Ну тогда возвращаемся к изначальному вопросу — почему вы делаете коммиты по несколько строк, если каждую строку редактируете отдельно? По каким принципам вы их объединяете?
Почему не коммитите каждую опечатку при наборе текста? Эти события ведь произошли, они должны быть в логе. Почему одни опечатки должны оставаться в коммитах, а другие нет?
Ну, для меня программирование, это вид творчество. И поэтому я делаю коммит, тогда когда мне кажется, что время его сделать. Иногда, коммичу каждую строку, когда мне кажется что так надо. Иногда делаю бранч, потом мержу его. И вообще, как правило, у меня всегда активны по крайней мере 4..5 ветки разработки.
Вообще, "я художник, я так вижу". :D
Но предмет искусства, здесь именно программа. А история, это лог работы, который потом помогает разобраться и анализировать как я работал и как эту работу можно улучшить в будущем. Именно поэтому для меня точность и непричесанность истории очень важна.
Как я уже писал выше — почему тогда не закинуть в СКВ просто конечную версию фичи, оттестированную и готовую к применению? Сразу все 10 тысяч строк. Ведь, как пишет mayorovp, «локальные изменения до PR никому не интересны».
mayorovp
В то же время, открытый PR ещё не является частью проекта, а потому его история изменений пока что никого не интересует.
Мне, как пользователю централизованной СКВ, не понять «а потому его история изменений пока что никого не интересует», простите. ПМСМ, это интересно, как минимум постфактум, потому что показывает ход разработки, косвенно указывает на причины принятых решений. А не просто на конечный результат.
Меня при работе с legacy кодом часто спасают как раз коммиты промежуточных этапов. Просто потому что комментарии к ним обычно содержат пояснения изменений, которые важны для понимания того или иного участка. Почему человек сделал так, а не иначе? А вот — пожалуйста — в истории видно, что это решение было опробовано и отвергнуто потому и потому. Граждане довольны, расходятся по домам (с).
michael_vostrikov
По каким признакам вы выберете именно третий и девятнадцатый коммит именно в этом мерже для обучения на чужих ошибках?
Например, по blame'у. В одном случае будет видно, как менялся тот или иной блок, строка. В другом — просто «состояние 1- состояние 2». Информативности 0.
johnfound
Но тогда и система контроля версии не понадобилась бы. Зачем она мне если я точно знаю что мне потребуется и что нет?
вот-вот:
«почему тогда не закинуть в СКВ просто конечную версию фичи, оттестированную и готовую к применению? Сразу все 10 тысяч строк.»
Так история — это два коммита один за одним, а не просто конечный результат.
История это изменения кода, обычно привязанные к причинам этим изменений (задачам). Поэтому коммиты должны показывать намерения. "Было намерение сделать в этой части такие изменения по вот такой причине". Соответственно, если причины требовали одних изменений, а фактические изменения отличаются, это баг. Поэтому искать причины багов или вносить изменения в существующую функциональность проще, когда история организована в такие логически связанные блоки. А когда один блок разделен на несколько частей (или наоборот, смешан с другими), то разбираться в причинах изменений сложнее, надо искать разные части и объединять их в уме.
Как я уже писал выше — почему тогда не закинуть в СКВ просто конечную версию фичи, оттестированную и готовую к применению?
Почему бы тогда в СКВ не хранить движения мышки и нажатия клавиатуры, которые делал программист?
При поиске в истории нас интересуют намерения и связанные с ними изменения кода. Поэтому удобнее коммиты так и организовывать. Когда есть один большой коммит с несколькими несвязанными изменениями, это тоже неудобно, так как непонятно, какое изменение кода к какому намерению относится.
Например, по blame'у
Дак там только последнее изменение, которое было может вчера. А когда доберемся до нужного периода, там будет у одних изменений один хеш, у других другой, и тоже только конечный результат. Информативности тоже 0, и появляются разные вопросы — почему сразу ту строчку не изменили, может причины какие-то есть, может этот лог парсится какой-то утилитой, и надо сначала ее перенастроить, надо лазить по истории, анализировать коммиты и сообщения к ним, спрашивать у кого-то а почему так.
А когда один блок разделен на несколько частей (или наоборот, смешан с другими), то разбираться в причинах изменений сложнее, надо искать разные части и объединять их в уме.
Вовсе необязательно. У нас в команде эти коммиты будут привязаны к одному таску, можно сделать выборку истории по его номеру.
Почему бы тогда в СКВ не хранить движения мышки и нажатия клавиатуры, которые делал программист?
Потому что мы говорим об изменения кода в системе контроля версий (кода). Изменение — от одного символа и больше, способ ввода не дает никакой дополнительной информации. В отличие от последовательных коммитов в виде проб и ошибок.
Дак там только последнее изменение, которое было может вчера. А когда доберемся до нужного периода, там будет у одних изменений один хеш, у других другой, и тоже только конечный результат
Не знаю, как это устроено в git, в SVN я просто попрошу показать изменения не включая последний коммит по данной строке и получу предыдущие изменения, связанные пачкой. Опять же — привязка всех коммитов, втч промежуточных, к таску.
там будет у одних изменений один хеш, у других другой, и тоже только конечный результат.
Почему только конечный, если как раз политика «коммитить промежуточные этапы тоже»?
Информативности тоже 0, и появляются разные вопросы — почему сразу ту строчку не изменили, может причины какие-то есть, может этот лог парсится какой-то утилитой, и надо сначала ее перенастроить, надо лазить по истории, анализировать коммиты и сообщения к ним, спрашивать у кого-то а почему так.
Наоборот — это будет в случае, если закоммитили сразу готовые 10к строк и комментарий(и) вида «пофикисли багу». У нас пишут развернутые комментарии, даже если изменили всего один символ. Опять же… привязка коммита к таску, где при необходимости оставят еще более развернутые комментарии. Просто потому что через год-два сам человек не будет помнить «почему так».
Другое дело если они все «годные», тогда можно и не сквошить, но надо конечно иметь достаточно покрытия чтоб писать так красиво :)
Промежуточные же нестабильные снэпшоты часто не несут смысла отдельно от всей кучи (мало чинят, больше ломают).
А это не всегда очевидно — будет ли в будущем польза от такого коммита.
Выше другого человека просили привести пример, привожу из своей практики:
Есть ошибка, исправление занимает 1 строку. Скажем, было «строка1», я закоммичу «строка2». Однако мне кажется странным, почему применили именно «строка1», лезу в историю, нахожу, что изначально было «строка3», ее заменили на «строка2» (как я хочу сделать), а потом на «строка1».
Когда «мой» вариант был закинут, он решал какую-то проблему, но следующий коммит имел комментарий, указывающий на то, что «мое» решение («строка2») поломало то и то в другом месте, почему применили строка1 как компромиссный вариант. В самом таске было написано чуть подробнее, но я бы не полез это выискивать, если бы не видел, что «моё» «строка2» уже было отвергнуто.
В итоге я вернул «строка3», исправил пару ошибок в других местах, так что решение стало покрывать все случаи.
Когда работаешь с legacy кодом, любая мелочь помогает, и наперед я не могу сказать, какой коммит пригодится, какой нет. Тот человек вполне мог «исправить историю» и закинуть только работающий (на тот момент) вариант, и я бы не узнал, что мое решение — негодное, было уже опробовано, не узнал бы почему оно негодное.
michael_vostrikov это и вам ответ с примером. Также наши разногласия сильно зависят от используемой СКВ. Я размышляю в рамках централизованной системы, поэтому мне неведом ряд из указанных вами проблем и наоборот.
Когда «мой» вариант был закинут, он решал какую-то проблему, но следующий коммит имел комментарий, указывающий на то, что «мое» решение («строка2») поломало то и то в другом месте
Так это значит, что первый вариант ушел в продакшн, а только потом его поменяли. Иначе бы комментарий был сразу в коде в том же коммите "такую строку писать не надо, ломается то-то и то-то". Ну так и в моем варианте он будет отдельным коммитом и уйдет в продакшн. Публичные коммиты я редактировать не предлагаю. То есть в моем варианте вам бы не надо было обращать внимание на странность и лазить по истории, всё было бы сразу в одном коммите. О чем я и говорю.
Также наши разногласия сильно зависят от используемой СКВ
Я работал с SVN, поэтому могу сравнивать. Возможность поправить опечатки гораздо удобнее ее отсутствия.
Так это значит, что первый вариант ушел в продакшн, а только потом его поменяли.
Не в продакшн, а в trunk. Проблема была замечена при QA trunk версии или даже при локальном тестировании самим разработчиком или кем-то еще из команды — уже не помню за давностью лет.
Я работал с SVN, поэтому могу сравнивать. Возможность поправить опечатки гораздо удобнее ее отсутствия.
Вы почему-то априорно полагаете, что условные опечатки надо исправлять, посему считаете систему с таким функционалом удобнее.
В вашем случае несколько изменений будет в одном коммите, в моем мире несколько изменений будут в одном таске. С разбиением их — тасков — на достаточную гранулярность для удобства восприятия. И искать информацию вы будете по коммитам (законченный этап, готовая фича-исправление и т.д.), а я — по задаче в тасклисте(багтрекере). Разный workflow, разные СКВ.
в моем мире несколько изменений будут в одном таске
Так и в моем тоже. Просто на одно логическое изменение будет один коммит, а не два.
Логическое изменение — это не таск, это изменения в файлах, которые можно отнести в одну группу. Вот есть изменения в файлах A, B, C с новыми сообщениями логов, вот есть изменения в файле D с такими же новыми сообщениями логов. Не коммит, а изменения на диске. Неважно, будет ли программист добавлять изменения в коммит по одному файлу или все сразу, это все равно одно логическое изменение проекта. Так удобнее анализировать историю. А если анализировать не надо, то и история не нужна.
Разный workflow, разные СКВ.
Привязка коммита к задаче от СКВ не зависит. С Git это тоже используется практически везде.
Не в продакшн, а в trunk.
В транк/мастер/чтототамещё это изменение тоже ещё не попало. Если же попало — значит, это публичный коммит, который редактировать нельзя. и с этим тут не спорят.
Если же попало — значит, это публичный коммит, который редактировать нельзя. и с этим тут не спорят.
Потому что в вашем workflow есть публичный и приватный коммит. В моем — все изменения запушены в центральный реп, иначе никак. И все последовательные изменения, даже частичные реализации — тоже. Если это просто последовательные CtrlS, то их нет как сущностей. А если вы пушите в свою отдельную приватную ветку, это все равно привязано к task'у и потом может быть вытащено при изучении истории.
Кстати, вспоминается RSX-11M и Files-сколько-то там с автоматическим версионированием. При сохранении файла при определенных настройках файл копируется с указанием номера версии, к которой потом можно обратиться, скажем, «abc.ftn;125»
michael_vostrikov
Логическое изменение — это не таск, это изменения в файлах, которые можно отнести в одну группу.
и это (в моей команде) означает включение в один task. Учитывая, что они имеют у нас древовидную структуру, т.е. любое большое изменение разбито на под-таски, каждый из которых соответствует логически завершенному участку.
Так удобнее анализировать историю.
В моем случае просто выборка будет делаться по другому ключу — по таскам.
YemSalat
Нафига мне на ревью история коммитов, если код я все равно буду оценивать в готовом виде?
Ну, в случае ревью я буду видеть, что коммиты с номера X по Y относятся к task'у, который мне и прислали на code review — здесь никакого неудобства нет. А чем может быть полезна история мелких коммитов в ретроспективе — см. выше пример с тремя строками.
В общем, друзья, это bikeshed discussion, так что закругляемся.
В моем — все изменения запушены в центральный реп, иначе никак.
Отлично, теперь я не могу нигде сохранить промежуточные результаты, чтобы не потерять их. Только не понятно почему это преимущество.
Ну и непонятно как принимать PR открытым проектам.
Логическое изменение — это изменения в файлах, которые можно отнести в одну группу.
и это (в моей команде) означает включение в один task
То есть у вас на один таск должен быть один коммит? О чем же вы тогда спорите? Если коммитов может быть больше одного, даже если нет опечаток, значит есть дополнительный логический признак, по которому вы их разделяете.
В моем случае просто выборка будет делаться по другому ключу — по таскам.
В Git тоже выборка делается по таскам. Просто удобнее, когда по таску 7 коммитов, а не 20, из которых 3-й и 19-й содержат схожие изменения строк в логах, а 4-й и 12-й взаимно компенсирующиеся изменения, которые ни на что не влияют.
«It's really important to get the rebase thing figured out so the changes you propose in any given commit reflect the final state of that code and are not reversed or modified in a subsequent commit. So if you change your mind about something, you go back to that commit, make the changes, amend the commit (git commit -v --amend --reuse-message=HEAD) and then rebase any later commits onto the one you've just amended.
This gets really fast once you get the hang of it. What it produces is a successively refined set of „clean“ commits that each accomplish a specific purpose. Each of these can be reviewed and merged individually as they pass muster. If you review historical commits you'll see this pattern over and over (except during some refactoring „periods“). A feature starts with a „docs: document XYZ analysis“ commit, goes on to an „acpt: add scenarios for ...“ acceptance test commit, then a series of individual property or method commits with its respective unit test. Each one is focused, relatively small (usually), and easy to validate.
Otherwise, it's extremely difficult to see what the changes really are, because they're distributed across multiple commits. It would basically make it more work for the committer (me) than doing it myself.»
И вообще сам проект весёлый :)
У нас в команде эти коммиты будут привязаны к одному таску, можно сделать выборку истории по его номеру.
Ну да, и потом среди 20 коммитов по таску выискивать те, которые относятся к одной функциональности. Третий и девятнадцатый.
Изменение — от одного символа и больше, способ ввода не дает никакой дополнительной информации. В отличие от последовательных коммитов в виде проб и ошибок.
Так и 2 последовательных коммита не дают новой информации. Какая новая информация в том, что исправили пропущенную строчку в логах? То, что была задача их поменять, и так понятно из предыдущего коммита.
Мы говорим об изменения кода, поэтому и отслеживать надо законченные и логически связанные изменения кода, а не ошибки программиста, исправленные через 10 минут.
Ну ок, не хотите движения мышки записывать, давайте делать коммиты из одной строки. Программист же по одной строке за раз изменяет. Это будет удобно, по-вашему? Вот по тем же причинам, по которым не надо разбивать коммиты построчно, не надо их разбивать и на части других размеров. Если так случилось, надо разные части объединить. А 2 несвязанных коммита объединять не надо. Фактические изменения должны быть равны логическим изменениям. Тогда логику изменений будет удобно отслеживать.
и получу предыдущие изменения, связанные пачкой
Ну я об этом и говорю. Вот у нас есть 10 строк вида $logger->log("New message"). Получаем изменения для одной строки, там указано, что строка изменилась в коммите с хешем aabbcc, а раньше была $logger->log("Some message"). Получаем изменения для другой строки, там указано, что строка изменилась в коммите с хешем ddeeff, а раньше была $logger->log("Some message"). Никакой дополнительной информации, отличаются только хеши коммитов.
Почему только конечный, если как раз политика «коммитить промежуточные этапы тоже»?
Я имел в виду состояние файла на конец нужного периода. Там будут строки $logger->log("New message"), которые отличаются только разными хешами предыдущего коммита.
Наоборот — это будет в случае, если закоммитили сразу готовые 10к строк и комментарий(и) вида «пофикисли багу».
Где я предлагал коммитить 10к строк с неинформативными комментариями? Я наоборот сторонник того, чтобы делать по задаче несколько коммитов, если она того требует. Я говорил про конкретный пример — исправить сообщения в логах. Какое сообщение надо написать в коммите с пропущенной строчкой, чтобы не было вопросов, почему сразу не поменяли?
А потом пришла задача снова поменять, человек открывает файл A, открывает Annotate, открывает коммит с аналогичными изменениями, и видит изменения в файлах A,B,C. Берет и меняет по аналогии. А там оказывается еще файл D надо было поменять, а он в другом коммите изменен.
Опять же… привязка коммита к таску, где при необходимости оставят еще более развернутые комментарии
Это и есть "спрашивать у кого-то а почему так", то есть искать ответ на этот вопрос. Зачем лазить по задачам, если можно не лазить по задачам? Когда связанные строки изменены все сразу, не будет и вопросов, почему поменяли не сразу.
Как я уже писал выше — почему тогда не закинуть в СКВ просто конечную версию фичи, оттестированную и готовую к применению? Сразу все 10 тысяч строк. Ведь, как пишет mayorovp, «локальные изменения до PR никому не интересны».
Многие так и делают. Комитят в свою ветку сколько хотят, но перед мержем собрают все коммиты в один.
Нафига мне на ревью история коммитов, если код я все равно буду оценивать в готовом виде?
Ну и пулл реквесту на 10 000 строк никто не будет рад, независимо от количества коммитов.
Практически ничего кроме гита не юзал в сознательном возрасте. Но после определенного времени изучения кажется, что в целом команды там все логичные и интуитивно понятные. Правда пользуюсь я им в основном через UI. Так что многих недовольных пользователей мне, видимо, не понять.
За последние 12 лет прошел путь SVN->Mercurial->Git (регулярное использование, на нерегулярной основе тыкал bzr).
Как по мне, git простой, быстрый и удобный :)
С ужасом вспоминаю людей которые юзали dropbox для версионирования и совместной разработки :D
перевод на гит вагона мелких проектов с битбакета это кошмар
Ctrl+F pijul → нет результатов
Как так-то? На работе и в opensource понятно: проще плакать и колоться, но быть понятным большинству потенциальных коллег.
Но в домашней разработке как можно использовать СКВ без спонтанного ветвления?
During the release of version 7.2ce at May 9, 2016, BitKeeper announced that it is starting to move from proprietary to open-source license.[10] The Apache License version 2 was chosen.
И даже есть свежие версии, видимо им пользуются.
Какую систему управления версиями вы используете (в реальной работе, больше всего)?