README.md

Инструкции работы с системой версионирования кода Git

Автор статьи: Максим Соколовский

Оригинал: http://know.worksolutions.ru/articles/324/

Общая схема работы, взаимодействие репозиторев

Выполнение команд

Установка на Linux сервер (Ubuntu)

$ apt-get install git

Создание хранилища

Создает в текущем каталоге новый подкаталог с именем .git содержащий все необходимые файлы репозитория — основу репозитория Git. На этом этапе проект еще не находится под версионным контролем. Для версионирования необходимо совершить фиксацию изменений.

$ git init

Создание локальной копии хранилища

Cоздает каталог с именем catalog, инициализирует в нем каталог .git, скачивает все данные для этого репозитория и создает (checks out) рабочую копию последней версии. Если вы зайдете в новый каталог catalog, вы увидите в нем проектные файлы, пригодные для работы и использования. Автоматически добавляет этот удалённый (центральный) репозиторий под именем origin.

$ git clone git://github.com/worksolutions/bitrix.git catalog

Настройка работы с центральным хранилищем

Вывод списка удаленных репозиториев. Например:

$ git remote -v

Добавление удаленного репозитория:

$ git remote add origin git://github.com/ws/project.git

Получение изменений из центрального хранилища

Связывается с центральным хранилищем и забирает все те данные проекта, корорых ещё нет. После выполнения команды должны появиться ссылки на все ветки из этого удалённого проекта. Теперь эти ветки в любой момент могут быть просмотрены или слиты.

$ git fetch

Производит слияние полученного кода центрального хранилища с локальной версией, возможны конфликты слияний, которые необходимо будет решать при помощи редактирования конфликтных файлов

$ git merge

Одновременное выполнение команд (fetch, merge)

$ git pull

Внесение изменений в локальное хранилище

Основная команда проверки состояния текущего репозитория. Вывод индексированных файлов, файлов отмеченных на удаление, предупреждение о наличие неверсионируемых файлов, и т.д.

$ git status

Добавляет под версионный контроль файлы, для индексации изменений. Зарепляет перечень и состояние файла для последующей фиксации.

$ git add <<относительный путь>>

Произведение фиксации индексированных ранее файлов в локальное хранилище

$ git commit -m "сообщение фиксации"

Индексирует файл/файлы по пути на удаление

$ git rm <<относительный путь>>

Отмена индексации файлов

$ git reset HEAD <<относительный путь>>

Показ изменений между проиндексированными и не проиндексированными файлами

$ git diff

Просмотр истории фиксаций [x] - количество последних фиксаций

$ git log -[x]

Отмена изменений файла. Использовать до фиксациии

$ git checkout <<относительный путь>>

Отправка изменений локального хранилища в центральное

Отправляет локальные изменения кода в центральное хранилище. Изменения не будут отправлены в случаях когда в центральном хранилище есть фиксации, которые не существуют в локальном, тогда нужно будет обновить локальное хранилище и затем попробовать обновить центральное.

$ git push

Решение конфликтов слияния в случае если СУРВ (Git) не способна самостоятельно актуализировать код. Конфликты происходят при выполнении команды слияния (merge). Необходимо отредактировать конфликтные файлы (Список доступен в выводе командной строки), проиндексировать изменения и произвести фиксацию корректировки конфликта (commit)

$ git push -u origin master

Отправка локальных изменений с указанием хранилища и ветки как upstream. Данные, которые будут посланы с помощью git push без указания хранилища и ветки будут отосланны в upstream.

Определение игнорируемых файлов

Для игнорирования индексации изменений определенных файлов необходимо создать файл .gitignore, где определить относительные пути игнорирования изменений. Файл этот должен находится под версионированием системы.

Вывод списка локальных веток

$ git branch

Вывод списка всех веток включая центральный репозиторий

$ git branch -a

Создает локальную ветку iss553.

$ git branch iss53

Переход в локальную ветку. Код рабочей копии соответствует версии ветки iss53

$ git checkout iss53

Обратный переход в ветку master

$ git checkout master

Создает локальную ветку iss553 и осуществляет переход в нее.

$ git checkout -b iss54

Обновление текущей ветки изменениями ветки master

$ git merge master

Обновляет текущую ветку изменениями ветки iss54

$ git merge iss54

Удаление ветки iss53

$ git branch -d iss53

Интеграция созданной ветки в основную версия проекта

Переход в локальную ветку. Код рабочей копии соответствует версии ветки iss53. Тут производится фиксация изменений ветки.

$ git checkout iss53

Слияние изменений основной ветки в текущую (iss53)

$ git merge master

Переход в ветку master.

$ git checkout master

Слияние основной версии (master) с новой iss53

$ git merge iss53

Обновление production сервера.

Для обновление рабочей версии кода необходимо: Выложить изменения (актуализировать) центральное хранилище (push c локальной копии) По ssh production сервера произвести обновление (pull) production копии хранилища

Использование отладочных средств

Просмотр когда и кем каждая строка метода была в последний раз отредактирована

$ git blame -L 0,14 simplegit.php

Запуск процесса бинарного поиска

$ git bisect start

Определение текущего состояния хранилища как “неисправное”

$ git bisect bad

Определение момента исправного состояния хранилища

$ git bisect good <номер фиксации>

Определение исправности версий поиска

$ git bisect (bad|good)

Сброс поиска. Хранилище возвращается в актуальное состояние

$ git bisect reset

Общие понятия

Именование коммитов (фиксаций) кода

Именование фиксации должно начинаться с контекста выполнения, продолжается действием относительно определенного контекста (т.е. непосредственно что сделано). Если фиксация напрямую касается контекста, действие можно “опустить”, например - добавлена детальная страница новостей.

Контекстом выполнения могут быть (в скобках примеры):

• Компонент, шаблон компонента (Компонент списка новостей, внедрение постраничной навигации)
• Шаблон сайта (Шапка сайта добавление компонента авторизации пользователя)
• Модель предметной области. (Модель новости. Добавление метода форматирования даты создания)
• Обработчик (обработка) события. (Обработчик события регистрации пользователя. Начисление бонусов. Правка связанная с правильным начислением копеек)
• Контроллер. (Контроллер новостей. Определение действия вывода списка)
• Выполнение поставленной задачи. (7641. Добавление списка новостей. Определение страницы со вставкой компонента news.list)

Работа с ветвлением в рамках проекта

Ветвление необходимо прежде всего для параллельной работы над разными областями проекта, либо при наращивании функционала когда основная ветка поддерживается актуальном состоянии (такая же как на боевом сервере).

Рассмотрим несколько примеров работы с ветками:

• Сборка нового проекта Интернет магазина. Работают два программиста над разными областями функционала, 1-й работает с каталогом товаров, 2-й реализует функционал личного кабинета покупателя. При этом определено, что появление каталога товаров должно быть ранее чем личный кабинет, а 1-й программист затем подключится к реализации личного кабинета. В этом случае кроме основной ветки master создать две соответствующие тематикам реализуемого функционала, например catalog и account. По завершению работы с каталогом необходимо обновить основную ветку master, затем обновить непосредственно рабочий проект, так на сайте появляется каталог и визуально никаких предпосылок появления личного кабинета нет. 1-й программист переключается в ветку account для работы с личным кабинетом и через время основная версия продукта “разом” приобретает личный кабинет. Таким образом в этом случае ветки необходимы для локализации выполнения большой задачи, когда работа на проектом идет параллельными курсами.

• Поддержка большого проекта. В таком случае важную роль играет быстрое исправление ошибок или выполнение срочных задач, при этом есть основной поток разработки. Так программисты основную работу по наращиванию функционала должны производить в параллельных ветках, а быстрые исправления или срочные задачи в основной master для немедленного обновления рабочей версии проекта.