Введение в Git

Table of Contents

Данная статья является выжимкой из книги Pro Git.

Документация

Основные фичи, термины.

Распределенная система:

У каждого разработчика хранится полная копия репозитория.
Это значит, что с ним можно работать при отсутствии связи с основным репозиторием.
Почти все операции — локальные

Ветвление - как основной инструмент работы.
В отличии от большинства систем при 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
```

ace's notebook : Git