Comments 13
При этом Git хранит историю не как список отдельных правок в файлах, а как снимки состояния проекта (snapshots). Каждый коммит — это снимок того, как выглядели файлы в момент сохранения.
Вы (или ваш чатбот) git с SVN случайно не перепутали?
Вот тут всё проще, компактнее и понятнее. Безо всякий «а если не прокатило, попробуйте». https://git-scm.com/cheat-sheet
Никогда не нужно что-либо делать с системой контроля версий, если вы не понимаете что именно делаете. Вот прямо сейчас приходится разгребать мерж конфликты в двух ветках, которые разделились пару лет назад. «Всего» 650 конфликтных файлов, 90% из которых возникли потому что неправильно использовался git.
Каждый коммит в git описывает состояние проекта целиком и полностью, а видимый diff всегда вычисляется динамически. Коммит это дерево проекта (tree) + метаданные, более подробно в моей статье тут.
Вместо того чтобы минусовать мой комментарий - советую изучить как именно гит хранит историю. В git это diff-ы, в svn - состояние целиком и полностью. Иначе локальная папка .git у вас в любом проекте была бы неимоверных размеров.
Git выстраивает «состояние проекта» целиком и полностью только в момент checkout. Это одна из причин, по которой git очень удобен для локальной разработки без необходимости обращения к серверу для каждой операции.
90% из которых возникли потому что неправильно использовался git.
а можно по подробнее об этом? хотелось бы узнать что-то новое и понять не допускаю ли таких ошибок
В svn можно было просто скопировать файлы из одного бранча в другой, без черри пика. У нас делали так же - вместо отдельных черри пиков вручную копировали некоторые файлы из одного бранча в другой (и называли это rebase, что в корне неверно). И когда пришла пора мержиться - вылезла куча однотипных конфликтов, которые вроде как тривиально может разрулить тот же beyond compare или araxis merge, но по факту все мерж конфликты пришлось проверять вручную, и вылезло немало расхождений.
Астрологи объявили неделю Git: количество статей на Хабре по Git для новичков увеличивается в два раза.
Поднимать компанию в рейтинге, пуляя нейрятинку километровой длины - а давай!
Чего не хватает на хабре в 2026?
Конечно же статей про гит
Фото котиков больше бы пользы принесло, котики хоть разные
На Хабре в 2026 не хватает мыслей о том, как система с настолько сырой архитектурой смогла завоевать рынок и стать де факто мировым стандартом разработки.
Рассмотрим типовую ситуацию - разработчик ошибся в описании коммита, затем feature-ветку смержил в релизную ветку. Перед самой выкаткой на ПРОД ошибку заметили. ВОПРОС - как скорректировать описание какого-то (не последнего) коммита в релизной ветке? Оказывается, git не предоставляет такой возможности! Есть только возможность ПЕРЕСОЗДАТЬ коммит, указав правильное описание. При этом вся история более поздних коммитов тоже будет перезаписана, хэши коммитов будут изменены.
Т.е. есть два варианта
1) Удалять релизную ветку, в feature ветке править описание с перезаписыванием истории коммитов и потом заставлять ВСЕХ рзработчиков снова мержить все свое в новую релизную ветку - если релиз большой, трудоемкость всего это измеряется человеко-часами или даже человеко-днями
2) Править описание в релизной ветке и получать риск нестабильного состояния - если после правки вдогонку кто-то еще сделает мерж feature-ветки в релизную, часть коммитов может просто задвоится.
Т.е. варианты один другого не лучше.
Более правильной виделась бы архитектура, в которой помимо хэша коммита был бы ИД коммита, который никогда не менялся, и при перезаписывании истории чтобы новые коммиты с новыми хэшами имели ИД старых коммитов. И при мерже смотреть на ИД коммитов и КАК МИНИМУМ предупреждать, что коммиты с такими ИД уже были, но они сменили хэш.
У меня одного такие мысли в голове селятся или еще кто-то думает также, что в архитектуре гита есть упущения?
Ну, то что вы тут написали - это не совсем по теме статьи, то есть - не для начинающих.
Вот мое мнение, что делать в такой ситуации, с такой организацией веток (вообще-то feature-ветки (они же функциональные ветки, если писать по-русски) заводятят неженки (quiche eaters), а настоящие программисты нашего времени коммитят сразу master ;-) ) - править ошибку в функциональной ветке до ее реального исправления, опционально - объединить через squash все коммиты правок в один, а потом перенести исправления в ветку выпуска (release) с помощью cherry-pick. Если правка ошибки потребовала немнго изменений, то при таком подходе есть немалый шанс, что конфликтов при переносе (и, следовательно, нестабильности из-за них) не возникнет. Другой вариант (если уж заводить, как неженки, под каждую работу свою ветку) - завести bugfix-ветку (точно так же, как если бы выпуск уже вышел в бой) и править ошибку там, а потом влить изменения в ветку выпуска (опционально, если функциональная ветка ещё кому-то нужна - забрать с помощью cherry-pick изменения в нее). Ну, а у настоящих .программистов нашего времени таких проблем не возникает: они правят напрямую ветку выпуска (точнее, master, потому что отдельные веткуи выпуска они тоже презирают).
Ваше же предложение хорошо подходит для правки описаний, но не кода - невидимая в истории правка кода рано или поздно нарушит стабильность, будет плохо всем.и концов ненайдешь.
Ну, а Git занял свое место, потому что дал невиданную в системах управления версиями ПО ранее свободу. Например, мой сын работает в конторе, которая пишет ПО для паравозов, и это ПО по-настоящему проверить можно только на паровозе, а паровозы у нас не стоят в Москве, а ездят по всякой глухомани. И Git позволил организовать работу так, что программист берет в командировку в эту глухомань копию репозитория, ездит на паравозе, ищет ошибки, правит их прямо там же на паровозе (ну, или в гостинице), там же дописывает функции, недописанные в Москве, коммитит исправления/функции в свою копию репозитория, при необходимости откатывает назад и т.д. А потом привозит эту копию из командировки в Москву и отправляет изменения в основную копию. Попробуйте провернуть такой же трюк с каким-нибудь SVN. Сын эти времена практически не застал, но ему рассказывали, что до Git в той конторе брали с собой и правили непосредственно исходники - по многу раз, делая резервные копии, при необходимости восстанавлияваясь из них, а потом, по приезду, пытались влить это в SVN.
PS А вообще, Git - это open source, никто и ничто не мешает сделать его модифицированную копию с очком и девочками и попробовать распространить эту копию. Так что, если не нравится Git - дерзайте и не обессудьте.
Иммутабельность коммитов это не упущение, а намеренно принятое решение. Погуглите зачем это нужно.
Насчёт второго id, который не меняется, - по-моему jj так делает
Гайд по Git для начинающих: основные команды, работа с ветками и типичные ошибки