UsesGit

Использование Git для разработки в Etersoft

Установка Git и настройки пользователя

Если в вашей системе ещё нет команды git, то установите пакет git (версии 1.5 и выше) штатным для системы образом (apt-get install git).

Для работы с сервером git.etersoft.ru следует добавить в ssh псевдоним для него (файл ~/.ssh/config).

Подробное описание находится на странице http://wiki.office.etersoft.ru/devel/info

Клонирование репозитория

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

Например, для WINE@Etersoft нужно выполнить такую команду:

git clone git.office:/projects/wine/eterhack.git wine-etersoft-public

где wine-etersoft-public - это локальный каталог, где будет создан репозиторий (указывать не обязательно).

Репозиторий следует создавать в каталоге /Projects.

Команда для получения публичного репозитория:

git clone http://git.etersoft.ru/projects/wine/eterwine.git wine-etersoft-public

Подробнее о репозиториях см. на http://winehq.org.ru

Ветки репозитория и их использование

После клонирования репозитория нужно получить ту ветку, с которой вы собираетесь работать:

git checkout -b eterhack origin/eterhack

Это добавит ветку eterhack и переключит в неё.

После этого с помощью команды git branch можно увидеть имеющиеся ветки:

$ git branch

  eter-1.0.9

* eterhack

  pure

Назначение веток в eterwine

pure - ветка с оригинальным Wine, она синхронизируется с оригинальным репозиторием. Не создавайте коммиты в этой ветке, не изменяйте её.

master - основная ветка нашей разработки (регулярно мержится с pure), туда мы коммитим изменения, которые могут быть у нас приняты в оригинальный Wine.

Назначение веток в eterhack

eterhack - нестабильная ветка, которая мержится с eterwine/master и которая является нашей текущей веткой для разработки WINE@Etersoft. Сюда помещаются патчи, которые не могут быть приняты в оригинальный Wine (аналог patches/hack), но которые подходят для всех проектов.

eter-1.0.11 - ветка разработки текущего релиза WINE@Etersoft. В неё попадают изменения, специфичные для конкретного релиза.

Таким образом, eterhack по сравнению с eterwine/master дополнен нашими хаками.

Переключение между ветками

Для переключения между ветками используется команда git-checkout:

$ git checkout master

Already on branch "master"

[lav@builder wine]$ git-checkout eterhack

Switched to branch "eterhack"

Управление репозиториями

Настройка репозитория

Для того, чтобы Ваше имя и адрес почты были корректными, их следует явно задать (Имя Фамилию — на английском):

git config --global user.name "Your full Name"
git config --global user.email "login@etersoft.ru"

например,

git config --global user.name "Ivan Ivanov"
git config --global user.email "iv@etersoft.ru"

Ключ --global задаёт сохранение данных в файле ~/.gitconfig, применяемый для всех репозиториев. Без --global настройки будут сохранены в текущем репозитории (.git/config).

При отправке в англоязычную рассылку обратите внимание, чтобы профиль в вашем почтовом клиенте был заполнен также на английском, чтобы в рассылке поняли как вас зовут :)

Обновление репозитория

Это не требуется при использовании скрипта update_eterbranches.sh

Для удобства работы стоит добавить всех удалённые репозитории, с которыми мы собираемся работать.

Добавить репозиторий можно командой

git remote add название git.eter:/people/sin/packages/wine.git

которой указывается желаемое название репозитория и путь к нему.

Посмотреть имеющиеся репозитории можно командой

git remote -v

Посмотреть ветки удалённого репозитория:

git branch -r

Для получения ветки из удалённого репозитория нужно создать ветку у себя и получить туда изменения, например для eter-1.0.9:

git checkout -b eter-1.0.9 origin/eter-1.0.9

git pull

Любую ветку можно обновить отдельно:

$ git checkout master

$ git pull origin master

Синхронизация веток

Синхронизация веток (если внесены изменения в master, которые хотелось бы тут же увидеть в eterhack):

git checkout eterhack

git merge master

Перенос отдельного коммита из другой ветки (если в eterhack внесено изменение, которое нужно перенести в master):

git checkout master

git cherry-pick COMMIT-ID

Публикация репозитория

Чтобы другие могли получить доступ к вашим изменениям, их нужно опубликовать на git.etersoft.ru.

Перед первой публикацией на удалённом сервере нужно инициализировать репозиторий командой

$ ssh git.eter init-db packages/wine.git

Эта команда создаст пустой репозиторий с указанным названием.

Конечно, для этого потребуется аккаунт на git.etersoft.ru. Пишите на support@etersoft.ru

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

git remote add origin git.eter:packages/wine.git

где origin — сокращённое название репозитория, используется по умолчанию.

Далее для передачи обновлений выполняем каждый раз

$ git push origin

Удаление ветки из удалённого репозитория

$ git push git.eter:packages/wine.git :ненужный_branch

Получение изменений из другого репозитория

Предположим что пользователь sin в репозитории wine.git ведёт ветку hacks, изменения в которой нам хотелось бы получить.

git remote add sin git.eter:/people/sin/packages/wine.git

git fetch sin

git checkout -b sinhacks sin/hacks

git pull

1. добавляем удалённый репозиторий, называя его sin

2. получаем изменения из удалённого репозитория sin

3. создаём новую ветку sinhacks на основе ветки hacks удалённого репозитория sin

Просмотр изменений в другом (удалённом) репозитории

$ git remote show vostok

* remote vostok

  URL: git.eter:/people/vostok/packages/wine.git

  New remote branches (next fetch will store in remotes/vostok)

    eter-1.0.9 eterhack master pure

$ git diff vostok/master

Внесение изменений

Откат локальных изменений

Для отката изменённого/удалённого файла к тому состоянию, в каком он в репозитории:

git checkout название_файла

Откат всех локальных изменений в репозитории:

git checkout -f

Cкрытие локальных изменений

Часто возникает ситуация, когда необходимо обновиться до последней версии, но при этом не хочется терять локальные изменения.

Для этого существует комманда:

git stash

Она сохраняет все незакоммиченные изменения и сбрасывает текущее положение до HEAD.

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

git stash apply

она вернёт все прежние изменения

Отмена (последнего) коммита

Исправление последнего коммита.

Исправьте файл. Запустите

git commit --amend файл

Возврат после неудачного коммита (удаляет последний коммит без следов)

git reset --hard HEAD^

Создание отменяющего коммита (создаётся ещё один коммит, отменяющий последнее изменение)

git revert HEAD

Чтобы откатить определённый коммит:

git revert COMMIT

Изменение порядка коммитов

Если последние коммиты имели несколько беспорядочный характер, и вы решили изменить их порядок, изменить,

объединить или удалить, то нужно использовать rebase:

git rebase -i HEAD~5

эта команда продолжит вам поменять последние 5 коммитов.

нельзя менять коммиты, которые вы уже опубликовали, это приведёт к проблемам при дальнейшей публикации

Откат до определённого коммита

Опасно

Чтобы вернуть репозиторий в состояние, которое было после определённого коммита, нужно знать ID этого коммита (COMMIT).

git reset --hard COMMIT

При это все последующие коммиты будут уничтожены.

Просмотр изменений

Просмотр локальных изменений (незакоммиченных):

git diff [файл]

Сравнение разных веток:

git diff pure master

Выявление автора строк

В простейшем случае, чтобы узнать коммит и автора, внёсшего строки в файл, достаточно запустить git blame файл.

Для ускорения можно сразу указать диапазон строк. При использовании параметра -C будет указано происхождение строк,

даже если они первоначально были внесены в другой файл.

git blame -L 10,19 -C файл

Внесение(коммит) изменений

Изменения вносятся командой git commit, которая без параметров вносит изменения только тех файлов, для которых был повторно выполнен git-add.

Более привычной будет команда git commit -a, которая создаёт коммит для всех ранее отслеживаемых и изменённых файлов. Обратите внимание, что коммит будет выполнен для всех изменённых файлов в репозитории.

Также можно воспользоваться командой git commit название_файла, которая внесёт изменения в указанных файлах.

Команда git commit вызывает текстовый редактор (обычно vi) для редактирования комментария к коммиту.

Редактор vi не имеет интуитивно-понятный интерфейс, но к нему есть краткая инструкция.

Создание патчей

git format-patch ID

ID - идентификатор предыдущего коммита. Коммиты, более новые, чем указанный, будут записаны в файлы.

Посмотреть сделанные коммиты можно через

git log

Пример, в первой строчке - ID коммита:

commit 53333771aae4888ee2e8373cec0abb06e3d1c290

Author: sergeym <sergeym@etersoft.ru>

Date:   Sat Mar 17 15:29:26 2012 +0400

Если надо, чтобы в тему письма включался номер патча в серии, можно использовать параметр -n:

git format-patch -n ID

В результате получится нечто вроде

Subject: [PATCH 02/22] hal: Add stub for HalTranslateBusAddress.

Слово патч можно заменить на любое другое с помощью параметра --subject-prefix:

git format-patch -n --subject-prefix=eterhack ID

Получится

Subject: [eterhack 02/22] hal: Add stub for HalTranslateBusAddress.

Сгенерированные патчи можно отправить по почте с помощью команды

git send-email --from 'Your Name <yourname@etersoft.ru>' --to 'wine-patches@lists.etersoft.ru' 0*.txt

Регрессивное тестирование

Использование git bisect

Git bisect позволяет методом бинарного поиска определять коммит, создающий ошибку

Допустим есть 2 версии исходников: версия в которой ошибка отсутствует и версия с ошибкой. После запуска git bisect делает несколько шагов, каждый раз спрашивая присутствует ли ошибка в текущей версии. В итоге за минимальное число шагов удаётся найти коммит, создающий ошибку.

Инициализация поиска

git bisect start

Сообщаем, что в версии wine-1.0 ошибки нет

git bisect good wine-1.0

Сообщаем, что в версии wine-1.1.1 ошибка присутствует

git bisect bad wine-1.1.1

Далее bisect находит середину, и шагает в это место. Требуется перекомпилировать исходники (configure && make) и запустить тест.

Сообщаем, что ошибка всё ещё есть (или good если её уже нет)

git bisect bad

Для большей наглядности можно использовать графическое представление дерева

git bisect visualize

Для возврата к исходному состоянию

git bisect reset

Особенности использования git bisect в ветке eterhack

При использовании git bisect в ветке eterhack возникает следующая проблема: между мержами находятся патчи из ветки pure. Git bisect перескакивая на них оказывается в ветке pure и игнорирует патчи из eterhack.

Для решения этой проблемы патчи из pure и eterhack должны быть в одной ветке. Для этого нужно:

1) Сделать временную рабочую ветку (чтобы не портить текущий репозиторий) - cкопировать ветку pure. Для этого находясь в pure надо выполнить

git checkout -b tmp

2) смержить eterhack во временную ветку:

git merge eterhack

После этого коммиты из ветки pure и eterhack окажутся в одной ветке, и можно будет пользоваться git bisect.

Возникает серьёзная проблема, если между коммитом, где бага уже присутствует (bad commit), и коммитом где баги ещё нет(good commit) текущая версия не собирается, а патч исправляющий данную ошибку находится выше bad commit.

Решить её можно следующим способом:

1) Сделать временную рабочую ветку (аналогично предыдущему случаю)

git checkout -b tmp

2) Для экономии времени и нервов, откатиться до bad commit (версии, где бага уже присутствует).

git reset  --hard [id of bad commit]

3) Приложить патч, исправляющий ошибку компиляции

4)Опустить его в самый низ, ниже коммита, где ошибки ещё нет. Для этого выполнить

git rebase -i [id of good commit]

и в текстовом редакторе поднять соответствующий коммит наверх (там порядок следования коммитов обратный).

После этого начнётся rebase дерева. По ходу процесса могут возникать конфликты. Думаю бесполезно их все исправлять, можно их пропускать:

git rebase --skip

Остаётся надеятся что конфликты ни на что не повлияют.

Далее остаётся только:

5) смержить eterhack во временную ветку:

git merge eterhack

и можно применять git bisect

Другой вариант, который мы пробовали: начиная с места, про которое известно, что там программа работала, сделать git format-patch.

Полученные патчи применить в новой ветке, начатой от место, где всё работало (через git am). Получаем чистую ветку, в которой можно делать проверку.

Конвертирование из CVS

Если репозиторий (описание коммитов) не в UTF-8, нужно установить кодировку:

$ git config --global i18n.commitencoding koi8-r

И выполнить

$ git cvsimport -p x -v -d :ext:cvs.etersoft:/var/local/cvsroot РЕПОЗИТОРИЙ

в созданном для нового репозитория каталоге

Если в дальнейшем вы планируете делать описания в кодировке UTF-8, отмените задание кодировки:

$ git config --global --unset i18n.commitencoding

Для того, чтобы корректно сконвертировать авторов коммитов, нужно добавить файл трансляции авторов при импорте ключом -A файл_с_авторами,

в котором каждая строка имеет формат:

[имя в CVS] = [полное имя] <[адрес email]>

.

Например,

vitlav = Vitaly Lipatov <lav@etersoft.ru>

phantom = Phantom Ghostly <ph.gh@mail.net>

Работа в Git при том, что майнстрим в SVN

1. cd strigi && git svn init https://svn.kde.org/home/kde/trunk/kdesupport/strigi

2. запускаем git svn fetch [ -rREVISION ] для скачивания исходного дерева

3. git svn rebase для внесения изменений из svn в рабочую ветку

Псевдонимы для удалённых репозиториев

Для удобства работы можно создать псевдоним для репозитория:

git remote add eter git.eter:/people/lav/packages/wine.git

Посмотреть имеющиеся всевдонимы:

$ git remote -v

eter    git.eter:packages/wine.git

Тонкости создания веток

Создание ветки на основе тега wine-0.9.59:

$ git checkout -b eter-1.0.9 wine-0.9.59

Switched to a new branch "eter-1.0.9"

Настройка вывода патчей и статуса

В некоторых системах в git не настроен вывод цветных патчей, например, в Fedora. Для включения этих возможностей используйте команды:

$ git config --global color.diff no
$ git config --global color.status auto
$ git config --global color.branch auto
$ git config --global core.editor vim
$ git config --global core.pager "vim -"

Эти команды включают использование цвета в diff, status и branch, устанавливают редактором по умолчанию и просмотрищиком патчей vim. Так как vim сам подсвечивает патчи, то гитовую расцветку надо выключить.