Git *

Вместо предисловия...

Мне давно хотелось отсматривать код примерно как это сделано в meld, но только в консоли, и еще мне хотелось чтобы это все было увязано с системой управления версиями файлов GIT. В общем чтобы все делалось 1 кнопкой не выходя из mc.

Ydiff

Однажды у нас на канале (или это было на траке...) проявился некто Daniel Borca пошумел-пошумел и убежал, видимо не понравилась ему наша бюрократия, но зато оставил он после себя несколько сыроватых патчей, к готовившемуся релизу 4.7.0-pre1 миднайт коммандера. Один из них содержал в себе ydiff.[ch] и zdiff.[ch]… Как оказалось, то что я хотел получить, было давно уже реализовано в древнем форке mc-mp и в последней версии ru-fork. После 2-х дневного «перепиливания» я подключил функцию сравнения файлов к последней версии mc… Полдела было сделано. :)

Я, как и многие программисты, после знаменитого выступления Линуса Торвальдса о Git на Google Talks заинтересовался распределенными системами управления версиями, а в особенно Git.

Я довольно таки свободно читаю на английском, но мне приятнее читать на русском языке, при условии нормального перевода.
Существует замечательная книга «Git Magic» Бена Лина (Ben Lynn).
Благодаря труду многих людей вышел первый черновой вариант этой книги. Всех желающих улучшить перевод — приглашаю под кат.

Уже было несколько статей, где авторы рассказывали о том как скрасить консольные будни с git. В последней приведенной ссылке автор предлагает создавать алиасы, для работы c git, непосредственно в shell. Это не очень хороший способ, хотя бы потому, что, например алиас gc будет конфликтовать с одноименной командой пакета graphviz. git сам прекрасно умеет работать с собственным алиасами.

Недавно знакомый Андрей (совсем недавно перешел на программирование под линукс) хотел создать новую ветку в git-е, но не был уверен в параметрах и хотел посмотреть подсказку. Он выполнил комманду с логичными, как ему показалось, параметрами:

git checkout -b --help

Как думаете что сделала эта комманда? Правильно, создала ветку с именем --help=)

Switched to a new branch '--help'

Ну не проблема, удалим её.

git checkout master
Switched to branch 'master'
git branch -d --help

Но не всё так просто. Результатом последней комманды был вывод помощи по утилите git branch.

Хм. Ладно, попробуем переименовать ветку и затем удалить ее.

git branch -m --help todo_remove

И как вы уже догадались, эта комманда тоже напечатала краткую помощь по использованию git branch.

А вы сходу придумаете как удалить её?

Как избавится от ветки и неожиданое продолжение истории под катом.

Это продолжение статьи ХХ полезных советов для пользователей Git среднего уровня

Про reset, незапланированно снова про альясы, про замечательный filter-branch, про мерджи и разрешение конфликтов с помощью rerere, про rebase (интерактивный и не очень) и, в завершение, про обслуживание своей гитницы.

Давным-давно я усвоил, что зависимости должны храниться вместе с кодом проекта. Тогда, при возврате к старой версии кода, гораздо проще восстанавливать окружение.

У моего проекта несколько зависимостей. Бóльшая часть зависимостей живет в гитовых репозиториях. Сам проект тоже живёт в гите.

Одна из используемых нами библиотек часто обновляется. Мы сидим на девелоперской версии, и нередко сами контрибутим в неё код, который требуется нашему проекту. То есть требуется оперативно пропускать наши правки через основной репозиторий этой библиотеки — создавать и поддерживать свой форк по ряду причин совершенно не хочется.

Раньше я просто копировал зависимости в папку проекта, и добавлял к каждой файл VERSION.TXT с её версией. Но, если нужно работать с текущей версией стороннего кода, это неудобно. Да и копировать файлы руками когда есть гит как-то глупо. Хочется найти более современное решение.

Вообще-то изначально я планировал перевести статью Энди Джеффриса (Andy Jeffries) 25 Tips for Intermediate Git Users, но в процессе я отбросил бестолковые, общеизвестные или самые простые советы вроде «настройте первым делом user.name и user.email», которые явно не подходят людям, уже более-менее плотно знакомым с Git.
Взамен я дополню статью моментами из личной практики («Своя практика»! Звучит здорово, будто я частный врач или адвокат! :-] )

Для того чтобы познакомиться с механизмом хуков в git, достаточно просто начать их использовать и посмотреть как оно работает, и как оно устроено внутри.
Хуки в git это некие скрипты, срабатывающие на определенные события, по сути своей являются их обработчиками. Расположены они в каталоге .git/hooks.

Проблемы с русскими символами в git

Когда вы начнете работать с версией git под windows в командной строке, вы столкнётесь со следующей проблемой — все сообщения git, в которых фигурируют русские символы будут нечитаемы. Имена файлов, на русском языке, будут выглядеть так — "\362\345\361\362", а тексты коммитов примерно так — <C8><ED><E8><F6><E8><E0><EB><E8><E7><E0><F6><E8><FF> <EF><F0><EE><E5><EA><F2><E0>. Т.е. исходная строка преобразуется в utf8 в соответствии с кодировкой latin1.

1 Введение

В своей прошлой заметке я постарался осветить в общих чертах стиль работы с
распределенной системой контроля версий git и указать на отличия по сравнению с
классическими централизованными СКВ. Целью было прежде всего обобщение опыта
работы с системой без упоминания тонкостей синтаксиса отдельных команд.

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

1 Вступление

В топике освещаются не столько подробности работы с git, сколько его отличия от схемы разработки других систем контроля версий, и общий подход (выработанный по большей части личным опытом и Git Community Book) к работе.

Продолжая статьи о Git, распределенной системе контроля версий, с помощью которой ведется разработка таких проектов как Linux и Ruby on Rails, хотелось бы сказать и несколько слов о работе с ним под Windows.

Официального порта Git под Windows нет, есть mingw+msys порт по адресу code.google.com/p/msysgit/downloads/list

Как-то понадобилось написать проект на ruby под Windows — возникла проблема с виндовым переносом строки, который вставлялся во все файлы автоматически, вследствие чего проект не работал вообще. Оказалось, что для исправления нужно подправить gitconfig, в котором разработчики msysgit предусмотрительно вставили автопостановку CRLF.

Отключается она элементарной правкой gitconfig (можно найти в папке C:\Program Files\Git\etc), меняем содержимое секции core на следующее:

[core]
autocrlf = false
symlinks = false

Надеюсь, совет окажется многим полезным :)

Я встречал в сети много tutorial'ов по установке своего сервера git как на gitweb, так и на webdav, но, увы, они либо были только по одному из вышеназванных пунктов, не освещая другой, либо банально не работали. Вчера возникла необходимость поднять свой сервер репозиториев. Потратил пару часов — поднял, теперь хочу поделиться опытом, потому что считаю проблему актуальной :)