Скотт Чакон - Pro Git

:040000 040000 40ee3e7821b895e52c1695092db9bdc4c61d1730

f24d3c6ebcfc639b1a3814550e62d60b8e68a8e4 M config

Когда вы закончили бинарный поиск, нужно выполнить git bisect reset для того, чтобы вернуть HEAD туда, где он был до начала поиска, иначе вы останетесь в, довольно, причудливом состоянии:

$git bisect reset

Это мощный инструмент, который помогает вам за считанные минуты проверить сотни коммитов на возможность внесения ошибки. В действительности, если у вас есть скрипт, который будет возвращать 0 если проект находится в рабочем состоянии и любое другое число в обратном случае, то вы можете полностью автоматизировать git bisect. Сперва, вы снова сообщаете границы бинарного поиска, указывая известные плохие и хорошие коммиты. Вы можете сделать это, передавая их команде bisect start – первым аргументом известный плохой коммит, а вторым известный хороший коммит:

$git bisect start HEAD v1.0

$git bisect run test-error.sh

Это приведет к автоматическом выполнению test-error.sh на каждый выгруженный коммит до тех пор, пока Git не найдет первый сломанный коммит. Вы также можете использовать что-то вроде make или make tests, или что-то еще, что у вас есть для запуска автоматизированных тестов.

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

Приведем пример. Предположим, вы разрабатываете веб-сайт и создаете ленту в формате Atom. Вместо написания собственного генератора Atom, вы решили использовать библиотеку. Вы, вероятно, должны либо включить нужный код из разделяемой библиотеки, например, модуля CPAN или Ruby gem, либо скопировать исходный код библиотеки в ваш проект. Проблема с использованием библиотеки состоит в сложной адаптации библиотеки под свои нужны и часто более сложным ее распространением, так как вам нужно быть уверенным, что каждому клиенту доступна такая библиотека. При включении кода библиотеки в свой проект проблема будет заключаться в сложном объединении ваших собственных изменений с изменениями в вышестоящем репозитории.

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

Далее мы рассмотрим процесс разработки простого проекта, разбитого на один главный проект и несколько подпроектов.

Давайте начнем с добавления существующего Git-репозитория, в качестве подмодуля репозитория, в котором мы работаем. Для добавления нового подмодуля используйте команду git submodule add с URL проекта, который вы хотите начать отслеживать. В данном примере мы добавим библиотеку “DbConnector”.

$git submodule add https://github.com/chaconinc/DbConnector

Cloning into 'DbConnector'...

remote: Counting objects: 11, done.

remote: Compressing objects: 100% (10/10), done.

remote: Total 11 (delta 0), reused 11 (delta 0)

Unpacking objects: 100% (11/11), done.

Checking connectivity... done.

По умолчанию подмодули добавляют подпроекты в директории, называемые так же, как и соответствующие репозитории, в нашем примере – “DbConnector”.

Если в данный момент вы выполните git status, то заметите несколько моментов.

$git status

On branch master

Your branch is up-to-date with 'origin/master'.

Changes to be committed:

(use "git reset HEAD ..." to unstage)

new file: .gitmodules

new file: DbConnector

Во-первых, вы должны заметить новый файл .gitmodules. Это конфигурационный файл, в котором хранится соответствие между URL проекта и локальной поддиректорией, в которую вы его выкачали:

$cat .gitmodules

[submodule "DbConnector"]

path = DbConnector

url = https://github.com/chaconinc/DbConnector

Если у вас несколько подмодулей, то и в этом файле у вас будет несколько записей. Важно заметить, что этот файл добавлен под управление Git так же, как и другие ваши файлы, например, ваш файл .gitignore. Этот файл можно получить или отправить на сервер вместе с остальными файлами проекта. Благодаря этому другие люди, которые клонируют ваш проект, узнают откуда взять подмодули проекта.

Поскольку другие люди первым делом будут пытаться выполнить команды clone/fetch по URL, указанным в файле .gitmodules, старайтесь проверять, что URL будут им доступны. Например, если вы выполняете отправку по URL отличному от того, по которому другие люди получают данные, то используйте URL, к которому у других участников будет доступ. Вы можете изменить это значение локально только для себя с помощью команды git config submodule.DbConnector.url PRIVATE_URL.