Руководство по контролю версий с использованием Git

Оригинал: Master version control with Git – tutorial
Автор: Richard Smedley
Дата публикации: 30 November 2014
Перевод: Н.Ромоданов
Дата перевода: декабрь 2014 г.

Git освоить довольно легко, но, поскольку мы расскажем не только о том, "что делать", но и о том "почему", вы узнаете гораздо больше и разберетесь не только со списком команд, но и с тем, что лежит глубже.

Git стал популярным настолько быстро, что можно было легко пропустить, почему им следовало бы пользоваться в повседневном кодировании (и написании статей). Мы намереваемся быстро разобраться, почему Git является таким особенным, и как его использовать - и мы надеемся вернуться к Git в ближайшие месяцы для того, чтобы рассказать о других сферах приложения, в которых Git может помочь вам с организацией дел.

Git является распределенной системой контроля версий, написанной Линус Торвальдсом после того, как из-за фиаско с BitKeeper в пректе ядра Linux возникла необходимость в новом хранилище данных. Теперь, благодаря GitHub и десятку других популярных репозиториев, в которых Git используется как социальное хранилище, а также средство совместного использования кода, он становится именно тем, что по умолчанию выбирается в новых проектах в качестве средства распределенного контроля версий и управления исходным кодом.

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

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

Подключаемся к любому проекту со свободным исходным кодом, в котором есть репозиторий Git

Ресурсы

Git

Аккаунт GitHub

Базовые знания по использованию командной строки

Пошаговые инструкции

Шаг 01: Проект, любой проект

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

Шаг 02: Установка

Естественно, в вашем дистрибутиве есть легко устанавливаемый двоичный файл. В большинстве дистрибутивов отдельно есть пакеты, предназначенные для преобразований из Git в Subversion, графический интерфейс, средства визуализации дерева релизов и прочее. Для того, чтобы у вас был очень полный комплект документации в формате HTM, установите пакет git-doc .

Шаг 03: Кто я?

Первоначальная конфигурация состоит в выполнении нескольких команд git config –global, с помощью которых ваши данные будут записаны в файл ~/.gitconfig. Без переключателя -global, команда git config сделает запись в файл ./.gitconfig так, что у вас есть возможность настраивать различные иедивидуальные репозитории.

Шаг 04: Дерево, прежде всего

Это те репозитории, которые создаются там, где находится ваш код; перейдите в каталог проекта и инициализируйте свой ваш первый репозиторий с помощью следующей команды:

git init

Будет создан каталог .git: теперь у вас есть рабочее дерево и теперь вы готовы к фиксации изменений в репозитории. Инициализация в каждом репозитории выполняется только один раз.

Шаг 05: Подготовка данных

Теперь, когда у вас есть рабочий репозиторий, давайте воспользуемся следующей командой:

git add

... которая поместит данные в область подготовленных данных. Если в качестве аргумента указать '.', то операция будет выполнена рекурсивно (т.е. включая и подкаталоги). Теперь мы воспользуемся командой коммит и, наконец, поместим в репозиторий наш код, который будет отслеживаться системой Git.

Примечание переводчика:

В проекте, использующем Git, есть три важных компонента: каталог Git'а (Git directory), рабочий каталог (working directory) и область подготовленных файлов (staging area). Команда git add помещает данные в область подготовленных данных. Т.е. помещение данных в репозитарий происходит за два шага - сначала данные подготавливаются, т. е. помещаются в область подготовленных данных, а только затем отдельным шагом закоммитчиваются в репозитории. Это важное и очень удобное отличие системы Git от многих других систем контроля версий.

Шаг 06: Статус

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

Шаг 07: Где я был?

Если вы вообще не закоммитили изменения, то можно воспользоваться командой git status и увидеть, какие именно изменения вы сделали, когда, например, воспользовались туннелированием через Rails, вносили изменения в формы, контроллеры и вспомогательные файлы. Что изменилось в этих файлах можно посмотреть с помощью команды git diff.

Шаг 08: Отмена подготовки данных

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

git reset HEAD имя_файла

... просто удалите его из области подготовленный файлов.

Шаг 09: Варианты

Если вы подготовили для коммита совершенно новый файл, а затем выполнили команду

git rm --config имя_файла

… то для того, чтобы удалить этот файл, лучше всего использовать параметр -rm, т. к. при удалении с параметром -cached файл будет просто удален из области подготовленных файлов. В этом случае команда git status, указанная для файла, который мы удалили, покажет изменение состояния со stage (подготовлен) на untracked (неотслеживаемый).

Шаг 10: Коммитим объекты

Со временем будет понятно, что в Git происходит за кулисами. Каждый объект, к которому применяется операция коммит, содержит снимок файлов, ссылки на родительские объекты этого коммита и хэш SHA-1 (40-символьный хэш частей, которые были закоммитчены), причем все это однозначно идентифицирует конкретный коммит.

Шаг 11: HEAD master

Последний объект, к которому применяется коммит, это объект HEAD, а его предок — ссылка HEAD^, которая указывает на самый последней коммит в текущей ветке. По умолчанию у нас есть только ветвь master, но мы для того, чтобы иметь возможность с исходными версиями файлов проекта, можем создавать новые ветки от любых ранее закоммитченных объектов.

Шаг 12: Ветви

Команда git checkout позволит вам использовать другую ветвь. Прежде, чем использовать команду checkout для переключения ветвей, важно закомммитить ваши изменения. В противном случае могут возникнуть некоторые странности, например, можно потерять все изменения, занесенные в ветвь, и т.п. ...

Шаг 13: Закоммитчиваем изменения

Прежде, чем вы смените ветвь, Git в случае, если вы забыли сохранить изменения, выдаст вам подсказку. Для того, чтобы сознательно удалить сделанные вами и еще незакоммитченные изменения, вы можете использовать следующую команду:

git checkout – имя_файла

"На коммиты затрачивается мало ресурсов", поэтому выполняйте коммит в свою собственную отдельную ветвь

Шаг 14: Код релиза

В зависимости от вашей команды и используемой вами стратегии вы можете использовать столько ветвей, сколько вам необходимо. Самый простой подход — использовать ветвь master только для релиза, а дополнительные изменения до тех пор, пока вы не будете готовы слить из обратно в новый релиз, закоммитчивать в ветку, предназначенную для разработок.

Шаг 15: Отслеживаем, что изменено

Иногда, если просто следить за тем, что вы только что сделали, то поможет избежать ошибок, характерных человеческому мышлению. Что это за небольшое изменение, которое, кажется, кто-то нарушил? Команда

git diff

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

git diff --cached

покажет изменения, которые были уже подготовлены, но еще не были закоммитчены.

К числу других полезных команд в Git относится команда

git diff HEAD^

... который показывает изменения, сделанные от момента совершения предшествующего коммита и до последнего коммита.

Шаг 16: Журналы операций над ветвью

Чтобы отследить коммиты в вашей текущей ветки, надо просто для этой ветви выполнить команду git log. Будет показана цепочка объектов, закоммитченных с момента инициализации ветви. Если вы хотите удостовериться в том, что ваш коллега пользуется той же самой ветвью, то лучше всего использовать несколько первых цифр хэша SHA-1, которые указаны в журнале для объекта HEAD.

Шаг 17: Конфликтующий код

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

Шаг 18: Убираем все лишнее

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

Шаг 19: Получаем обновления

Команда git pull origin master дает возможность получить последнюю копию содержимого ветви merge из удаленного репозитория и слить ее с вашей локальной копией. В результате в вашей локальной копии будут объединены обновления, сделанные другими, с вашими собственными изменениями. Вы можете это выполнять достаточно часто или только после тех изменений, которые касаются именно вас.

Шаг 20: Получаем данные

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

Шаг 21: Отсылаем код

Команда git push используется для отсылки изменений в удаленный репозитории. Когда используется параметр push.default в вашей конфигурационной настройке или указываются аргументы в команде (что проще), отсылка выполнена не будет в случае, если имя ветви удаленного репозитория будет отличаться от имени ветви в ващем локальном репозитории.

Шаг 22: Алиасы, сберегающие время

Такие алиасы, как, например,

gc для команды git commit, 
ga f для команды git add –all
и gst для команды git status

Сократят количество нажатий на клавиши для те, кто этими командами пользуется часто. Вы, возможно, пожелаете добавить свои собственные предпочитаемые алиасы в ваш файл .bashrc или скачаете одну из коллекций макросов, которые можно найти на GitHub.

Шаг 23: Попробуйте команды

Возьмите некоторый код и начните опробовать команды. Команду git clone можно использовать для того, чтобы сделать локальную копию всего репозитория Git в полном объеме, включая и все ветви (их можно увидеть с помощью команды git branch -r). Ваше внимание также привлекут кнопки "Fork me on GitHub" (мой форк на GitHub).

Шаг 24: Переходим к использованию Git

Теперь, вооружившись некоторым пониманием того, что представляет собой Git, двигайтесь дальше и распространяйте свой код! В сети есть много учебников по расширенным возможностям использования Git, а мы в нашем издании надеемся вернуться к этой теме в ближайшее время для того, чтобы вам показать, насколько универсально в использовании творение Торвальдса!

---

---