Комментарии 64
githowto.com/ru/git_internals_git_directory
Цитата — Смотрим в один из каталогов с именем из 2 букв. Вы увидите файлы с именами из 38 символов. Это файлы, содержащие объекты, хранящиеся в git. Они сжаты и закодированы, поэтому просмотр их содержимого нам мало чем поможет.
git-scm.com/book/ru/v2/Git-%D0%B8%D0%B7%D0%BD%D1%83%D1%82%D1%80%D0%B8-%D0%9E%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D1%8B-Git
Там подробно с примерами расписано как хранятся файлы в дереве
Теперь возникает вопрос: почему git победил svn?
На мой взгляд потому что нет зависимости от сервера. Недавно узнал что можно клонировать и пушить не только на сервер но и в дирректорию на диске.
В гите есть несколько уровней оптимизации. С точки зрения прикладного пользователя вы можете считать что он хранит полные копии каждого файла на момент его коммита. Но на самом деле гит периодически выполняет команду упаковки и в процессе ее выполнения анализирует обьекты в хранилище и вычисляет дельты между ними, в дальнейшем он заменяет обьекты на дельты за счет чего экономится место. При этом там есть еще куча оптимизаций вроде того что самые свежие версии файла хранятся целиком для быстрого доступа, а старые версии хранятся в виде отрицательных дельт для экономии места.
ИМХО git победил svn за счет гениальной организации и отличной и продуманной работы с ветками (до которой далеко тому же hg). Данная статья не описывает даже десятой части того насколько красиво внутри все устроено
git победил svn за счет гениальной организации и отличной и продуманной работы с ветками (до которой далеко тому же hg)Вот бы еще git научился безболезненно закрывать ветки не удаляя их, как hg, вообще ништяк было бы.
Что в вашем понимании безболезненно закрывать?
git merge позволяет смерджить ветку куда либо и не удаляет ее… это равно закрыть ветку?
Если вы хотите избавится от возможности создавать в ветке новые комиты — создайте тег с тем же именем и удалите ветку. останется зафиксированный тег. ИМХО у вас какой то странный запрос.
Что в вашем понимании безболезненно закрывать?Чтобы ветка оставалась собой, просто не отображалась в списке текущих, и без всякого шума. А в идеале еще чтобы в нее нельзя было закоммитить без переоткрытия, и чтобы в логе можно было фильтровать отображение промежуточных коммитов закрытых веток.
создайте тег с тем же именем и удалите ветку. останется зафиксированный тегЯ в курсе про такой способ, им и перебиваюсь, но будем честны это просто костыль. Большинство разработчиков используют теги для версионирования, а мелькающие среди версий огрызки веток выглядят ужасно и кустарно.
Если вы не следуете gitflow или похожему подходу, когда одна задача = одна ветка, то скорее всего у вас просто не возникнет такой проблемы.
ИМХО у вас какой то странный запрос.Настолько странный, что о нем писали сотни раз до меня. В hg это дефолтный способ работы с ветками.
будем честны это просто костыль.
Механизм тегов решает именно ту задачу о которой вы пишете:
1) не отображаются в основном списке веток
2) нельзя комитить в него без явного переоткрытия (создания новой ветки на основе тега)
Большинство разработчиков используют теги для версионирования, а мелькающие среди версий огрызки веток выглядят ужасно и кустарно.
Ничего не мешает создать некий префикс для имен таких тегов и фильтровать по нему. Даже с использованием тегов только для версионирования очень быстро их становятся сотни а значит глазами их никто не читает. Обычный вариант как я пользуюсь командой:
git tag | grep vМеханизм тегов решает именно ту задачу о которой вы пишетеОн решает ее криво (ветка не просто скрыта, ее вообще нет), с побочками в виде мусорных тегов, и это просто неудобно. При этом в истории все равно образуются холмы (пример из интернета) из коммитов «закрытых» веток.
нельзя комитить в него без явного переоткрытияПочему нельзя? Чекаут по имени тега, внес изменения, закоммитил. Фактически все работает, просто наш тег выполняющий роль головы ветки не двигается на новый коммит, как раз потому что он тег, а не голова ветки. Т.е. мы просто поломали функционал ветки, а не реализовали ее закрытие.
Ничего не мешает создать некий префикс для имен таких тегов и фильтровать по нему.И как это сделать скажем в гитхабе/битбакките, чтобы посетитель репозитория зайдя в раздел релизов не видел там дохлых веток?
Он решает ее криво, с побочками в виде мусорных тегов, и это просто неудобно.
Чем мусорная закрытая ветка отличается от мусорного тега?
И как это сделать скажем в гитхабе/битбакките, чтобы посетитель репозитория зайдя в раздел релизов не видел там дохлых веток?
Ну это уже вопрос собственно к гитхабу и битбакету, если они не реализовали подобный функционал значит спрос на него небольшой. Это не проблемы гита как системы контроля версий как там гитхаб их отображает
Чем мусорная закрытая ветка отличается от мусорного тега?Тем что она не мусорная. Ее не видно там, где ее не должно быть видно, но при этом видно там, где мы ожидаем ее увидеть.
Ну это уже вопрос собственно к гитхабу и битбакету, если они не реализовали подобный функционал значит спрос на него небольшойА совсем не потому что гит на это не рассчитан, и теги нужны именно для тегов, да. Наверное оно со всеми фичами так, если еще нет — значит и не надо.
Тег это просто метка и постоянный указатель на коммит. За годы развития гита было множество вариантов их использовать. Наиболее популярный из тех что есть сейчас — это использовать теги для версионирования. Но при этом в самом гите на этот счет ничего не сказано и вы имеете все возможности использовать их так как вам удобно. Например в одном из наших workflow мы ставим несколько тегов на один коммит — один тег помечает комит как версию, а еще 2 тега на тот же коммит подписаны людьми ответственными за выпуск релиза и соответственно удостоверяют подписью их согласие на выпуск. Соответственно деплой prod окружения происходит при наличии 3-х тегов а не одного. Соответственно мы используем этот механизм так как это удобно нам. Поэтому я не понимаю почему вы считает что для хранения легаси веток их нельзя использовать только потому что Github не дает вам удобной UI для их просмотра
Сравнимого по функционалу бесплатного хостинга для чего угодно другого нет, КМК.
Так то hg значительно проще в использовании, чем git. И многим его с головой бы хватило. И при наличии бесплатного (для личного пользования) hghub с вебмордой — многи предпочли бы его.
И при наличии бесплатного (для личного пользования) hghub с вебмордой — многи предпочли бы его.Был же Bitbucket, аж с 2008 года. Но в 2011 он добавил поддержку git, а в этом году выпилит поддержку самого меркуриала.
Был же Bitbucket, аж с 2008 года
В 2016 году, судя по ссылкам из википедии, в Bitbucket пользователей (hg + git) было в 4 раза меньше, чем у github (git only).
Теперь возникает вопрос: почему git победил svn?думаю основная причина — децентрализация и не зависимость от сервера. Не знаю как сейчас, но в svn до версии 1.7 включительно, без доступа к серверу ты не мог ничего сохранить (закомитить). Т.е. едишь ты в поезде или где то на даче без инета — и все, приехали.
Лично я понял как — деревья используются для хранения данные об файлах их иерархическом положении в древе абстрактной файловой системы для корректного воссоздания структуры.
А по факту при коммите формируется, и храниться дельта изменений.
В противном случаи каждый коммит в файл исходного кода, размером в 1 Мб, должен будет порождать его копию (пусть даже и архивную). Чисто эмперическим путем можно увидеть:
- при первичном коммите файла в 1Мб = коммит имеет большой размер (более 1 Мб), т.к. коммит содержит дельту от "ничего" до 1Мб
- при следующем коммите (при изменении всего одного символа) мы получаем объем хранимых данных близкий по объему изменений.
В этой статье содержится еще меньше информации, чем в сотне других.
можно хотя бы 2-3, в которых описываются "кишки"?
Автор не увидит ваш комментарий здесь.
От меня: https://git-scm.com/doc
Там ещё упакованный формат хранения в директории objects/pack есть.
Разрешение конфликтов слияния — очень частая операция при работе даже двоих людей над одним и тем же кодом.
Когда ситуация разрастается до десятков и больше человек — как вариант решения, назначается ответственный за прием кода в мастер-ветку, он же и решает мерж-конфликты. Хотя это не единственный возможный сценарий решения этой проблемы.
Тогда при попытке слияния коммитов Васи и Юры возникнет конфликт слияния (мерж конфликт) и гит попросит решить, что из двух вариантов изменений файла нужно оставить, а что удалить (или же оставить всё).
Правильно. И получится нерабочий код. Юра трогал не только общий модуль. Вася поступил так же. И арбитр замучается выяснять, что можно слить, а чего нельзя. Это-то и беспокоит.
В большинстве случаев слияние тривиально.
В меньшинстве случаев либо Вася, либо Юра берут обновлёный код и делают те же самые изменения, которые делали ранее.
Ну и проверку получившегося кода никто не отменял.
Стоит добавить, что при таком варианте возможно попадание некачественного кода в основную ветку.
Это решается обязыванием проганять тесты перед пушем в мастер, и обязятельным ревью кода, без которого пуш в мастер невозможен.
Это снимает необходимость в супер-девелопере, который должен принимать изменения в основную ветку, и снижает нагрузку.
Еще добавлю что редко всё же бывают ситуации когда отдельные запросы на внесение кода в основную ветку проходят тесты успешно, но в конце дня суммарно может что-то поломаться. Ну и человек, занимающийся внесением проверенных тестами и просмотренных другими людьми изменений в основную ветку всё же нужен в данном сценарии.
https://m.habr.com/ru/post/75990/ — как-то так. Информацию по настройке можете пропустить.
в точку.
С таким переводом xkcd — спасибо, не надо. Почему "запомни", а не "запомнил"?
Кол-во файлов в 255 раз меньше? Как так?
От разкладывания по 255 папкам кол-во файлов уменьшается в 255 раз? Серьёзно?
В среднем в одной директории становится в 256 раз меньше файлов. Кстати, если файлов будет слишком много, то возможно дальнейшее распихивание по директориям: objects/aa/bb/... и т.д.
Цель такого мероприятия: уменьшить количество файлов в одной директории из-за проблем с масштабируемостью файловых систем.
От разкладывания по 255 папкам кол-во файлов уменьшается в 255 раз? Серьёзно?
Вопрос трактовки.
"количество файлов в папке" может означать количество файлов в папке как с учетом файлов во вложенных папках, так и без учета.
Регулярно встречаю как первое, так и второе в интерфейсе программ, всяких руководствах и книгах.
Если имеется ввиду первое, то оспариваемое утверждение неверно, если второе, то верно.
Если второе, то в папке objects нет ни одного файла и от 1 до 255 других папок 00-ff. То есть, оспариваемое утверждение неверно никогда.
"Этот маленький трюк", о последствиях которого спор, уменьшает количество файлов в папке /objects до количества вложенных папок (каждая из которых тоже файл). Если бы не трюк, то все файлы из подпапок валялись бы непосредственно в папке /objects.
Кстати, уменьшение количества файлов начинается не сразу. На начальном этапе в каждой подпапке получается по одному файлу, а потому никакого выигрыша нет.
Руководство по Git. Часть №1: все, что нужно знать про каталог .git