Комментарии 39
Гит отличная штука. За прогит — отдельное спасибо авторам. Здорово помог, когда начинал пользоваться git-ом
Я бы в ссылки еще добавил: githowto.com/ru
Спасибо за статью. И отдельное спасибо за иллюстрации.
Погубить историю в гите — это надо попотеть. :)
git reflog поможет заблудившимся. Главное — не усердствовать с git gc.
git reflog поможет заблудившимся. Главное — не усердствовать с git gc.
gitk --all
Отличная статья на помнимание указателей с отличными иллюстрациями, спасибо!
Для редактирования локальной истории (считаю это дело полезным, чтобы во внешнем репе была чисто и красиво) использую git rebase. В частности, для описанного примера со слиянием пары комитов в один удобен интерактивный rebase:
и далее в редакторе помечаем последний комит буквой s (squash). А вот git reset так давно не использовал, что успел забыть, зачем он нужен. Впрочем, картинка в посте вполне освежает память.
$ git rebase -i HEAD~2и далее в редакторе помечаем последний комит буквой s (squash). А вот git reset так давно не использовал, что успел забыть, зачем он нужен. Впрочем, картинка в посте вполне освежает память.
какие-то еще операции, кроме git reset влияют на ORIG_HEAD и что произойдет с веткой коммитов на который указывал ORIG_HEAD после того, как он изменится?
ORIG_HEAD появляется после так называемых «опасных» команда, к которым и относится
А ветка коммитов, на который указывал ORIG_HEAD никуда не девается — я на самом деле немного слукавил, сказав, что возможно потерять историю. Все «неоприходаванные» коммиты (читай — не принадлежащие ни одной ветке) можно выцепить командой
git reset с набором определённых флагов. А ветка коммитов, на который указывал ORIG_HEAD никуда не девается — я на самом деле немного слукавил, сказав, что возможно потерять историю. Все «неоприходаванные» коммиты (читай — не принадлежащие ни одной ветке) можно выцепить командой
git log --all, либо git reflog. git reflog, если в кратце, отражает историю движения указателя 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 (и не только сливать, но и переупорядочивать, менять комменты, выборочно удалять и прочее)
Я в свое время так и перешел с 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 это как tex, или vim — один и тот же результат получить несколькими путями. Это из-за гибкости. Из-за гибкости, кстати, и геморрой при первичном знакомстве. Отсюда формула — за гибкость приходится платить геморроем при обучении =) Зато если привынуть — можно горы сворачивать =) Мощны инструменты.
Наглядная справка по git: A Visual Git Reference (Русская версия)
Ссылка на русскую версию ведет на английскую, правильная ссылка: marklodato.github.com/visual-git-guide/index-ru.html
Как-то сложновато всё, имхо. А штуки типа detach HEAD производят впечатление текущей абстракции. Но сама статья супер, спасибо, теперь более или менее разобрался.
>> «master указывает на самый старший коммит в ветке под названием master „
>> “Вспомнить, что указатель master указывает на самый свеженький коммит.»
Так самый старший или самый младший?
>> “Вспомнить, что указатель master указывает на самый свеженький коммит.»
Так самый старший или самый младший?
Подскажите плз толковый git GUI. Сам всегда использую HG + TortoiseHg, но сейчас возникла необходимость работы с GitHub — после TortoiseHG хочется чего нибудь такого же удобного.
Используйте то, к чему привыкли, только Git+TortoiseGit
Еще есть нативный клиент GitHub
http://git-scm.com/downloads/guis
На мой взгляд, самый удачный — Tower.
P.S. Маленький совет: настройте себе удобную консоль и используете её. Все мои знакомые, которые пользуются разными git GUI, испытывают проблемы с каким-нибудь функционалом гита. Гит сделан для удобной работы в консоли, так что любой гуи — это ограничение.
На мой взгляд, самый удачный — Tower.
P.S. Маленький совет: настройте себе удобную консоль и используете её. Все мои знакомые, которые пользуются разными git GUI, испытывают проблемы с каким-нибудь функционалом гита. Гит сделан для удобной работы в консоли, так что любой гуи — это ограничение.
А как можно проделывать подобные вещи с bare репозиторием?
а bare-репозиторий ничем от «обычного» не отличается в этом плане. Но тут есть два тонких момента:
1) Если с этого репозитория никто ничего не брал и брать не планирует, т.е. с него не было сделано клонов, тогда можно гонять указатель по всей истории как вздумается. НО:
2) Если кто-то клонировал этот репозиторий, тогда откатывать нет никакого смысла, ибо когда тот, кто отклонировал, будет в него «пушить», то он всё равно восстановит этим действием откаченную историю. Для того, чтобы отменить тот или иной коммит в истории 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
%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-репозитории этим лучше не заниматься по указанной мною выше причине.Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Машина времени в git