Revision history for Git


Revision [52]

Last edited on 2017-02-28 00:49:41 by ace
Additions:
=====Ветвление (Branch)=====
=====Работа с удаленным репозиторием.=====
=====Начальные команды=====
=====Редко используемые команды=====
=====Команды для администрирования=====
Deletions:
===Ветвление (Branch)===
===Работа с удаленным репозиторием.===
===Начальные команды===
===Редко используемые команды===
===Команды для администрирования===

Revision [51]

Edited on 2017-02-28 00:47:27 by ace
Additions:
- [[http://git-scm.com/book|Pro Git eng]]
- [[http://cloud.github.com/downloads/GArik/progit/progit.ru.pdf|Pro Git rus]]
- Распределенная система:
- В отличии от большинства систем при commit сохраняется слепок файловой системы, а не различия(diff) в файлах.
- Добавлять новые файлы нужно вручную:
- В Git файлы могут находиться в одном из трёх состояний:
- Три основных части Git проекта:
- Стандартный рабочий процесс с использованием Git выглядит примерно так:
====git status====
- Используемый для определения, какие файлы в каком состоянии находятся
- Changes to be committed: - файлы, которые будут помещены в репозиторий при следующем commit (добавляются через git add)
- Changed but not updated: - файлы, которые хранятся в репозитории и были изменены в рабочем каталоге , но к ним не была применена команда git add
- Untracked files - новые файлы, которые не включены в слепок(новые файлы которые никогда не присутствовали в репозитории).
- Для игнорирования файлов в разделе Untracked files используется файл .gitignore. Шаблоны:
- Пустые строки, а также строки, начинающиеся с #, игнорируются.
- Можно использовать стандартные glob шаблоны.
- Можно заканчивать шаблон символом слэша (/) для указания каталога.
- Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.
- Используется для
- добавления новых файлов
- добавления(индексации) измененных файлов в staging area
- Можно избежать использование команды для измененных файлов используя комманду git commit -a
- Сохранение изменений в локальном репозитории.
- Для комментирования можно использовать ключ -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%%
- Просмотр веток в репозитории
- * указывает ветку с которой вы сейчас работает
- ключ -v - дает информацию о последних коммитах каждой ветки.
- создание новой ветки на базе from_branch_name. Без переключения в нее.
- для переключения надо выполнить команду git checkout branch_name
- также можно создать и сразу перейти к ветке командой git checkout -b branch_name [from_branch_name]
- если from_branch_name не указан, новая ветка создается на базе текущей.
- удаление ветки
- git checkout branch_name - переключение на ветку branch_name. Перезаписывает файлы в рабочей директории.
- git checkout -b branch_name - создание и переключение на ветку branch_name.
- git checkout -- filename - перезаписывает файл в рабочем каталоге содержимым файла с последнего коммита из репозитория.
- Производит слияние веток.
- Вы должны находится в основной ветке в которую хотите влить изменения с branch_name_to_merge.
- Слияние, при которой все коммиты вашей текущей ветки попадают в ветку branch_name.
- Позволяет видеть историю работы последовательно.
- Результат работы аналогичен git merge
- *Внимание*. Не перемещайте коммиты, которые вы выложили в публичный репозиторий. То есть эта команда хороша только для работы с локальным репозиторием до push.
- Вам поступил звонок об критической ошибке на сайте:
- Вы работаете в ветке 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:)
- отредактировать эти файлы в рабочей папке. В них будут следующие секции: %%
- В верхней части(до ""======="") будет часть кода, которая находится в текущей ветке.
- В нижней части (после ""=======""), часть кода из ветки с которой вы пытаетесь слиться.
- Вам необходимо заменить данный блок на подходящий код.
- После того как вы отредактировали все файлы необходимо для каждого конфликтного файла сделать git add
- Окончательным шагом будет git commit - для завершения слияния.
- Получение репозитория с удаленного сервера для локальной работы:
- В каталоге где будет вести разработка: %%git clone git://github.com/schacon/grit.git mygrit%% *заменить на наш репозиторий*
- Эта команда
- создает каталог с именем «mygrit»
- инициализирует в нем каталог .git
- скачивает все данные для этого репозитория
- создает (git checkout) рабочую копию последней версии.
- Если вы зайдете в новый каталог mygrit, вы увидите в нем проектные файлы, пригодные для работы и использования.
- настройка удаленных репозиториев
- после 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
- вытягивает изменения c удаленного репозитория, но при этом не делает слияния
- создает ветку в вашем репозитории rep_alias/branch
- если rep_alias не указан, используется последний использованный
- если branch не указан - используется имя вашего текущего branch
- вытягивает изменения c удаленного репозитория(git fetch), при этом пытается сделать слияние с вашим репозиторием.
- если rep_alias не указан, используется последний используемый сервер
- если 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'
- Удаляет файл с локальной рабочей директории и из индекса.
- Перемещает/переименовывает файлы.
- Важно - история файла не сохраняется, так как команда фактически делает следующее:
- mv old_file new_file
- git rm old_file
- git add new_file
- Просмотр истории commit-ов
- Файлы конфигов
- без параметров в папке репозиория .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%%
Deletions:
- [[http://git-scm.com/book|Pro Git eng]]
- [[http://cloud.github.com/downloads/GArik/progit/progit.ru.pdf|Pro Git rus]]
- Распределенная система:
- В отличии от большинства систем при commit сохраняется слепок файловой системы, а не различия(diff) в файлах.
- Добавлять новые файлы нужно вручную:
- В Git файлы могут находиться в одном из трёх состояний:
- Три основных части Git проекта:
- Стандартный рабочий процесс с использованием Git выглядит примерно так:
==git status==
* Используемый для определения, какие файлы в каком состоянии находятся
* Changes to be committed: - файлы, которые будут помещены в репозиторий при следующем commit (добавляются через git add)
* Changed but not updated: - файлы, которые хранятся в репозитории и были изменены в рабочем каталоге , но к ним не была применена команда git add
* Untracked files - новые файлы, которые не включены в слепок(новые файлы которые никогда не присутствовали в репозитории).
* Для игнорирования файлов в разделе Untracked files используется файл .gitignore. Шаблоны:
* Пустые строки, а также строки, начинающиеся с #, игнорируются.
* Можно использовать стандартные glob шаблоны.
* Можно заканчивать шаблон символом слэша (/) для указания каталога.
* Можно инвертировать шаблон, использовав восклицательный знак (!) в качестве первого символа.
* Используется для
* добавления новых файлов
* добавления(индексации) измененных файлов в staging area
* Можно избежать использование команды для измененных файлов используя комманду git commit -a
* Сохранение изменений в локальном репозитории.
* Для комментирования можно использовать ключ -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%%
* Просмотр веток в репозитории
* * - указывает ветку с которой вы сейчас работает
* ключ -v - дает информацию о последних коммитах каждой ветки.
* создание новой ветки на базе from_branch_name. Без переключения в нее.
* для переключения надо выполнить команду git checkout branch_name
* также можно создать и сразу перейти к ветке командой git checkout -b branch_name [from_branch_name]
* если from_branch_name не указан, новая ветка создается на базе текущей.
* удаление ветки
* git checkout branch_name - переключение на ветку branch_name. Перезаписывает файлы в рабочей директории.
* git checkout -b branch_name - создание и переключение на ветку branch_name.
* git checkout -- filename - перезаписывает файл в рабочем каталоге содержимым файла с последнего коммита из репозитория.
* Производит слияние веток.
* Вы должны находится в основной ветке в которую хотите влить изменения с branch_name_to_merge.
* Слияние, при которой все коммиты вашей текущей ветки попадают в ветку branch_name.
* Позволяет видеть историю работы последовательно.
* Результат работы аналогичен git merge
* *Внимание*. Не перемещайте коммиты, которые вы выложили в публичный репозиторий. То есть эта команда хороша только для работы с локальным репозиторием до push.
* Вам поступил звонок об критической ошибке на сайте:
* Вы работаете в ветке 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:)
* отредактировать эти файлы в рабочей папке. В них будут следующие секции: %%
* В верхней части(до ""======="") будет часть кода, которая находится в текущей ветке.
* В нижней части (после ""=======""), часть кода из ветки с которой вы пытаетесь слиться.
* Вам необходимо заменить данный блок на подходящий код.
* После того как вы отредактировали все файлы необходимо для каждого конфликтного файла сделать git add
* Окончательным шагом будет git commit - для завершения слияния.
* Получение репозитория с удаленного сервера для локальной работы:
* В каталоге где будет вести разработка: %%git clone git://github.com/schacon/grit.git mygrit%% *заменить на наш репозиторий*
* Эта команда
* создает каталог с именем «mygrit»
* инициализирует в нем каталог .git
* скачивает все данные для этого репозитория
* создает (git checkout) рабочую копию последней версии.
* Если вы зайдете в новый каталог mygrit, вы увидите в нем проектные файлы, пригодные для работы и использования.
* настройка удаленных репозиториев
* после 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
* вытягивает изменения c удаленного репозитория, но при этом не делает слияния
* создает ветку в вашем репозитории rep_alias/branch
* если rep_alias не указан, используется последний использованный
* если branch не указан - используется имя вашего текущего branch
* вытягивает изменения c удаленного репозитория(git fetch), при этом пытается сделать слияние с вашим репозиторием.
* если rep_alias не указан, используется последний используемый сервер
* если 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'
* Удаляет файл с локальной рабочей директории и из индекса.
* Перемещает/переименовывает файлы.
* Важно - история файла не сохраняется, так как команда фактически делает следующее:
* mv old_file new_file
* git rm old_file
* git add new_file
* Просмотр истории commit-ов
* Файлы конфигов
* без параметров в папке репозиория .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%%

Revision [49]

Edited on 2017-02-26 07:11:40 by ace
Additions:
{{{toc}}}
Deletions:
{{toc}}

Revision [46]

Edited on 2017-02-26 06:47:38 by ace
Additions:
======Введение в 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==
Deletions:
==Введение в 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====

Revision [45]

Edited on 2017-02-26 06:39:50 by ace
Additions:
* В верхней части(до ""======="") будет часть кода, которая находится в текущей ветке.
* В нижней части (после ""=======""), часть кода из ветки с которой вы пытаетесь слиться.
Deletions:
* В верхней части(до =======) будет часть кода, которая находится в текущей ветке.
* В нижней части (после =======), часть кода из ветки с которой вы пытаетесь слиться.

Revision [44]

Edited on 2017-02-26 06:35:58 by ace
Additions:
* отредактировать эти файлы в рабочей папке. В них будут следующие секции: %%
<<<<<<< HEAD:index.html
Deletions:
* отредактировать эти файлы в рабочей папке. В них будут следующие секции:%%(html)<<<<<<< HEAD:index.html

Revision [41]

Edited on 2017-02-26 06:25:14 by ace
Additions:
==Введение в Git==

{{toc}}

Данная статья является выжимкой из книги 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:)
* отредактировать эти файлы в рабочей папке. В них будут следующие секции:%%(html)<<<<<<< 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%%
Deletions:
* [[Git/Introduce]]

Revision [40]

Edited on 2017-02-26 06:24:52 by ace
Additions:
* [[Git/Introduce]]
Deletions:
((Git/Introduce))

Revision [39]

The oldest known version of this page was created on 2017-02-26 06:24:40 by ace