Git *

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

Я давно уже начал писать эту статью, но меня опередили (8.
Основная задумка была объяснить братьям флэшерам как работать с git. В статье я попытался описать свой личный опыт, а не просто перечислить очевидные плюсы git. Поэтому она будет полезна всем.

В первую очередь буду рад дополнениям и исправлениям. И конечно же вопросам.

Что такое git

git — это распределенная система контроля версий. Отличается от SVN отсутствием необходимости в центральном репозитории (который все же хорошо было бы держать) и легкостью работы с ветками (branch). Изначально я решил попробовать его в работе прочитав эту статью, что всем рекомендую.

У себя в компании я смог перевести клиентскую разработку на git и до сих пор не пожалел ни минуты. Время от времени я натыкаюсь на споры по поводу какая система контроля версий лучше, часто приходится объяснять чем все-таки мне нравится git.

Было время, когда я ничего не знал про VCS, ни что это такое, ни тем более зачем это мне. И верхом своих достижений считал папочку с архивами версий. К моменту осознания необходимости системы контроля версий я уже набил шишек и прочувствовал необходимость такого инструмента. Но борландовский аналог CVS меня не впечатлил. У каждого файла свой номер версии. Как мне получить срез определенного релиза я так и не разобрался. А в это время SVN победоносно шла сквозь умы разработчиков. Черт, это было то, чего мне так не хватало. Прочитав доку и начав работать я просто влюбился в нее. Да, были трудности и определенные неудобства, но куда без них.
Так я и работал бы в SVN, но ничего не стоит на месте. В интернете уже потекли тонкие ручейки новостей про Git. Я не кидаюсь за каждой новой технологией, и прошло уже достаточно много времени, пока мне не прожужжали этим Git’ом все мозги. Мне стало любопытно, я вначале присматривался, примерялся, а потом плюнул и начал новый проект на Git. Мучался с ребятами 2 недели, накачал литературы, написал шпаргалку… ничего, привыкли, … а потом меня поперло.

Теперь меня регулярно просят рассказать про Git и что в нем такого. Уже надоело, поэтому этот пост для тех, кто еще сомневается.

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

Наверняка, каждый из нас сталкивался с ситуацией, когда вместо внятного комментария к коммиту хочется написать очередной «асдфасдф». Что касается меня — так я частенько впадаю в такое состояние.

У меня для вас 2 хороших новости!

1. Хорошие люди придумали для таких целей сайт http://whatthecommit.com/.
2. Под впечатлением от этого проекта я написал шуточный прокси для git'а, который умеет добавлять в ваш коммит случайное сообщение.

Допустим мы храним данные на некотором удалённом сервере в Bare-репозитории.
Если есть сомнения в честности обслуживающего сервер персонала, или мы опасаемся, что кто-то сопрёт наш проект, можно зашифровать избранные секретные файлы, представляющие особо секретные технологии фирмы и тем самым затруднить клонирование проекта.

Я не буду обсуждать согласование описываемого ниже метода с политикой и лицензионным соглашением бесплатных Git-репозиториев (а ля GitHub) — это дело частностей и вашей совести.

В реализации мы всопользуемся .gitattributes, staging, filters (фильтрами) и главой 7.2 Pro Git Book.

При работе с 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. В последней приведенной ссылке автор предлагает создавать алиасы, для работы 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, но, увы, они либо были только по одному из вышеназванных пунктов, не освещая другой, либо банально не работали. Вчера возникла необходимость поднять свой сервер репозиториев. Потратил пару часов — поднял, теперь хочу поделиться опытом, потому что считаю проблему актуальной :)