Wiki source for Git
======Введение в 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
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> 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%%
{{{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
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> 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%%
