Введение
Git (произн. «гит») — это распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года.
Git позволяет вести распределённую работу над одним проектом. Разработчики могут располагаться как на одном компьютере, так и в разных частях света.
Помимо Git есть много других систем управления версиями (VCS, Version Control System), одной из которых является свободная (и бесплатная) система Subversion (кратко SVN).
Subversion (также известная как «SVN») — свободная централизованная система управления версиями, официально выпущенная в 2004 году компанией CollabNet Inc.
Обо всём этом можно подробно прочитать в других источниках. Здесь же я опишу своё краткое представление о Git, которое у меня сложилось при работе с ним. Описание не претендует на полное и всеобъемлющее.
Описание будет в виде коротких тезисов и абзацев
Хотя местами указаны названия команд, они не будут выполняться, т.к. некоторые параметры для них опущены. Конкретные примеры применения команд git будут рассмотрены в следующей статье.
Git, описание
Общее
Git — это распределённая система управления версиями.
С git можно работать и локально и удалённо.
Репозиторий (хранилище) — это место, где хранится наши данные: история изменений нашего проекта
Репозиторий Git — это всегда локальный репозиторий
Данные репозитория git помещается в папку .git/ в папке, в которой вы создали репозиторий
Любую папку на компьютере можно легко превратить в папку с локальным репозиторием, выполнив всего одну команду git init внутри выбранной папки для репозитория
О репозитории
В Git, в отличии от Subversion, есть два типа репозитория: «простой» и «голый»
Простой репозиторий — это основной репозиторий, с которым вам предстоит работать. В нём вы можете выполнять большинство команд git. Такой репозиторий содержит подпапку .git/
Голый репозиторий — этот репозиторий часто, применяемый для ведения разработки в централизованном стиле. Данные репозитория не помещаются в подпапку .git/, а размещаются непосредственно в корне папки репозитория
Настройки репозитория
Используйте команду git config для работы с настройками, или редактируйте файлы настроек вручную
Каждый репозиторий Git имеет свои собственные настройки, располагаемые в файле .git/config
Вообще настройки репозиториев Git соответствуют общей архитектуре настроек в Linux. А именно, это означает, что настройки разделены на три уровня:
- Уровень 1. Локальные настройки репозитория, применяются только к одному конкретному репозиторию, располагаются в каждом отдельном репозитории в файле .git/config
- Уровень 2. Пользовательские настройки репозитория, применяются ко всем репозиториям пользователя, и располагаются в домашней директории пользователя в файле ~/.gitconfig (Для Windows путь к домашней директории вы можете явно указать в переменной окружения HOME)
- Уровень 3. Системные настройки, применяются ко всем репозиториям всех пользователей системы, располагаются обычно в файле /etc/gitconfig (для Windows это может быть файл «c:Program Files (x86)Gitetcgitconfig»)
Приоритетным уровнем является первый, поэтому в нём могут быть переопределены все настройки, которые были установлены с верхних уровней.
Отношения между репозиториями
Репозиторий Git — это всегда локальный репозиторий, располагающийся в своей папке
Для репозитория есть понятие «наблюдать за другим репозиторием» (это понятие я придумал сам), на практике выражается использованием команд git remote в консоли и секций [remote «имя_наблюдения»] в файле конфигураций репозитория
Один репозиторий может:
- не наблюдать ни за кем
- или наблюдать за любым кол-вом репозиториев
Репозиторий A может загрузить полное (или частичное) содержимое репозитория B, даже если A «не наблюдает» за B, и даже если A не имеет общей истории с B.
«Загрузить» (git fetch) внешний репозиторий и «слиться» (git merge) с репозиторием — разные вещи! Мы всегда можем загрузить содержимое внешнего репозитория, посмотреть его историю изменений, но не прибегать к слиянию с ним.
Допустим, в репозитории A вы создали наблюдение с именем seeB за репозиторием B (git remote add seeB path/to/B). Но важно помнить, что «наблюдение» не обновляется автоматически. Это значит, что спустя время, git не сообщит вам об изменениях в репозитории B. Узнавать об этом вам необходимо самим — просто загрузив свежую версию репозитория B командой git fetch seeB. «Наблюдение» — это не какая-то система слежения, а просто копия репозитория B в одной из падпапок .git/ репозитория A.
Одиночная работа
Создав репозиторий, в него можно фиксировать изменения (git commit), просматривать логи изменений (git log), загружать указанную или последнюю версию фиксации (git checkout)
Одиночная работа с репозиторием сводится к тому, что вы делаете некоторые изменения в файлах и фиксируете их (подробнее об этом написано в статье «Название статьи»)
Распределённая работа
Командная работа над проектом (репозиторием) начинается тогда, когда кто-то клонирует его.
Клонировать репозиторий — значит скопировать весь репозиторий полностью: вместе со всей его историей изменений.
Один репозиторий может быть клонирован любым кол-вом людей.
Чтобы слить два репозитория в будущем, их не обязательно клонировать изначально, но клонировать удобнее, т.к. автоматически добавляется информация о «наблюдении за оригинальным репозиторием» в настройках клона.
Когда разработчик 2 внёс изменения в склонированный ранее репозиторий, он сообщает об этом разработчику 1. И тот «забирает» его изменения от себя используя команду git pull (или две последовательные команды git fetch и git merge). После этого разработчик 1 сообщает разработчику 2, что он принял изменения, после этого 2-й разработчик обновляет свой склонированный репозиторий командой git pull, и продолжает разработку.
Разработчик 2 не смог бы «втолкнуть» (git push) свои изменения в репозиторий разработчика 1, т.к. по умолчанию это запрещено (для больших подробностей смотрите опцию receive.denyCurrentBranch настроек репозитория)
Втолкнуть изменения из репозитория B в репозиторий A, без его ведома A можно в том случае, если репозиторий A является «голым» (т.е. создан командой git init —bare).
Распределённая структура разработки
Есть группа разработчиков. Каждый имеет свой собственный «простой» (git init) репозиторий. У каждого настроены «наблюдения» за репозиториями соседей. Каждый разработчик сам загружает к себе чужие изменений. Никто из разработчиков не может ни кому «втолкнуть» свои изменения.
Централизованная структура разработки
Существует центральный «голый» (git init —bare) репозиторий. Все остальные разработчики отклонировались от центрального репозитория. Каждый разработчик сначала вносит изменения в свой локальный репозиторий-клон, а потом «вталкивает» (git push) свои изменения в центральный сервер.
Ветви в репозитории
Используйте команду git branch, чтобы просмотреть список существующих веток в репозитории и узнать какая ветка сейчас выбрана активной
Используйте
команду git branch -r, чтобы просмотреть список веток в существующих «наблюдениях» репозитория
Ветка в репозитории — это альтернативный путь развития проекта
Репозиторий может содержать любое кол-во веток
При создании веток не происходит физического копирования файлов хранилища. Поэтому даже создав много веток, это не отразится сильно на размере репозитория
Две ветви одного репозитория могут быть слиты в одну ветку (git merge)
Создать новую ветку можно двумя способами:
- создать явно командой git branch имя_ветки
- или неявно: откотиться назад до любой фиксации, внести изменения и зафиксировать эти новые изменения.
Git защитит вас, если вы попытаетесь удалить ветку (git branch -d имя_ветви), изменения которой вы ещё не сливали в главной ветвь. Но если вы всё же хотите удалить ветвь без слияния с основной ветвью, используйте команду git branch -D имя_ветви
Общие понятия в репозитории
Репозиторий имеет несколько важных понятий, о которых важно знать, чтобы поняь принцип работы с репозиторием.
Working tree — рабочая папка «простого» репозитория, место, где хранятся файлы вашего проекта (папка .git не относится к этой области)
Index (staging area) — незримая область, в которой хранятся отметки о файлах, изменения в которых вы собираетесь зафиксировать
Local repo — ваш локальный репозиторий.
Remote repo — это удалённый репозиторий, который может находиться как в другой папке на вашем компьютере, так и на другой машине в сети.
Таким образом процесс работы с репозиторием сводится к следующей простой схеме:
- вы вносите изменения в working directory
- добавляете желаемые изменения в область staging area
- фиксируете изменения в репозиторий local repo
Также есть ещё несколько понятий, значение которых я ещё не уловил до конца:
- HEAD — ссылка на текущее состояние репозитория
- FETCH_HEAD — ссылка на состояние репозитория, загруженное в эту ссылку командой git fetch или git pull
Заключение
Более подробно о работе git я расскажу в следующей статье. Данная статья служит лишь общим каркасом для понимания общих идей и принципов работы git. Всё, о чём говорилось здесь, мы рассмотрим в следующей статье на примерах
Читать далее: Git, краткий справочник команд
Смотрите также: