При работе с git под windows не покидало ощущение, что чего-то не хватает, не столь комфортно с ним работать как на других системах.
Оказывается, в msysgit по умолчанию отключен цветной вывод.

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

Мне давно хотелось отсматривать код примерно как это сделано в 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 хука post-commit для отправки информации о коммите, на указанный в сообщении коммита емайл, по средствам msmtp(обычно он идет в комплекте msysGit).

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

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

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

Во всем множестве статей по git'у, которые я смог найти в сети, не хватает одного существенного момента — описания командной работы. То, что обычно описывают как командную работу, на самом деле является просто работой с удаленным репозиторием.

Ниже я хочу описать свой опыт командной работы над проектом с использованием git'а.

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

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

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

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

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

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