Revision [41]

This is an old revision of Git made by ace on 2017-02-26 06:25:14.

Введение в Git

Table of Contents

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

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

* "Pro Git eng":http://git-scm.com/book
* "Pro Git rus":http://cloud.github.com/downloads/GArik/progit/progit.ru.pdf

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

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

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

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

iss53:index.html

* В верхней части(до

=) будет часть кода, которая находится в текущей ветке. * В нижней части (после

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 config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

* Список параметров со значениями:

$ git config --list

ace's notebook : Git