Просмотр кода страницы UsesGit

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


__TOC__


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



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



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

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



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



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

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

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



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



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



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

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

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





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



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

<pre>git checkout -b eterhack origin/eterhack</pre>

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



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

<pre>$ git branch

  eter-1.0.9

* eterhack

  pure</pre>





==== Назначение веток в 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:

<pre>$ git checkout master

Already on branch "master"

[lav@builder wine]$ git-checkout eterhack

Switched to branch "eterhack"</pre>



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

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



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

 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 задаёт сохранение данных в файле <tt>~/.gitconfig</tt>, применяемый для всех репозиториев. Без --global настройки будут сохранены в текущем репозитории (.git/config).

<!--Для отправки патчей в рассылку wine-patches@winehq.org следует задать суффикс .txt для файлов с патчами, чтобы их можно было нормально извлекать из архива (это ошибка в mailman).

<pre>git config format.suffix .txt</pre>-->


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


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

<div style="display: inline; color: red;">Это не требуется при использовании скрипта update_eterbranches.sh</div>

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

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

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

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



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

<pre>git remote -v</pre>



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

<pre>git branch -r</pre>



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

<pre>git checkout -b eter-1.0.9 origin/eter-1.0.9

git pull</pre>





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

<pre>$ git checkout master

$ git pull origin master</pre>



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



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

<pre>git checkout eterhack

git merge master</pre>



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

<pre>git checkout master

git cherry-pick COMMIT-ID</pre>



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



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

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



<pre>$ ssh git.eter init-db packages/wine.git</pre>

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



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



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

<pre>git remote add origin git.eter:packages/wine.git</pre>

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



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

<pre>$ git push origin</pre>



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



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



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



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

<pre>git remote add sin git.eter:/people/sin/packages/wine.git

git fetch sin

git checkout -b sinhacks sin/hacks

git pull</pre>

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

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

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



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



<pre>$ 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</pre>



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

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



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

<pre>git checkout название_файла</pre>



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

<pre>git checkout -f</pre>



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

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

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

<pre>git stash</pre>

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

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

<pre>git stash apply</pre>

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



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

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

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

<pre>git commit --amend файл</pre>



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

<pre>git reset --hard HEAD^</pre>



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

<pre>git revert HEAD</pre>



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

<pre>git revert COMMIT</pre>



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



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

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

<pre>git rebase -i HEAD~5</pre>

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

<div style="display: inline; color: red;">нельзя менять коммиты, которые вы уже опубликовали, это приведёт к проблемам при дальнейшей публикации</div>



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

<div style="display: inline; color: red;">Опасно</div>

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

<pre>git reset --hard COMMIT</pre>

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



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



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

<pre>git diff [файл]</pre>



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

<pre>git diff pure master</pre>



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

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

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

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

<pre>git blame -L 10,19 -C файл</pre>



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



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

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

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



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

Редактор vi не имеет интуитивно-понятный интерфейс, но к нему есть [http://freesource.info/wiki/VI краткая инструкция].



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



<pre>git format-patch ID</pre>

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



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

<pre>git log</pre>

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

<pre>commit 53333771aae4888ee2e8373cec0abb06e3d1c290

Author: sergeym <sergeym@etersoft.ru>

Date:   Sat Mar 17 15:29:26 2012 +0400</pre>



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

<pre>git format-patch -n ID</pre>

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

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



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

<pre>git format-patch -n --subject-prefix=eterhack ID</pre>

Получится

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



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

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



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

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

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

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



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

<pre>git bisect start</pre>



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

<pre>git bisect good wine-1.0</pre>



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

<pre>git bisect bad wine-1.1.1</pre>



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

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

<pre>git bisect bad</pre>



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

<pre>git bisect visualize</pre>



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

<pre>git bisect reset</pre>



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

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

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

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

<pre>git checkout -b tmp</pre>

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

<pre>git merge eterhack</pre>

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



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

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

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

<pre>git checkout -b tmp</pre>

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

<pre>git reset  --hard [id of bad commit]</pre>

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

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

<pre>git rebase -i [id of good commit]</pre>

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

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

<pre>git rebase --skip</pre>

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

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

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

<pre>git merge eterhack</pre>

и можно применять 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 файл_с_авторами,

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

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



Например,

<pre>vitlav = Vitaly Lipatov <lav@etersoft.ru>

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



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

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

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

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





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



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

<pre>git remote add eter git.eter:/people/lav/packages/wine.git</pre>



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

<pre>$ git remote -v

eter    git.eter:packages/wine.git</pre>



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


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

<pre>
$ git checkout -b eter-1.0.9 wine-0.9.59

Switched to a new branch "eter-1.0.9"
</pre>



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


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

<pre>
$ 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 -"
</pre>

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


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

==== Другая наша документация по git ====
* [[UsesGear|Gear-оводство]]
* [[UsesGitEtersoft|Особенности использования git.etersoft.ru]]



==== ALTLinux at [http://freesource.info/ FreeSource] ====
* [http://www.altlinux.org/Git Using git.altlinux.org]
* [http://freesource.info/wiki/RuslanHihin/gitusermanual Хорошее описание работы с git на русском языке]



==== Русскоязычные описания работы с Git ====
* [http://progit.org/book/ru/ Проект Про Git]
* [http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/ru/ Волшебство Git]
* [http://githowto.com Интерактивный тур - Git How To]
* [https://habrahabr.ru/company/Voximplant/blog/276695/ Как оформлять коммиты]
* [http://www.ibm.com/developerworks/ru/library/l-git_1/ IBM Developerworks, Часть 1]
* [http://www.ibm.com/developerworks/ru/library/l-git_2/ IBM Developerworks, Часть 2]
* [http://blog.nsws.ru/rabota-s-git-dlya-nachinayushhix.html Git для начинающих]
* [http://habrahabr.ru/blogs/Git/75728/ Полезные советы по Git]
* [http://gq.net.ru/2009/12/16/git-history-rewrite/ Редактирование истории (Максим Чистолинов])

==== Англоязычные описания работы с Git ====
* [http://wiki.winehq.org/GitWine Аналогичная документация по разработке Wine (на англ.])
* [http://wiki.winehq.org/GitBranches Work with Git branches]
* [http://wiki.winehq.org/HackingTips HackingTips - Manage Wine Sources with Git]
* [http://tomayko.com/writings/the-thing-about-git The Thing About Git]



==== Kernel developers resources ====
* [http://lkml.org/lkml/2005/5/26/11/index.html LKML quick-start]
* [http://www.linux-ntfs.org/doku.php?id=howto:git Using Git with NTFS kernel driver repositories]
* [http://lwn.net/Articles/210045/ Branching and merging with git]



==== Other developers resources ====

* [http://git.or.cz/ Basic Git site with documentation]
** [http://www.kernel.org/pub/software/scm/git/docs/tutorial.html Original Git tutorial]
** [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday Git]
* [http://wiki.samba.org/index.php/Using_Git_for_Samba_Development Using Git for Samba Development]
* [http://utsl.gen.nz/talks/git-svn/intro.html git-svn for Subversion users]
* [http://wiki.sourcemage.org/Git_Guide SourceMage Git Guide]
* [http://evasive.ru/git_kung-fu.html Многопользовательская работа с git]
* [http://githowto.com интерактивный тур на русском]