Страницы

19 июля 2013 г.

Все, что вы хотели узнать про Git, но боялись спросить. Часть 2. История.


Вот какую картинку я нашел на просторах Интернета. Мне кажется, она как нельзя лучше подходит для этого поста. На самом деле, на ней отображен лишь один из подходов к организации процесса работы с Git-репозиторием. Но об этом позже. А сейчас давайте поговорим о том, как же Git ведет историю проекта, и чем это хорошо для нас.

Но вначале, предлагаю вам детальней разобраться коммитами. Мы вскользь знакомились с этим понятием в предыдущей статье и уже знаем, что коммит создается, когда есть необходимость внести изменения в проект. Но что же это такое? Не вдаваясь в лишние детали, можно сказать, что коммит состоит из двух важных частей: указателя на конкретное состояние проекта и указателей на ноль или более родительских коммитов. Последняя часть служит ключевым элементом в формировании истории Git-проекта.


Историю репозитория в Git можно представить в виде ориентированного графа, где вершинами являются коммиты, а ребрами - связи между ними.


Вот, пожалуйста, старался, рисовал.
Красные точки - коммиты, стрелки - указатели.




Таким образом, используя связи между коммитами, можно свободно перемещаться по истории.
Кроме того, Git предоставляет нам возможность использовать указатели на определенные коммиты, для упрощения взаимодействия с репозиторием. (Да, и тут указатели. Черт побери, они везде. Постарайтесь не запутаться :) Их можно поделить на три группы: локальные ветки, удаленные ветки и тэги.
Что такое ветка? С точки зрения Git, это просто указатель на конкретный коммит, но учитывая однонаправленность связи между коммитами, ветки становятся для нас удобным инструментом.
Что я имею ввиду? Думаю, будет понятней показать на картинке:

 Как видите, у нас есть ветка some_branch, указатель на определенный коммит в верхней части графа. Следуя по стрелкам, можно отследить всю историю для этого коммита (подсвечена красным). Вот, как выглядят ветки с точки зрения разработчика.

Теперь, чем отличаются локальные ветки от удаленных. Тут все просто - локальные находятся в вашем репозитории на вашей машине, удаленные - на далеком-далеком сервере где-то в глубинах Интернета. (Или на машине соседа, не суть, главное, что не на вашей :)

Тэги похожи на ветки в том смысле, что они тоже указывают на определенный коммит. Разница в том, что тэг присваивается коммиту один раз и навсегда, в то время, как указатели веток можно передвигать, как вам вздумается.

Среди вышеупомянутых указателей хотелось бы выделить один специфический. Имя ему HEAD. Когда вы переключаетесь с ветки на ветку, каким-либо образом манипулируете историей, либо создаете новый тэг - HEAD всегда следует за вами и всегда указывает на последний коммит в текущей версии репозитория.

Ну, хватит теории, перейдем к практике. Во-первых, для любых операций с историей Git, было бы неплохо увидеть ее воочию. Кстати, я стянул проект Bootstrap с github.com, чтобы мои примеры были более наглядными.
Давайте выполним команду git log.



































Согласен, много текста. Присмотритесь внимательней, и вы увидите много полезной информации. В частности, нам доступен хэш коммита, имя + email автора, дата и время создания, а также описание коммита. Но не слишком понятно, как они друг с другом связаны.
Увидеть связи можно добавив параметр --graph к git log



































Намного лучше, теперь мы видим, как коммиты связаны между собой. Если хотите увидеть больше коммитов и только краткую инфомацию о них, вам поможет параметр --oneline.


































Как видите, опущена вся информация, кроме краткого хэша коммита и его описания. Зато, на экран помещается намного больше истории.

Эти два параметра (плюс еще параметр --stat), пожалуй, самые частоупотребляемые в повседневной работе. Конечно, git log содержит намного больше функций, причем их перечисление заслуживает отдельной статьи (а то и нескольких), но, честно говоря, они редко бывают полезны. Если интересно, посмотрите справку.

Просмотр истории - одна из немногих операций, для которых удобней использовать графические оболочки. Причина проста - они могут отобразить больше информации одновременно, плюс - есть поиск(и не надо помнить эту кучу параметров для git log:). Я использую GitExtensions или SmartGit - обе хороши. Но не дайте им заманить себя, ведь консоль это наше все. Воспринимайте их как просмотрщик лога, не более :)

На этом, пожалуй, и закончим ознакомление с историей, не хочу слишком перегружать статью. Я убежден, что небольшими порциями информация усваивается лучше. Что касается следующей части, в ней мы узнаем, как перемещаться по истории. Возможно, также затронем операции с ветками и тэгами. Зависит от того, на сколько многословна будет моя муза в следующий раз :)

Любые вопросы/пожелания/замечания - буду рад ответить в комментариях.

Комментариев нет:

Отправить комментарий