Как стать автором
Обновить

Комментарии 39

Гит отличная штука. За прогит — отдельное спасибо авторам. Здорово помог, когда начинал пользоваться git-ом
Да, книга великолепна. После прочтения появляетя не просто набор интрукция и workflow, а понимание механизмов работы git'а.
Спасибо за совет. Раньше не знал этого ресурса. Возьму на заметку.
Спасибо за статью. И отдельное спасибо за иллюстрации.
Пожалуйста =) я эти картинки сперва рисовал на бумаге, объясняя коллегам команды, затем надоело — решил написать статью и кидать ссылку.
Погубить историю в гите — это надо попотеть. :)
git reflog поможет заблудившимся. Главное — не усердствовать с git gc.
Отличная статья на помнимание указателей с отличными иллюстрациями, спасибо!
Для редактирования локальной истории (считаю это дело полезным, чтобы во внешнем репе была чисто и красиво) использую git rebase. В частности, для описанного примера со слиянием пары комитов в один удобен интерактивный rebase:

$ git rebase -i HEAD~2

и далее в редакторе помечаем последний комит буквой s (squash). А вот git reset так давно не использовал, что успел забыть, зачем он нужен. Впрочем, картинка в посте вполне освежает память.
какие-то еще операции, кроме git reset влияют на ORIG_HEAD и что произойдет с веткой коммитов на который указывал ORIG_HEAD после того, как он изменится?
ORIG_HEAD появляется после так называемых «опасных» команда, к которым и относится git reset с набором определённых флагов.
А ветка коммитов, на который указывал ORIG_HEAD никуда не девается — я на самом деле немного слукавил, сказав, что возможно потерять историю. Все «неоприходаванные» коммиты (читай — не принадлежащие ни одной ветке) можно выцепить командой git log --all, либо git reflog. git reflog, если в кратце, отражает историю движения указателя HEAD. Обладая этой информацией вполне можно восстановить «потерянные» коммиты, но, если честно, извините, слегка геморрой. Лучше этого избегать.
Как Я понимаю это все меняет только указатели, но не сами файлы? или Я запутался?
Да, Вы запутались. Со сменой указателей (а конкретно — указателя HEAD) меняется и состояние файлов (за исключением git reset --soft). Файлы приобретают то состояние, куда указывает HEAD. Это важный и немного странный на первый взгляд момент, который обычно и вводит в заблуждение новичков.
Из всех этих howto я понял, что git — такая штука, на изучение которой придется потратить приличное время. Нельзя просто так взять и начать использовать git.
Можно начать использовать GIT в «визуальном режиме» в любимой IDE, а потом уже разбираться с нюансами и доп.возможностями. Это будет лучше, чем вообще не начинать.
Как раз начать использовать можно сразу и довольно просто.
Я в свое время так и перешел с svn на git когда в очередном проекте все на него перевели.
В гите конечно куча функций, но их вас никто не обязывает изучать. И вы можете вполне пользоваться базовой функциональностью, не задумываясь про остальное.
Например, я регулярно пользуюсь git rebase для слияниея коммитов перез отправкой их на публичный репо.
А у этой команды есть опция --onto про которую я знаю из мануалов, но никак не могу запомнить что она делает, т.к. она мне ни разу не нужна была. Что говорить про остальные опции о которых я вообще не подозреваю :)
И ничего — живу :)

Кстати из описанных команд, для новичков я считаю нужно знать только
git checkout ветка (переключиться на ветку)
git checkout -b ветка (создать ветку из текущей и переключиться)
git reset --hard (отменить все незакоммиченное)
git reset --hard HEAD~n (отменить все незакоммиченное и откатиться на n коммитов)

А git reset --soft это честно говоря уже из разряда извращений, тем более пример приведенный для этой опции надуманный, гораздо проще и надежнее сливать коммиты через git rebase -i HEAD~n (и не только сливать, но и переупорядочивать, менять комменты, выборочно удалять и прочее)

Вместо git reset --hard отмену можно делать с помощью «git stash», «git stash apply» делать никто не обязывает :-)
Можно.
Только зачем замусоривать репо файлами которые не нужны?
stash предназначена для совсем другого — для сохранения, а не удаления.
Замусоривание минимальное, да и перетирается в следующий раз. Я не говорю что это оптимальный путь, просто как вариант.
Что значит «перетирается в следующий раз»? Хранилище у stash организовано на основе стека. И при очередном git stash мы добавляем в стек новое состояние. И если не чистить stash, то стек будет только расти.
Не стек, а лог.
git это как tex, или vim — один и тот же результат получить несколькими путями. Это из-за гибкости. Из-за гибкости, кстати, и геморрой при первичном знакомстве. Отсюда формула — за гибкость приходится платить геморроем при обучении =) Зато если привынуть — можно горы сворачивать =) Мощны инструменты.
Спасибо, поправил.
Как-то сложновато всё, имхо. А штуки типа detach HEAD производят впечатление текущей абстракции. Но сама статья супер, спасибо, теперь более или менее разобрался.
>> «master указывает на самый старший коммит в ветке под названием master „
>> “Вспомнить, что указатель master указывает на самый свеженький коммит.»

Так самый старший или самый младший?
гм, великий и могучий русский язык. С одной стороны Вы правы, безусловно. Но вот с другой стороны — более старший коммит — более старшая ревизия по номеру, а не по возрасту =) вот такая вот дилемма
Подскажите плз толковый git GUI. Сам всегда использую HG + TortoiseHg, но сейчас возникла необходимость работы с GitHub — после TortoiseHG хочется чего нибудь такого же удобного.
Используйте то, к чему привыкли, только Git+TortoiseGit
попробовал… к моему сожалению tortoiseHg и tortoiseGit схожи только префиксом «tortoise» — очень странно что при практически одинаковой функциональности Git и Hg, эти tortoise клиенты так сильно отличаются.
Еще есть нативный клиент GitHub
Извините, но это не GUI клиент, а какое-то гламурное убожество… самый базовый набор команд завернутый в неюзабельный интерфейс.
http://git-scm.com/downloads/guis
На мой взгляд, самый удачный — Tower.

P.S. Маленький совет: настройте себе удобную консоль и используете её. Все мои знакомые, которые пользуются разными git GUI, испытывают проблемы с каким-нибудь функционалом гита. Гит сделан для удобной работы в консоли, так что любой гуи — это ограничение.
А как можно проделывать подобные вещи с bare репозиторием?
а bare-репозиторий ничем от «обычного» не отличается в этом плане. Но тут есть два тонких момента:
1) Если с этого репозитория никто ничего не брал и брать не планирует, т.е. с него не было сделано клонов, тогда можно гонять указатель по всей истории как вздумается. НО:
2) Если кто-то клонировал этот репозиторий, тогда откатывать нет никакого смысла, ибо когда тот, кто отклонировал, будет в него «пушить», то он всё равно восстановит этим действием откаченную историю. Для того, чтобы отменить тот или иной коммит в истории bare-репозитория необходимо породить новый коммит. Обычно для этого используют git revert

я надеюсь правильно понял Ваш вопрос.
я о том, что bare репозиторий вроде как не воспринимает прямые команды
%mkdir temp
%cd temp
%git init --bare
Initialized empty Git repository in /www/github/data/temp/
%git status
fatal: This operation must be run in a work tree
Как я понимаю, git status обращается к файлам, находящимся под контролем. В bare-репозитории их, естесственно нет — там только так называемые snapshots файловой системы. К файлам обращается и git checkout и git reset --hard, но git reset --soft спокойно двигает веточку, так как результат этой операции лишь изменение значений указателей, а не самой файловой системы. Но опять же повторю, в bare-репозитории этим лучше не заниматься по указанной мною выше причине.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории