23.06.2009 04:23
lwilis — Git - что нужно для начала?
Немного расскажу про систему контроля версий git. Базой этой заметки служат обе части gittutorial, man gitignore, man git-update-index, man git-reset. Заметка подойдет для быстрого старта. Пригодится для контроля изменений в /etc.Система контроля версий полезна для документирования изменений в конфигурации вашей ОС. Во-первых, появляется возможность проводить эксперименты при конфиругировании, имея возможность вернуться к заведомо рабочим параметрам. Во-вторых, проще клонировать действительно нужные параметры, если завести несколько веток в репозитарии, - две (основная и экспериментальная) для PC и две для нетбука.
Ветка (branch) - это одна из версий состояния файлов в каталоге вашего проекта
Документирование строится путем осуществления commit`ов в ветку.
Commit - это способ регистрации изменения в одном или нескольких файлах проекта. Здесь нужно заметить, что после внесения изменений в файл или создания нового файла, необходимо добавить файл в репозитарий. И после добавления можно создать commit, то есть зафиксировать изменение и дать ему описание.
Внутри репозитарий git представляет из себя каталог .git, расположенный в каталоге проекта. В .git лежат как служебные файлы, так и наши рабочие данные. Рабочие данные находятся в каталоге .git/objects. Углубляться в устройство git здесь не буду, но в конце заметки будет ссылка именно по внутренностям git.
Для начала рекомендую потренироваться "на кошках", поэтому сразу в /etc не полезем.
Поехали.
1 |
$ mkdir ~/test && cd ~/test
|
Но, сразу после начала знакомства с git мне потребовалось смотреть на прогресс и состояние репозитарияотменить слежение за изменениями в некоторых файлахнекоторые файлы я не хотел добавлять в репозитарий, и хотел, чтобы git их игнорировалмне нужно было откатывать свои изменения
Продолжим.
1 |
$ git branch #Убедимся, что находимся экспериментальной ветке
|
1 |
$ git log
|
На этом, пожалуй, закончу. Если будет интересно, то тему слияния веток, сравнение состояния файлов в разных ветках и что-нибудь еще рассмотрю в следующий раз.
внутренности git
трудно сказать. Большие дядьки используют для контроля кода ядра, а мне пригодилась для наведения порядка в /etc - масштабы, прямо скажем, диаметрально противоположные.
И да, я полагаю, что от новичка я тоже не сильно отличаюсь.
А заметку делал для тех, кто уже что-то слышал и хочет попробовать, но "не подступиться"
И да, я полагаю, что от новичка я тоже не сильно отличаюсь.
А заметку делал для тех, кто уже что-то слышал и хочет попробовать, но "не подступиться"
Тоже не так давно взялся за гит.
Может, стоит осветить такое:
1)Застрял по началу на вопросе: http или ssh? Выбрал оба. =)
2)Клиенты. Для виндузей-то нашёл черепашку, как и для свинки, под макось - gitx
Может, стоит осветить такое:
1)Застрял по началу на вопросе: http или ssh? Выбрал оба. =)
2)Клиенты. Для виндузей-то нашёл черепашку, как и для свинки, под макось - gitx
да, я помню ты в жуйке отписывался на эту тему ;)
Пока что не обещаю ответов на эти вопросы
Пока что не обещаю ответов на эти вопросы
//случайно отправил. Удалить/редактировать нельзя?
А для себя что-то ничего подобного eSvn найти не могу. Консоль решает!
3)веб-морды для управления. Как по мне, так и gitosis отличное средство, но вот для других...
А для себя что-то ничего подобного eSvn найти не могу. Консоль решает!
3)веб-морды для управления. Как по мне, так и gitosis отличное средство, но вот для других...
Сам пользуюсь SVN, посматриваю на git, готовлюсь :)
Статья как раз в тему, типовые случаи описаны. За это спасибо.
Увидел интересное отличие: в SVN коммит подразумевает, что надо забрать все изменённые файлы, а в GIT, как я понял, надо явно помечать, что войдёт в коммит или писать опцию -a. Тут при переходе предвижу наступание на грабли несколько раз, пока новые рефлекс не выработается :)
Статья как раз в тему, типовые случаи описаны. За это спасибо.
Увидел интересное отличие: в SVN коммит подразумевает, что надо забрать все изменённые файлы, а в GIT, как я понял, надо явно помечать, что войдёт в коммит или писать опцию -a. Тут при переходе предвижу наступание на грабли несколько раз, пока новые рефлекс не выработается :)
Рад, что заметка в тему.
Пока разбирался с git, натыкался на статьи в стиле "как переехать с svn на git", но пропускал их, чтоб голову не морочить. Ну не пользовался я раньше VCS.
Тем не менее главное отличие от svn в том, что git - распределенная (DVCS). Поэтому работать можно не подключаясь "главному" репозитрарию (в кавычках, потому что как такового главного нет, все репы равноценны, просто можно договориться, какой реп считать главным), а следовательно "забирание" нужно делать перед коммитом в "главный". То есть сначала кодим и коммитим у себя, потом забираем из главного репа, разруливаем конфликты, коммитим в главный.
Пока разбирался с git, натыкался на статьи в стиле "как переехать с svn на git", но пропускал их, чтоб голову не морочить. Ну не пользовался я раньше VCS.
Тем не менее главное отличие от svn в том, что git - распределенная (DVCS). Поэтому работать можно не подключаясь "главному" репозитрарию (в кавычках, потому что как такового главного нет, все репы равноценны, просто можно договориться, какой реп считать главным), а следовательно "забирание" нужно делать перед коммитом в "главный". То есть сначала кодим и коммитим у себя, потом забираем из главного репа, разруливаем конфликты, коммитим в главный.
А по-моему более важное отличие - поддержка бранчей и аккуратный merge.
И такая штука, как отложенные коммиты тже полезно для нескольких разработчиков.
В свинке такого очень не хватает. А привыкать придётся долго.
Короче, есть резон посмотреть на git после свинки. Но переносить проекты с свн на гит особого резона нет.
И такая штука, как отложенные коммиты тже полезно для нескольких разработчиков.
В свинке такого очень не хватает. А привыкать придётся долго.
Короче, есть резон посмотреть на git после свинки. Но переносить проекты с свн на гит особого резона нет.
По мне так главный плюс гиты -- это как раз его локальность, помимо прочего конечно. Часто возникали задачи, когда хотелось локальную версионность без лишних заморочек с поднятием репозитария, его ведением и т.п. Гита как раз для этого очень подходит.
Увидел интересное отличие: в SVN коммит подразумевает, что надо забрать все изменённые файлы...
По умолчанию - всё. По желанию - нужное
Отличная статья!
Как раз в тему для тех кто знает и любит консоль, другие системы контроля версий (svn, cvs) и подумывает переходить на git.
Тут наверное одни из самых типичных случаев преведены, мне очень понравилось это руководство, спасибо :)
Как раз в тему для тех кто знает и любит консоль, другие системы контроля версий (svn, cvs) и подумывает переходить на git.
Тут наверное одни из самых типичных случаев преведены, мне очень понравилось это руководство, спасибо :)
Спасибо, познавательно.
А можешь сказать пару слов о git в сравнении с hg?
А можешь сказать пару слов о git в сравнении с hg?
а объективные причины выбора git, а не hg имеют место быть?
или все получилось спонтанно?
или все получилось спонтанно?
Не то чтоб спонтанно, просто решил попробовать git или Mercurial, начал с git - он мне так понравился, что mercurial я даже смотреть не стал.
А про существование hg я узнал уже после чтения манов git`а.
А про существование hg я узнал уже после чтения манов git`а.
Мои впечатления: hg интуитивно понятней, намного удобней настройка(как веб-обёртка репа, так и сам реп и личный конфиг юзера/хотя с последними двумя - спорно/)
В hg присутствует какая-то абстрактная нумерация коммитов
Много раз пытался перелезть на гит - не вышло. С hg как-то работать приятней.
Бытует мнение, что, в отличие от других DVCS, гит переполнен фичами. Но тот же mercurial поддерживает расширения(ибо питон )), которые реализуют самые нужные вещи, отсутствующие в ядре, и реализуют с учётом опыта их использования в гите. Некоторые включаются в базовую поставку системы.
Git позволяет редактировать любой элемент дерева коммитов, mercurial разрешает отменить лишь последний коммит. Хотя здесь я не уверен, что всё именно так, как кажется.
В hg присутствует какая-то абстрактная нумерация коммитов
Много раз пытался перелезть на гит - не вышло. С hg как-то работать приятней.
Бытует мнение, что, в отличие от других DVCS, гит переполнен фичами. Но тот же mercurial поддерживает расширения(ибо питон )), которые реализуют самые нужные вещи, отсутствующие в ядре, и реализуют с учётом опыта их использования в гите. Некоторые включаются в базовую поставку системы.
Git позволяет редактировать любой элемент дерева коммитов, mercurial разрешает отменить лишь последний коммит. Хотя здесь я не уверен, что всё именно так, как кажется.
несмотря на небольшой опыт - уже несколько раз столкнулся с невозможностью hg слить больше двух веток за раз. вроде бы не очень существенно, но не айс.
Вот хорошая ссылка. Даже не знаю, что делает hg ярче гита - сама статья или комментарии )
http://alexlebedev.com/blog/mercurial-flying-fine/
http://alexlebedev.com/blog/mercurial-flying-fine/
скриншот актуальный) я такое тоже уже видел
гит подобные штуки не вытворяет?
гит подобные штуки не вытворяет?
Конечно вытворяет. Там же ниже написано, что это просто результат ошибки участника проекта, который с непривычки при коммите промахнулся с бранчем. Другое дло, что в гите ка-кто реализована правка истории. Хотя сомневаюсь, что можно менять саму структуру дерева.
Перевод с translated.by:
Перевод с translated.by:
Git предоставляет большой список команд, число которых в версии 1.5.0 достигает 139 уникальных единиц. Он имеет репутацию инструмента, сложного для изучения. В сравнении с Git, Mercurial делает упор на простоту.
Что касается производительности — Git очень быстр. В некоторых случаях он быстрее, чем Mercurial (по крайней мере под Linux), а в других быстрее оказывается Mercurial. Однако под Windows как производительность, так и общий уровень поддержки, во время написания этой книги у Git гораздо хуже, чем у Mercurial.
В то время как репозиторий Mercurial не требует операций по техническому обслуживанию, репозиторий Git требует частых ручных "перепаковок" собственных метаданных. Если этого не делать, производительность начинает падать, наряду с увеличением объёма занимаемого дискового пространства. Дисковый массив сервера, содержащего несколько Git репозиториев, по отношению к которым не выполняется строгое правило частой "перепаковки", рано или поздно забивается под завязку, в результате чего процесс ежедневного резервного копирования легко может занимать более 24 часов. Только что "запакованный" репозиторий Git занимает немного меньше места, чем репозиторий Mercurial, но объём не перепакованного репозитория будет на несколько порядков больше.
Ядро Git написано на языке С. Многие команды Git реализованы в виде Shell скриптов или скриптов на языке Perl и уровень качества данных скриптов сильно разнится. Я встречал несколько установок, в которых скрипты тупо продолжали выполнение, несмотря на наличие фатальных ошибок.
Mercurial предоставляет возможность импорта истории версий из репозитория Git.
есть rebase - эта команда позволяет полностью переделать ветку, вынести несколько коммитов в другую ветку. Подробности пока что сам не знаю
Основной довод в пользу git - можно работать с ветками в одной директории, в то время как в Mercurial и остальных системах это делается в клонированных репозиториях
по моему для hg был плагин реализующий такую возможность
или я что то путаю?
или я что то путаю?
http://www.selenic.com/mercurial/wiki/MqExtension
Вот нашёл. Наиприятнейшая штука :)
Вот нашёл. Наиприятнейшая штука :)
оффтоп: по моему подстветка синтаксиса как то лажает, нет? я кроме циферок слева - никакой "подстветки" не вижу
оффтоп x2: она *подсветка* тоже самописная?
оффтоп x2: она *подсветка* тоже самописная?
что нибудь такое не хотите?
http://alexgorbatchev.com/wiki/SyntaxHighlighter
http://alexgorbatchev.com/wiki/SyntaxHighlighter
все равно куцо как то выглядит (:
хотя это наверное уже не проблема хайлайтера
хотя это наверное уже не проблема хайлайтера
Подсветка не самописная. Название на Г начинается. Что-то вроде ~ Geshi
кстати если кому интересно - могу написать аналогичную статью про hg (:
Мне например оно не нужно.
А чем новичёк отличается от меня?