Комментарии 23
Больше статей про гит, хороших и разных! Ловите +1.
+ еще странная вещь как заметки к комитам
Достаточно интересное чтиво на ночь. Спасибо.
Если честно, опередили. Хотел послезавтра где-то об этом же написать.
Про .git-овые файлы еще много интересного можно рассказать.
Например, что использование SHA для идентификации содержимого файлов и деревьев естественным образом исключает дублирование данных в репозитории. У git'а нет записи изменений как таковых — что произошло в конкретном commit'е определяется исходя из того, что контрольная сумма у файла (или директории) с данным именем поменялась, а если после commit'а появился один или больше файлов с той же sha, что и до коммита, то это копирование или перемещение. Все очень просто, но с таким подходом отследить переименование файла с одновременным изменением содержимого не получится. Если вам важно прослеживать историю изменений, придется переименовывать и изменять файл в разных коммитах. Кстати, если не ошибаюсь, данные нескольких репозиторий можно хранить совместно, что делает git еще более эффективным для больших проектов.
Еще можно написать как ставятся хуки, описать revwalk, сравнить аннотированые и обычные тэги, ну или алгоритмы вычисления истории изменений, diff, blame… Так что не сдерживайте себя ;)
Например, что использование SHA для идентификации содержимого файлов и деревьев естественным образом исключает дублирование данных в репозитории. У git'а нет записи изменений как таковых — что произошло в конкретном commit'е определяется исходя из того, что контрольная сумма у файла (или директории) с данным именем поменялась, а если после commit'а появился один или больше файлов с той же sha, что и до коммита, то это копирование или перемещение. Все очень просто, но с таким подходом отследить переименование файла с одновременным изменением содержимого не получится. Если вам важно прослеживать историю изменений, придется переименовывать и изменять файл в разных коммитах. Кстати, если не ошибаюсь, данные нескольких репозиторий можно хранить совместно, что делает git еще более эффективным для больших проектов.
Еще можно написать как ставятся хуки, описать revwalk, сравнить аннотированые и обычные тэги, ну или алгоритмы вычисления истории изменений, diff, blame… Так что не сдерживайте себя ;)
git умный, если файл изменился не сильно, он поймёт, что его переименовали. Естественно ему можно это подсказать командой git mv
Хранить много проектов в одном репозитории можно, но не рекомендуется. Это называется submodules. Работает не особо, так что лучше хранить в разных репозиториях, благо это ничего не стоит.
Хранить много проектов в одном репозитории можно, но не рекомендуется. Это называется submodules. Работает не особо, так что лучше хранить в разных репозиториях, благо это ничего не стоит.
По поводу git mv git wiki говорит что это полный аналог удаления файла и добавления с новым именем; хотя то что вы говорите про «если файл изменился не сильно, он поймёт» я уже несколько раз встречал в обсуждениях git'а — надо будет разобраться. Тут только надо понимать, поправьте, если я ошибаюсь, что ядру git'а это без разницы — git может дать полный snapshot в точке #N и в точке #N-1, а что конкретно произошло между этими моментами — это уже проблема интерпретации клиента или дополнительных утилит.
По поводу нескольких проектов в репозитории — согласен, я бы старался избегать. Зачем смешивать отслеживание изменений в нескольких несвязных проектах? Submodules — это все-таки больше «внешние» проекты, тоже не совсем то.
Я говорил про объединение данных репозиторий — кажется, это делается через .git/objects/info/alternates. Это не связано с подпроектами, скорее с оптимизацией крупных хранилищ исходного кода. Например, если вы хотите сделать свой github с поддержкой fork'ов и при этом реально копировать репозитории, то проблемы с местом на жестом диске будут вас преследовать в ночных кошмарах. В случае если папку objects можно расшарить между несколькими репозиториями, такой проблемы не будет. Очевидно, что практический интерес это представляет в основном крупным компаниям с множеством команд и продуктов, ну или хостерам кода типа github, bitbucket, kiln и т.д., но с точки зрения возможностей git'а, все же полезно знать.
По поводу нескольких проектов в репозитории — согласен, я бы старался избегать. Зачем смешивать отслеживание изменений в нескольких несвязных проектах? Submodules — это все-таки больше «внешние» проекты, тоже не совсем то.
Я говорил про объединение данных репозиторий — кажется, это делается через .git/objects/info/alternates. Это не связано с подпроектами, скорее с оптимизацией крупных хранилищ исходного кода. Например, если вы хотите сделать свой github с поддержкой fork'ов и при этом реально копировать репозитории, то проблемы с местом на жестом диске будут вас преследовать в ночных кошмарах. В случае если папку objects можно расшарить между несколькими репозиториями, такой проблемы не будет. Очевидно, что практический интерес это представляет в основном крупным компаниям с множеством команд и продуктов, ну или хостерам кода типа github, bitbucket, kiln и т.д., но с точки зрения возможностей git'а, все же полезно знать.
Вот только что закоммитил один зип архивчик с его перепаковкой и переименованием — git все распознал без дополнительных пинков и даже показал процент совпадения файлов, а вот если его переименовать и директорию сменить — уже сам не может, надо таки пинать.
идея хранения всех форков в одном репозитории весьма интересная, вполне может быть что именно для этих целей она и создавалась. потому как большая часть обьектов в .git/objects будут общими.
Что касается submodules, я с вами не соглашусь. Весьма бывает удобно вынести общий модуль для нескольких проектов в отдельный репозиторий. Например если над ними работают 2 разные комманды и основной проект будет хранить только ссылку на коммит с которым всё работает хорошо. Общий модуль обновился — ничего не поломалось. Когда нужны будут новые функции — обновили коммит в submodule протестировали, подпилили, то что отвалилось и уже стабильную связку закоммитили в репозиторий.
Или например есть 5 проектов с общим ядром. 3 проекта просто на поддержке, их лучше трогать чем реже тем лучше, только баги править. Еще 2 в активной разработке и под них в ядре делаются изменения. Общий submodule будет отличным решением в этой ситуации. Вобщем примеров можно много привести когда submodule жить помогает.
Что касается submodules, я с вами не соглашусь. Весьма бывает удобно вынести общий модуль для нескольких проектов в отдельный репозиторий. Например если над ними работают 2 разные комманды и основной проект будет хранить только ссылку на коммит с которым всё работает хорошо. Общий модуль обновился — ничего не поломалось. Когда нужны будут новые функции — обновили коммит в submodule протестировали, подпилили, то что отвалилось и уже стабильную связку закоммитили в репозиторий.
Или например есть 5 проектов с общим ядром. 3 проекта просто на поддержке, их лучше трогать чем реже тем лучше, только баги править. Еще 2 в активной разработке и под них в ядре делаются изменения. Общий submodule будет отличным решением в этой ситуации. Вобщем примеров можно много привести когда submodule жить помогает.
Ок. Попытаюсь раскрыть тему подробнее. Спасибо. :)
Цикл статей на эту тему: Git guts (на русском).
То же самое одним большим постом: Git guts all-in-one
То же самое одним большим постом: Git guts all-in-one
А зачем вам знать как работает Git?
Имею ввиду, что уже не в первый раз натыкаюсь на такие статьи-раскопки Git, но ни разу не видел подобного про Svn и остальные SCM-системы.
Академический интерес?
Академический интерес?
Интересно, как там всё внутри устроено.
Лично мне удобней знать все о том, чем я пользуюсь (в разумных количествах, конечно). Становятся более понятны принципы работы и возможности системы. Всегда проще понять как работает, чем запоминать, как ею пользоваться.
НЛО прилетело и опубликовало эту надпись здесь
А ещё бывают packed-refs, object/pack — собранные в один файл несколько ссылок, объектов.
Как Mercurial устроен внутри вот тут неплохо написано www.aosabook.org/en/mercurial.html
Проект по переводу этой книги на русский: code.google.com/p/aosa-ru
Картинки приказали долго жить.
Что такое «git co»?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что скрывает от нас директория .git