Revision [49]

This is an old revision of Git made by ace on 2017-02-26 07:11:40.

 

Введение в Git


Table of Contents


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

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


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


- Распределенная система: - В отличии от большинства систем при commit сохраняется слепок файловой системы, а не различия(diff) в файлах. - Добавлять новые файлы нужно вручную:
- В 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