Магия Git Магия Git iicollaborators
 Скачать 309.22 Kb.
|
Магия Git i Магия Git Магия Git ii COLLABORATORS TITLE : Магия Git ACTION NAME DATE SIGNATURE WRITTEN BY Ben Lynn Август 2007 REVISION HISTORY NUMBER DATE DESCRIPTION NAME Август 2007 BL Магия Git iii Оглавление 1 Предисловие 1 1.1 Благодарности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Лицензия 2 2 Базовые операции 3 2.1 Сохранение состояния . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1 Добавление, удаление, переименование . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Расширенная отмена/Восстановление . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1 Возвраты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Создание списка изменений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 Скачивание файлов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5 На острие ножа 5 2.6 Публичный доступ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.7 Что я наделал? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.8 Упражнение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 Все о клонировании 8 3.1 Синхронизация компьютеров . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Классический контроль исходного кода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Создание форка проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.4 Окончательные бэкапы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5 Многозадачность со скоростью света . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6 Другие системы контроля версий . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4 Чудеса ветвления 11 4.1 Кнопка босса . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2 Грязная работа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3 Быстрые исправления . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4 Бесперебойный рабочий процесс . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.5 Собрать все в кучу . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6 Управление Ветками . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.7 Временные Ветки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.8 Работайте как вам нравится 15 Магия Git iv 5 Уроки истории 16 5.1 Оставаясь корректным . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2 …И кое-что еще . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3 Локальные изменения сохраняются . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4 Переписывая историю . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.5 Создавая Историю . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.6 Когда же все пошло не так? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.7 Из-за кого все пошло наперекосяк? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.8 Личный опыт . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6 Групповая работа в Git 21 6.1 Кто я? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2 Git через SSH, HTTP 21 6.3 Git через что угодно . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.4 Патчи: Общее применения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.5 К сожалению, мы переехали . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.6 Удаленные Ветки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.7 Несколько Удаленных Веток . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.8 Мои Настройки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7 Гроссмейстерство Git 26 7.1 Релизы исходников . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.2 Сохранение изменений . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.3 Слишком большой коммит 27 7.3.1 Этапные изменения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.4 Не теряй HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.5 Охота за HEAD'ами . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.6 Git как основа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.7 Опасные трюки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.8 Улучшаем свой публичный образ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 8 Раскрываем тайны 32 8.1 Невидимость . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.2 Целостность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.3 Интеллект . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.4 Индексация . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.5 Голые репозитории . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.6 Происхождение Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.7 База данных объектов 33 8.7.1 Blobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.7.2 Деревья . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.7.3 Коммиты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.7.4 Неотличимо от магии . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Магия Git v 9 Недостатки Git 37 9.1 Недостатки SHA1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.2 Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.3 Несвязанные файлы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 9.4 Кто и что редактировал ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.5 История файлов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.6 Начальное Клонирование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.7 Изменчивые Проекты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.8 Глобальный счетчик . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 9.9 Пустые подкаталоги 39 9.10Первоначальный коммит 39 10 Приложение А: Перевод этого руководства 41 Магия Git vi Введение Я буду использовать аналогии, чтобы объяснить, что такое контроль версий. Если вам нужно более точное объяснение, обратитесь к статье википедии Работа - это игра Я играл в компьютерные игры почти всю свою жизнь. А вот использовать системы контроля версий я начал уже будучи взрослым. Подозреваю, что я не один такой, и сравнение этих двух занятий может помочь объяснению и пониманию их концепций. Представьте, что редактирование кода, документа или чего-либо еще — игра. Далеко продвинув- шись, вы захотите сохраниться. Чтобы сделать это, вы нажмете на кнопку "Сохранить" в вашем любимом редакторе. Но это перезапишет старую версию. Это как в древних играх, где был только один слот для со- хранения: вы можете сохраниться, но вы никогда не сможете вернуться к прежнему состоянию. Что досадно, так как одно из прежних сохранений может указывать на одно из очень интерес- ных мест в игре, и, может быть, однажды вы захотите вернуться к нему. Или, что еще хуже, вы сейчас находитесь в безвыигрышном состоянии и вынуждены начинать заново. Контроль версий Во время редактирования вы можете "Сохранить как …" в другой файл, или скопировать файл куда-нибудь перед сохранением, чтобы уберечь более старые версии. Может быть и заархивиро- вав их для сохранения места на диске. Это самый примитивный вид контроля версий, к тому же требующий интенсивной ручной работы. Компьютерные игры прошли этот этап давным-давно, в большинстве из них есть множество слотов для сохранения с автоматическими временными метками. Давайте усложним условия. Пусть у вас есть несколько файлов, используемых вместе, например, исходный код проекта или файлы для вебсайта. Теперь, чтобы сохранить старую версию, вы должны скопировать весь каталог. Поддерживать множество таких версий вручную неудобно, и быстро становится дорогим удовольствием. В некоторых играх сохранение — это и есть каталог с кучей файлов внутри. Эти игры скрывают детали от игрока и предоставляют удобный интерфейс для управления различными версиям этого каталога. В системах контроля версий всё точно так же. У них у всех есть приятный интерфейс для управ- ления каталогом, полным-полно всяких данных. Вы можете сохранять состояние каталога так часто, как пожелаете, и вы можете восстановить любую из предыдущих сохраненных версий. Но, в отличие от компьютерных игр, они умнее используют дисковое пространство. Обычно только несколько файлов меняется от версии к версии, не более. Сохранение различий, а не всей копии каталога, не так сильно расходует свободное место. Магия Git vii Распределенный контроль А теперь представьте очень сложную компьютерную игру. Её настолько сложно пройти, что множество опытных игроков по всему миру решили объединиться и использовать общие сохра- нения, чтобы попытаться выиграть. Прохождения на скорость — живой пример. Игроки, специ- ализирующиеся на разных уровнях игры, объединяются, чтобы в итоге получить потрясающий результат. Как бы вы организовали такую систему, чтобы игроки смогли легко забирать сохранения других? А загружать свои? Раньше каждый проект использовал централизованную систему контроля версий. Какой-нибудь сервер хранил все сохраненные игры. И никто больше. На машине каждого игрока хранилась только очень маленькая часть. Когда игрок хотел пройти немного дальше, он выкачивал самое последнее сохранение с сервера, играл немного, сохранялся и закачивал уже свое сохранение обратно на сервер, чтобы кто-нибудь другой смог его использовать. А что, если игрок по какой-то причине захотел использовать более старую сохраненную игру? Возможно, текущая версия сохраненной игры безвыигрышна, потому что кто-то из игроков за- был взять какой-либо игровой предмет на каком-то предыдущем уровне, и они хотят найти по- следнюю сохраненную игру, которая все еще выигрышна. Или, может быть, они хотят сравнить две более старые сохраненные игры, чтобы установить вклад каждого игрока. Может быть много причин вернуться к более старой версии, но выход один. Они должны за- просить центральный сервер о той старой сохраненной игре. Чем больше сохраненных игр они захотят, тем больше им понадобится связываться с сервером. Новое поколение систем контроля версий, к которым относится Git, известны как распределен- ные системы, их можно понимать как обобщение централизованных систем. Когда игроки загру- жаются с главного сервера, они получают каждую сохраненную игру, а не только последнюю. Это как если они зеркалируют центральный сервер. Эти первоначальные операции клонирования могут быть интенсивными, особенно если при- сутствует длинная история разработки, но это сполна окупается при длительной работе. Од- на немедленная выгода состоит в том, что если по какой-то причине потребуется более старая версия, дополнительное обращение к серверу не понадобится. Глупые предрассудки Широко распространенное заблуждение состоит в том, что распределенные системы непригод- ны для проектов, требующих официального централизованного репозитория. Ничто не может быть более далеким от истины. Получение фотоснимка не приводит к тому, что мы крадем чью- то душу. Проще говоря, клонирование главного репозитория не уменьшает его важность. В первом приближении можно сказать, что все, что делает централизованная система контро- ля версий, хорошо сконструированная распределенная система может сделать лучше. Сетевые ресурсы просто дороже локальных. Хотя дальше мы увидим, что в распределенном подходе есть свои недостатки, менее вероятно провести ложные аналогии руководствуясь этим приближен- ным правилом. Небольшому проекту может понадобиться лишь часть функций, предлагаемых такой системой. Но будете ли вы использовать римские цифры в расчетах с небольшими числами? Более того, ваш проект может вырасти за пределы ваших первоначальных ожиданий. Использовать Git с самого начала — это как держать наготове швейцарский армейский нож, даже если вы только открываете им бутылки. Однажды вам безумно понадобится отвертка и вы будете рады, что под рукой у вас нечто большее, чем простая открывалка. Магия Git viii Конфликты при слиянии Для этой темы аналогия с компьютерной игрой становится слишком натянутой. Вместо этого, давайте вернемся к редактированию документа. Итак, допустим, что Алиса вставила строчку в начале файла, а Боб — в конец. Оба они закачи- вают свои изменения. Большинство систем автоматически сделает разумный вывод: принять и объединить их изменения так, чтобы обе правки — и Алисы, и Боба — были применены. Теперь предположим, что и Алиса, и Боб независимо друг от друга сделали изменения в од- ной и той же строке. Тогда становится невозможным разрешить конфликт без человеческого вмешательства. Тот, кто вторым из них закачает на сервер изменения, будет информирован о конфликте слияния, и должен либо выбрать, чье изменение перекроет другое, либо заново от- редактировать строку целиком. Могут случаться и более сложные ситуации. Системы контроля версий разрешают простые ситу- ации сами, и оставляют сложные для человека. Обычно такое их поведение поддается настрой- ке. Магия Git 1 / 41 Глава 1 Предисловие Git это Швейцарский армейский нож контроля версий. Надежный универсальный многоцелевой инструмент контроля версий, чья черезвычайная гибкость делает его сложным в изучении даже для многих профессионалов. Как говорил Артур Кларк - любая достаточно развитая технология неотличима от магии. Это отличный способ подхода Git: новички могут игнорировать принципы его внутренней работы и рассматривать Git как гизмо, который может поражать друзей и приводить в бешенство врагов своими чудесными способностями. Вместо того, чтобы вдаваться в подробности, мы предоставляем грубую инструкцию для кон- кретных действий. После частого использования вы постепенно поймете как работает каждый трюк и как адаптировать рецепты для ваших нужд. Переводчики • Китайский (упрощенный) : JunJie, Meng и JiangWei. Хостинг - Google Docs. • Испанский : Rodrigo Toledo. Другие Издания • HTML одной страницей : один HTML без CSS. • PDF файл : для печати. • Пакет Debian : получите локальную копию этого сайта. Пакет Ubuntu (Jaunty Jackalope) . Также доступен когда этот сервер недоступен для сопровождающих 1.1 Благодарности Благодарю Dustin Sallings, Alberto Bertogli, James Cameron, Douglas Livingstone, Michael Budde, Richard Albury, Tarmigan, Derek Mahar и Frode Aannevik за внесенные предложения и улучшения. Спасибо Daniel Baumann за создание и сопровождение пакета для Debian. Также благодарен JunJie, Meng и JiangWei за перевод на китайский, и Rodrigo Toledo за перевод на испанский. [Если я забыл про вас, пожалуйста, сообщите мне, поскольку я часто забывают обновлять этот раздел.] Мои благодарности остальным за вашу поддержку и похвалу. Если бы это была реальная физи- ческая книга, я смог бы разместить Ваши щедрые отзывы о ней на обложке, чтобы прореклами- ровать ее! Серьезно, я высоко ценю каждое ваше сообщение. Чтение их всегда поднимает мне настроение. Бесплатные хостинги Git Магия Git 2 / 41 • http://repo.or.cz/ хостинг свободных проектов. Первый сайт Git-хостинга. Основан и поддержи- вается одним из первых разработчиков Git. • http://gitorious.org/ другой сайт Git-хостинга, направленный на проекты с открытым кодом. • http://github.com/ хостинг проектов с открытым кодом, и закрытых проектов на платной основе. Большое спасибо каждому из этих участков для размещения данного руководства. 1.2 Лицензия Это руководство выпущено под GNU General Public License version 3 . Естественно, что источник находится в репозитории Git, и можно получить, набрав: $ git clone git://repo.or.cz/gitmagic.git # Создает каталог "gitmagic". или с одного из зеркал: $ git clone git://github.com/blynn/gitmagic.git $ git clone git://gitorious.org/gitmagic/mainline.git Магия Git 3 / 41 Глава 2 Базовые операции Прежде чем погружаться в дебри многочисленных команд Git, попробуйте воспользоваться при- ведёнными ниже простыми примерами, чтобы немного освоиться. Несмотря на свою простоту, каждый из них является полезным. В самом деле, первые месяцы использования Git я не выходил за рамки материала, изложенного в этой главе. 2.1 Сохранение состояния Выполняете опасную операцию? Прежде чем сделать это, создайте снимок всех файлов в теку- щей директории с помощью команд: $ git init $ git add . $ git commit -m "Мой первый бекап" Теперь, если ваши новые правки всё испортили, запустите: $ git reset --hard чтобы вернуться к исходному состоянию. Чтобы вновь сохраниться, выполните: $ git commit -a -m "Другой бекап" 2.1.1 Добавление, удаление, переименование Приведенный выше пример будет отслеживать файлы, которые вы добавили, когда впервые запу- стили git add. Если вы хотите добавить новые файлы или поддиректории, вам придётся сказать Git: $ git add НОВЫЕ_ФАЙЛЫ... Аналогично, если вы хотите, чтобы Git забыл о некоторых файлах, например, потому что вы удалили их: $ git rm СТАРЫЕ_ФАЙЛЫ... Переименование файла — это то же, что и удаление старого имени и добавления нового. Для этого есть git mv, который имеет тот же синтаксис, что и команда mv. Например: $ git mv OLDFILE NEWFILE Магия Git 4 / 41 2.2 Расширенная отмена/Восстановление Иногда вы просто хотите вернуться к определенной точке и забыть все изменения, потому что все они были неправильными. В таком случае: $ git log покажет вам список последних изменений (коммитов, прим. пер.) и их SHA1 хеши. Далее введи- те: $ git reset --hard SHA1_HASH для восстановления состояния до указанного коммита и удаления всех последующих коммитов безвозвратно. Возможно, в другой раз вы захотите быстро вернуться к старому состоянию. В этом случае на- берите: $ git checkout SHA1_HASH Это перенесет вас назад во времени, до тех пор пока вы не сделаете новые коммиты. Как и в фантастических фильмах о путешествиях во времени, если вы редактируете и коммитите код, вы будете находиться в альтернативной реальности, потому что ваши действия отличаются от тех, что вы делали до этого. Эта альтернативная реальность называется «ветвь» (branch, прим. пер.), и чуть позже мы пого- ворим об этом . А сейчас просто запомните: $ git checkout master вернёт вас обратно в настоящее. Кроме того, чтобы не получать предупреждений от Git, всегда делайте коммит или сброс ваших изменений до запуска checkout. Ещё раз воспользуемся терминологией компьютерных игр: • git reset --hard: загружает ранее сохраненную игру и удаляет все версии, сохраненные после только что загруженной. • git checkout: загружает старую игру, но если вы продолжаете играть, состояние игры бу- дет отличаться от более новых сохранений, которые вы сделали в первый раз. Любая игра, которую вы теперь сохраняете, попадает в отдельную ветвь, представляющую альтенативную реальность, в которую вы вошли. Как мы договорились Вы можете выбрать для восстановления только определенные файлы и поддиректории путём перечисления их имён после команды: $ git checkout SHA1_HASH some.file another.file Будьте внимательны: такая форма checkout может незаметно перезаписать файлы. Чтобы избе- жать неприятных неожиданностей, выполняйте коммит до запуска checkout, особенно если вы только осваиваетесь с Git. Вообще, если вы не уверены в какой-либо операции, будь то команда Git или нет, сперва выполните git commit -a. Не любите копировать и вставлять хеши? Используйте: $ git checkout :/"Мой первый б" для перехода на коммит, который начинается с приведенной строки. Можно также запросить 5-ое с конца сохраненное состояние: $ git checkout master5 Магия Git 5 / 41 2.2.1 Возвраты В зале суда в протокол могут вноситься изменения прямо во время слушания. Подобным образом и вы можете выбирать коммиты для возврата. $ git commit -a $ git revert SHA1_HASH отменит коммит с выбранным хешем. Запущенный git log показывает, что изменение записано в качестве нового коммита. 2.3 Создание списка изменений Некоторым проектам требуется список изменений (changelog, прим. пер.). Создать такой список вы можете, просто направив вывод git log в файл: $ git log > ChangeLog 2.4 Скачивание файлов Получить копию проекта под управлением Git можно, набрав: $ git clone git://server/path/to/files Например, чтобы получить все файлы, я создавал такой сайт: $ git clone git://git.or.cz/gitmagic.git Мы поговорим больше о команде clone позже. 2.5 На острие ножа Если вы уже загрузили копию проекта с помощью git clone, вы можете обновить его до послед- ней версии, используя: $ git pull 2.6 Публичный доступ Предположим, вы написали скрипт, которым хотите поделиться с другими. Можно просто поз- волить всем загружать его с вашего компьютера, но, если они будут делать это в то время, как вы дорабатываете его или добавляете экспериментальную функциональность, у них могут возник- нуть проблемы. Конечно, это одна из причин существования цикла разработки. Разработчики могут долго работать над проектом, но открывать доступ к коду следует только после того, как код приведен в приличный вид. Чтобы сделать это с помощью Git, выполните в директории, где лежит ваш скрипт: Магия Git 6 / 41 $ git init $ git add . $ git commit -m "Первый релиз" Затем скажите вашим пользователям запустить: $ git clone ваш.компьютер:/path/to/script для того чтобы загрузить ваш скрипт. Это подразумевает что у вас есть доступ по ssh. Если нет, запустите git daemon и скажите остальным использовать для запуска: $ git clone git://ваш.компьютер/path/to/script Теперь, всякий раз когда ваш скрипт готов к релизу, выполняйте: $ git commit -a -m "Следующий релиз" и ваши пользователи смогут обновить свои версии, перейдя в директорию, содержащую ваш скрипт, и, набрав: $ git pull ваши пользователи никогда не попадут на версии скрипта, доступ к которым вы скрываете. Без- условно, этот трюк работает для всего, а не только в случаях со скриптами. 2.7 Что я наделал? Выясните, какие изменения вы сделали со времени последнего коммита: $ git diff Или со вчерашнего дня: $ git diff "@{yesterday}" Или между определенной версией и версией, сделанной 2 коммита назад: $ git diff SHA1_HASH "master2" В каждом случае на выходе будет патч, который может быть применён с помощью git apply. Попробуйте также: $ git whatchanged --since="2 weeks ago" Часто я смотрю историю при помощи qgit вместо стандартного способа, из-за приятного интер- фейса, или с помощью tig с текстовым интерфейсом, который хорошо работает при медленном соединении. В качестве альтернативы, можно запустить веб-сервер, введя git instaweb, и запу- стить любой веб-браузер. Магия Git 7 / 41 2.8 Упражнение Пусть A, B, C, D четыре успешных коммита, где В — то же, что и A, но с несколькими удаленными файлами. Мы хотим вернуть файлы в D, но не в B. Как это можно сделать? Существует как минимум три решения. Предположим, что мы находимся на D. 1. Разница между A и B — удаление файлов. Мы можем создать патч, отражающий эти изме- нения, и применить его: $ git diff B A | git apply 2. Поскольку в коммите A мы сохранили файлы, мы можем получить их обратно: $ git checkout A FILES... 3. Мы можем рассматривать переход от A до B в качестве изменений, которые мы хотим от- менить: $ git revert B Какой способ лучший? Тот, который вам больше нравится. С Git легко сделать все, что вы хотите, причём часто существует много разных способов сделать одно и то-же. Магия Git 8 / 41 |