======Введение в Git====== {{{toc}}} Данная статья является выжимкой из книги Pro Git. =====Документация===== - [[http://git-scm.com/book|Pro Git eng]] - [[http://cloud.github.com/downloads/GArik/progit/progit.ru.pdf|Pro Git rus]] =====Основные фичи, термины.===== - Распределенная система: - У каждого разработчика хранится полная копия репозитория. - Это значит, что с ним можно работать при отсутствии связи с основным репозиторием. - Почти все операции — локальные - Ветвление - как основной инструмент работы. - В отличии от большинства систем при commit сохраняется слепок файловой системы, а не различия(diff) в файлах. - Если файл не был изменен, то берется линк на предыдущую версию. - Если файл был изменен, то заливается новая версия файла полностью. - При удалении файла, сам файл и его история остается. Он просто не попадает в "слепок". - Добавлять новые файлы нужно вручную: - Это значит, что папки типа upload и временные файлы игнорируются. Не надо писать исключений. - Благодаря этому рабочий каталог может быть корневым каталогом сайта на dev-сервере. - В Git файлы могут находиться в одном из трёх состояний: - Зафиксированный (committed) - значит, что файл уже сохранён в вашей локальной базе. - Измененный (modified) - файлы, которые поменялись, но ещё не были зафиксированы - Подготовленные файлы(staged) — это изменённые файлы, отмеченные для включения в следующий коммит - Если рабочая версия файла совпадает с версией в каталоге Git, файл считается зафиксированным(commited). Если файл изменён, но добавлен в область подготовленных данных, он подготовлен(staged). Если же файл изменился после выгрузки из репозитория, но не был подготовлен, то он считается изменённым(modified). - Три основных части Git проекта: - Каталог Git - это место, где Git хранит метаданные и базу данных объектов вашего проекта. Это наиболее важная часть Git, и именно она копируется, когда вы клонируете репозиторий с другого компьютера. - Рабочий каталог — это извлечённая из базы копия определённой версии проекта. Эти файлы достаются из сжатой базы данных в каталоге Git и помещаются на диск для того, чтобы вы их просматривали и редактировали. - Область подготовленных файлов(staging area) — это обычный файл, обычно хранящийся в каталоге Git, который содержит информацию о том, что должно войти в следующий коммит. Иногда его называют индексом (index), но в последнее время становится стандартом называть его областью подготовленных файлов (staging area). - Стандартный рабочий процесс с использованием Git выглядит примерно так: - Вы изменяете файлы в вашем рабочем каталоге. - Вы подготавливаете файлы, добавляя их слепки в область подготовленных файлов. - Вы делаете коммит. При этом слепки из области подготовленных файлов сохраняются в каталог Git. =====Часто используемые команды===== ====git status==== - Используемый для определения, какие файлы в каком состоянии находятся - Changes to be committed: - файлы, которые будут помещены в репозиторий при следующем commit (добавляются через git add) - Changed but not updated: - файлы, которые хранятся в репозитории и были изменены в рабочем каталоге , но к ним не была применена команда git add - Untracked files - новые файлы, которые не включены в слепок(новые файлы которые никогда не присутствовали в репозитории). - Для игнорирования файлов в разделе Untracked files используется файл .gitignore. Шаблоны: - Пустые строки, а также строки, начинающиеся с #, игнорируются. - Можно использовать стандартные glob шаблоны. - Можно заканчивать шаблон символом слэша (/) для указания каталога. - Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа. ====git add==== - Используется для - добавления новых файлов - добавления(индексации) измененных файлов в staging area - Можно избежать использование команды для измененных файлов используя комманду git commit -a ====git commit==== - Сохранение изменений в локальном репозитории. - Для комментирования можно использовать ключ -m %%git commit -m "iss182: Fix benchmarks for speed"%% - Если использовать без ключа -m, то откроется редактор в котором надо будет описать изменения. - ключ -a позволяет избежать использование команды git add для измененных файлов. - ключ --amend, позволяет изменить последний commit:%%git commit -m 'initial commit' git add forgotten_file git commit --amend%% =====Ветвление (Branch)===== ====git branch==== - Просмотр веток в репозитории - * указывает ветку с которой вы сейчас работает - ключ -v - дает информацию о последних коммитах каждой ветки. ====git branch branch_name [from_branch_name]==== - создание новой ветки на базе from_branch_name. Без переключения в нее. - для переключения надо выполнить команду git checkout branch_name - также можно создать и сразу перейти к ветке командой git checkout -b branch_name [from_branch_name] - если from_branch_name не указан, новая ветка создается на базе текущей. ====git branch -d branch_name==== - удаление ветки ====git checkout==== - git checkout branch_name - переключение на ветку branch_name. Перезаписывает файлы в рабочей директории. - git checkout -b branch_name - создание и переключение на ветку branch_name. - git checkout -- filename - перезаписывает файл в рабочем каталоге содержимым файла с последнего коммита из репозитория. ====git merge branch_name_to_merge==== - Производит слияние веток. - Вы должны находится в основной ветке в которую хотите влить изменения с branch_name_to_merge. ====git rebase branch_name==== - Слияние, при которой все коммиты вашей текущей ветки попадают в ветку branch_name. - Позволяет видеть историю работы последовательно. - Результат работы аналогичен git merge - *Внимание*. Не перемещайте коммиты, которые вы выложили в публичный репозиторий. То есть эта команда хороша только для работы с локальным репозиторием до push. ====Пример работы с branch==== - Вам поступил звонок об критической ошибке на сайте: - Вы работаете в ветке dev - Вы сохраняете текущую работу (git commit) - Переключаетесь в основную ветку (git checkout master) - Создаете новую ветку (git checkout -b hotfix) - Делаете изменения, проверяете что проблема решена. - Сохраняете ваши изменения (git commit) - Переходите в основную ветку (git checkout master) - Выполняете слияние (git merge hotfix) - Удаляете ветку hotfix если она не нужна (git branch -d hotfix) - Переключаетесь обратно в ветку dev (git checkout dev) и продолжаете работу - Если hotfix критический и в может повлиять на вашу текущую работу, не забудьте объединить вашу текущую ветку разработки с веткой master. ====Конфликты при слиянии==== - Конфликты возникают когда вы в двух ветках редактировали в одном и том же файле одну и туже часть. - Примечание: допустим в файле у вас описан класс. В ветке мастер вы отредактировали один метод. В вашей ветке вы отредактировали другой. В этом случае конфликта не возникнет. - При слиянии система пытается сделать commit для текущей ветки, то есть: - Cначала объединенные файлы помещаются в staged-area. - После чего происходит commit - Если возник конфликт, то, commit не происходит и его надо сделать вручную следующим образом: - с помощью git status посмотреть какие файлы имеют конфликт(unmerged:) - отредактировать эти файлы в рабочей папке. В них будут следующие секции: %% <<<<<<< HEAD:index.html ======= >>>>>>> iss53:index.html %% - В верхней части(до ""======="") будет часть кода, которая находится в текущей ветке. - В нижней части (после ""=======""), часть кода из ветки с которой вы пытаетесь слиться. - Вам необходимо заменить данный блок на подходящий код. - После того как вы отредактировали все файлы необходимо для каждого конфликтного файла сделать git add - Окончательным шагом будет git commit - для завершения слияния. =====Работа с удаленным репозиторием.===== ====git clone==== - Получение репозитория с удаленного сервера для локальной работы: - В каталоге где будет вести разработка: %%git clone git://github.com/schacon/grit.git mygrit%% *заменить на наш репозиторий* - Эта команда - создает каталог с именем «mygrit» - инициализирует в нем каталог .git - скачивает все данные для этого репозитория - создает (git checkout) рабочую копию последней версии. - Если вы зайдете в новый каталог mygrit, вы увидите в нем проектные файлы, пригодные для работы и использования. ====git remote==== - настройка удаленных репозиториев - после git clone прописывается репозиторий с которого скачали под alias origin - просмотр: git remote -v - добавление: git remote add pb git://github.com/paulboone/ticgit.git - просмотр информации: git remote show pb - переименование: git remote rename pb paul - удаление: git remote rm paul ====git fetch [rep_alias] [branch]==== - вытягивает изменения c удаленного репозитория, но при этом не делает слияния - создает ветку в вашем репозитории rep_alias/branch - если rep_alias не указан, используется последний использованный - если branch не указан - используется имя вашего текущего branch ====git pull [rep_alias] [branch]==== - вытягивает изменения c удаленного репозитория(git fetch), при этом пытается сделать слияние с вашим репозиторием. - если rep_alias не указан, используется последний используемый сервер - если branch не указан - используется ваша текущая ветка ====git push [rep_alias] [branch][:remote_branch]==== - заливает ваши наработки в удаленный репозиторий - *внимание*: при синтаксисе git push rep_alias :branch - происходит удаление ветки на сервере - Если вы и кто-то ещё одновременно клонируете репозиторий, затем он выполняет команду push, а затем команду push выполняете вы, то ваш push точно будет отклонён. Вам придётся сначала вытянуть (fetch) их изменения и объединить с вашими (смотри пример ниже) - Вы можете изменить имя ветки на удаленном сервере, указанием remote_branch - если rep_alias не указан, используется последний используемый сервере - если branch не указан - используется ваша текущая ветка ====Пример работы==== - Загружаем репозиторий (git clone) - делается один раз в самом начале работы. - Делаем изменения и коммитем их (git commit) - Загружаем на сервер (git push) - Если получили отказ (error: failed to push some refs): - Загружаем изменения сделанными другими участниками (git fetch) - Объединяем свою текущую ветку (master) c веткой сервера (origin/master) (git merge origin/master) - Загружаем полученную ветку на сервер (git push) =====Начальные команды===== ====Создание репозитория из существующего проекта==== - В папке проекта %%git init git add *.php git add *.phtml git add *.css git add *.html git add *.htm git add .htaccess git commit -m 'initial project version' %% =====Редко используемые команды===== ====git rm==== - Удаляет файл с локальной рабочей директории и из индекса. ====git mv==== - Перемещает/переименовывает файлы. - Важно - история файла не сохраняется, так как команда фактически делает следующее: - mv old_file new_file - git rm old_file - git add new_file ====git log==== - Просмотр истории commit-ов =====Команды для администрирования===== ====git config==== - Файлы конфигов - без параметров в папке репозиория .git/config - --system - использовать файл /etc/gitconfig - --global - использовать файл ~/.gitconfig - Создание пользователя:%%git config --global user.name "John Doe" git config --global user.email johndoe@example.com%% - Список параметров со значениями: %%git config --list%%