Хабрахабр / Комментарии к посту «Про Git на пальцах (для переходящих с SVN)» в блоге «Разработка»

07.09.2009 13:42:07 el777

el777 — Mon, 07 Sep 2009 13:42:07 GMT

Опишите. Когда я искал такие решения, они были с какими-то проблемами и не подходили.
Если вам удалось это сделать удобно — то было бы очень интересно прочитать.

01.09.2009 11:58:51 clops

clops — Tue, 01 Sep 2009 11:58:51 GMT

Первый и достойный ответ по делу. Поддерживаю

01.09.2009 09:22:07 aratak

aratak — Tue, 01 Sep 2009 09:22:07 GMT

да. очень интересно. допустим, используя redmine приходится вытягивать проект в папку на сервере по крону, (которая доступна для redmine).

01.09.2009 09:17:28 aratak

aratak — Tue, 01 Sep 2009 09:17:28 GMT

можно попробовать gitmodule. вроде оно.

31.08.2009 16:30:21 allter

allter — Mon, 31 Aug 2009 16:30:21 GMT

> разрабатывайте, как хотите, а мне присылайте патчи

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

Кстати, ваши люди вполне могут сами работать с master демократичным образом, но «официальная» версия master будет только у вас и вы её будете регулярно накатывать на репозиторий (push -f). Это, конечно, плохо тем, что тем разработчикам, кто ранее склонировал master с общего сервера придётся rebase-ить его на за-push-еный вами.

В общем, если сложно настроить DAV, то выходов куча.

Я бы всё-таки сделал иерархию ref`ов с ограничением доступа в конфиге апача, если ничего лучшего нет. Либо найдите перловика, который ограничит доступ через mod_perl. Ещё лучше, конечно поставить ssh, а для людей, сидящих под файрволом вывесить ssh на 443 порту.

31.08.2009 15:54:07 torkve

torkve — Mon, 31 Aug 2009 15:54:07 GMT

В gitweb я возможности подобных ограничений тоже не нашел, а гитхаб, если я ничего не путаю, сам по себе закрытый.
Другого способа доступа к файлам без привлечения ssh я, увы, не нашел :) Есть, конечно, git-daemon, но он работает только на чекауты, а не на коммиты.
Устраивать отдельные репозитории для «закрытых» и «общих» веток — это всё-таки, имхо, бардак. Проще сказать: «разрабатывайте, как хотите, а мне присылайте патчи».

31.08.2009 15:29:56 allter

allter — Mon, 31 Aug 2009 15:29:56 GMT

Вам, может, будет проще прописать не полные урлы для ограничения, а маски путей. Тогда не придётся менять конфиг каждый раз. Или посмотрите на другие DAV сервера, например на nginx`овский (я с ним не работал, но судя по примерам конфигов в гугле, он довольно тонко настраивается).

Ещё попробуйте посмотреть, как это сделано в github/gitweb для mob веток (я не смотрел).

В общем, это не проблема git, а проблема выбранного способа доступа к файлам.

Лучше, конечно, сделать, как предложил maxcom ниже — это и нагляднее, и привычнее (вспомним систему интеграции, которой придерживается проект linux ядра).

31.08.2009 15:11:02 dienow

dienow — Mon, 31 Aug 2009 15:11:02 GMT

Это ответ на то что в SVN неудобно реализованы ветки и нельзя решить при их помощи основные задачи. Так то я представляю в чём разница :-)

31.08.2009 15:10:38 allter

allter — Mon, 31 Aug 2009 15:10:38 GMT

1) Вот-вот. Я как раз и писал (выше по треду), что определённые орг. проблемы порождают определённые сложности при работе с Subversion, которые перестают быть таковыми при использовании Git. Эти орг. проблемы, конечно, решаются, но слишком уж мелкими шажками.

Собственно, я для основных проектов git использую в совокупности с оставшимся в наследство svn хранилищем. При этом перенос коммитов между ветками делается без потери семантики «коммит»/«изменение»/«фича» с помощью rebase. И в этом и заключается основная крутизна Git, как DVCS/DSCM: независимость своей ветки кода от чужой. И этим активно пользуются open source проекты, т.к. у них ситуация, когда «пропадает» разработчик (он же часто и заказчик) той или иной фичи, случается гораздо чаще, чем в процессе «нормальной разработки». И семь остальных фич заглохшую ждать при релизе не будут.

Кстати, в приведённом в (1) сценарии использования основная засада — не «быстро-быстро» внедрить 0910 (любой мало-мальски грамотный руководитель такого никогда не попросит, хотя у нас и так бывает иногда), а отказаться в ближайшей версии (и в trunk) от некоторых изменений, которые уже оттестированы (и замерджены в trunk) в ближайшем накате (см. пункт 0909->trunk->0910,0908). Этот сценарий гораздо более част в жизни из-за real life забот (политика, юр. обязательства и т.п.). В Subversion этому поможет только политика «стабильный trunk», когда изменения в trunk попадают только после успешного деплоя фича-брэнча (спасибо за картинку в комменте внизу — как раз иллюстрирует этот подход). Иначе в trunk придётся делать малокрасивый коммит «обратного диффа». С которым потом (когда части заблокированных изменений, наконец, дадут зелёный свет) непонятно, что делать, т.к. всё, что при этом остаётся в trunk — это коммит с текстовым changelog (в лучшем случае) и кучей каких-то непонятных изменений: какие изменения надо накатывать из «забаненного» фича-бренча — непонятно.

(2)
> Релиз ветки, как явление, не содержат изменений вообще, только баг-фиксы.

Т.е. у вас, на самом деле, изменения не автоматические, как на картинке, а выполняются SCM-инженером (или тимлидом) по необходимости. Тогда понятно — это единственный нормальный подход при наличии хотя бы минимального управления/vision/предсказания у проекта (и описано везде, включая svn book). Проблема, что не все проекты такие — в частности, многие задачи поддержки/эксплуатации существующих систем жёстко привязаны к реальной жизни и изменения, происходящие в ней мгновенно сказываются на проекте, не позволяя ждать следующего цикла.

31.08.2009 14:55:20 sse

sse — Mon, 31 Aug 2009 14:55:20 GMT

На Хабре много чего не хватает про разработку, однако больше всего плюсов набирают посты про новинки от Apple и обзоры кусков пластмассы. А за статью на техническую тему можно и минусов набрать «туда, о чем нельзя упоминать» :)

31.08.2009 14:34:37 allter

allter — Mon, 31 Aug 2009 14:34:37 GMT

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

habrahabr.ru/blogs/development/68341/#comment_1939100
habrahabr.ru/blogs/development/68341/#comment_1939795

речь пошла о том, что вопросы плохой организации/проектирования/архитектуры осложняют работу с Subversion. Конечно, такие моменты осложнят и работу с git, но, как мне кажется, с конкретной задачей подготовки двух релизов в условиях гонки лучше справляется git, чем svn, т.к. встроенные механизмы rebase и merge сохраняют семантику «коммит» и благодаря этому людям, ответственным за каждый из релизов проще управлять изменениями, наработанными во время гонки другой командой (для другого релиза).

31.08.2009 14:31:38 clops

clops — Mon, 31 Aug 2009 14:31:38 GMT

31.08.2009 14:30:31 clops

clops — Mon, 31 Aug 2009 14:30:31 GMT

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

31.08.2009 14:28:17 clops

clops — Mon, 31 Aug 2009 14:28:17 GMT

1) Ситуация исключена на организационном уровне. Клиентов готовят к тому, что их проект будет частью определённого релиза.

2) Релиз ветки, как явление, не содержат изменений вообще, только баг-фиксы. Все изменения в отдельных ветках, которые попадаю в trunk. Из него раз в месяц ответвляется новый релиз. Баг фиксы, соответственно, делаются только в релиз ветках (один раз) и пропагируют оттуда в trunk и другие ветки. Этим занимаются branch managers.

Вообще это стандартная практика. Release Driven Development.

31.08.2009 14:24:38 allter

allter — Mon, 31 Aug 2009 14:24:38 GMT

1) А если высшее руководство попросит часть изменений, запланированных в ветке 0910, срочно сделать и включить на выходных, а изменения 0909 притормозить до неизвестных времён, то что вы будете делать?

2)
> выглядит это просто: утром запускается автоматические merges

> 0910->trunk->0909,0908
> 0909->trunk->0910,0908

Т.е. 0908 содержит все изменения из свежих веток? А в чём тогда разница между ними? Или merge не автоматические, а, таки, выборочные?

31.08.2009 14:12:45 SergeyKish

SergeyKish — Mon, 31 Aug 2009 14:12:45 GMT

Ага, с точки зрения svn пользователя другие СКВ отличаются только распределенностью… до смены СКВ.

31.08.2009 13:53:45 sse

sse — Mon, 31 Aug 2009 13:53:45 GMT

Если у вас есть трудности с svn, возможно, имеет смысл посмотреть сюда — не исключено, что будет полезно (если вы еще не видели, конечно): www.infoq.com/articles/agile-version-control

31.08.2009 13:50:41 sse

sse — Mon, 31 Aug 2009 13:50:41 GMT

TFS лучше забыть как страшный сон — это не scm, это фреймворк для построения scm. Помимо того, что он криво встраивается в 2003/2005 студию, у него огромные проблемы с workspace. Проверено на более-менее крупных проектах — плюемся, доделываем и будем искать альтернативы.

31.08.2009 13:48:37 sse

sse — Mon, 31 Aug 2009 13:48:37 GMT

Не знаю, что значит лучше: Visual SVN прекрасно работает через http «искаропки» (фактически это — апач с svn-модулем).

31.08.2009 13:45:02 clops

clops — Mon, 31 Aug 2009 13:45:02 GMT

не согласен — у нас в SVN репозитории сейчас 3 активных релиз бранча

0908 — это на продакшн сервере
0909 — в выходные будет go-live
0910 — это на следующий месяц, был ответвлён из trunk в эти выходные

по одному на каждый месяц. release maitainer каждое утро сливает все change setы — конфликтов за несколько лет работы практически не было.

выглядит это просто: утром запускается автоматические merges

0910->trunk->0909,0908
0909->trunk->0910,0908
0908->trunk->0909,0910

притом из-за специфика SVN мы переносим все changesets как одну ревизию кода. все разработки ведутся не в trunk а в отдельных ветках, которые потом вливаниются в trunk перед тем как создаётся новая релиз ветка.

31.08.2009 13:37:38 allter

allter — Mon, 31 Aug 2009 13:37:38 GMT

Я больше не о терминологии (в некотором смысле, trunk — это «следующий/планируемый/текущий/нестабильный релиз»). А о том, что на Subversion в силу того, что встроенный механизм слияния имеет серьёзные ограничения и того, что замердживаемые изменения сами могут быть замерджены (причём, возможно, пофайлово, а не целым деревом), сложнее вести два релиз-бренча одновременно.

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

31.08.2009 13:37:10 maxcom

maxcom — Mon, 31 Aug 2009 13:37:10 GMT

дать всем ssh доступ к репозиторию — это проще всего

31.08.2009 13:35:35 maxcom

maxcom — Mon, 31 Aug 2009 13:35:35 GMT

git не поддерживает такие ограничения. Можно хранить master в отдельном репозитарии, в который писать может только head developer, а остальные разработчики — только читать. Соответственно остальным выдать репозиторой «песочницу», в которой они будут жить, и из которой будет вытягивать нужные изменения head developer.

31.08.2009 13:27:54 torkve

torkve — Mon, 31 Aug 2009 13:27:54 GMT

Вот я искал что-то и решений не нашёл…

31.08.2009 13:23:20 allter

allter — Mon, 31 Aug 2009 13:23:20 GMT

Можно также прикрутить к апачу модуль (например, mod_perl) и навесить обработчик на стадию аутентификации и авторизации (по такому же пути можно осуществить авторизацию через LDAP). Наверняка это уже где-то есть в гугле — к сожалению именно сопряжением webdav с гитом я не занимался, что бы более адресно помочь.

31.08.2009 12:55:22 torkve

torkve — Mon, 31 Aug 2009 12:55:22 GMT

Ну, у меня работа с DAV идёт средствами апачевского mod_dav, приблизительно так:

Dav on Order Allow,Deny Allow from all AuthType Basic AuthName Git AuthUserFile "/path/to/dav_git.passwd" Require valid-user

То есть, DAV позволяет разрешить чекауты всем, но любая операция коммита требует авторизации из файла паролей. Насколько я вижу в access-логе апача, для ограничения коммита мне придётся на "/myrepo.git/refs/heads/master" поставить ограничение на LOCK отдельным файлом паролей. Это довольно неудобно и требует перечитывания конфига апача при каждом добавлении/изменении веток с ограничениями.
В dav_svn я могу в authz-файле указать права просто как:

[myrepo:/trunk]
headdev=rw
seconddev=rw
*=r

[myrepo:/branches/mybranch]
headdev=rw
someoneelse=rw
*=r

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

31.08.2009 12:44:47 clops

clops — Mon, 31 Aug 2009 12:44:47 GMT

столбы приравниваются к релизам. релиз — это отдельная ветка от транка и он довольно долго обкатывается прежде чем попасть в продакшн

31.08.2009 12:42:04 clops

clops — Mon, 31 Aug 2009 12:42:04 GMT

у нас trunk — это даже не продакшн, а просто основа кода. из него раз в месяц отделяем release branch который в течении месяца тестируется со всем сторон и потом она же попадает в продакшн; все новые разработки делаются в отдельных ветках, которые по завершению попадают в транк; таким образом минимальный срок тестирования любой новой фишки составляет 4 недели. стандартная release driven парадигма

31.08.2009 12:38:59 clops

clops — Mon, 31 Aug 2009 12:38:59 GMT

> Надо отметить, что в SVN, конечно, есть ветки, но сделаны они, видимо, для другого, и поэтому плохо приспособлены для того, чтобы их сливать в trunk.

это вы какую-то фигню написали. вся суть репозитория — в ветках. всем разработчикам сидеть в транке — дурдом. к правилам создания веток хочу так же добавить ветки релизов, как без этого работать мне сложно понять. SVN прекрасно работает с ветками во всех направлениях, дайте мне кейс, кто она с ними не справляется как должно.

в пользу GIT говорит только распределённость.

31.08.2009 12:31:08 skiedr

skiedr — Mon, 31 Aug 2009 12:31:08 GMT

Если у вас линукс почитайте эту статью.
Ести немножко донатроить SSH можно удет иметь github подобную авторизацию с помощью ключей доступа.

31.08.2009 12:24:23 SMiX

SMiX — Mon, 31 Aug 2009 12:24:23 GMT

`hg serve` это как раз http-сервер, а другого вроде каки нет.

31.08.2009 12:22:46 torkve

torkve — Mon, 31 Aug 2009 12:22:46 GMT

Каким образом? Я вот, наоборот, всё бьюсь, и никак не могу настроить гит для нормлаьной работы через http.

31.08.2009 11:39:11 SergeyKish

SergeyKish — Mon, 31 Aug 2009 11:39:11 GMT

Git разделяет изменение индекса и коммит.
Значение файлов сохраняется при добавлении в индекс, соответственно есть три варианта git diff.

$ echo 'created' >file
$ git add file
$ echo 'updated' >file
$ git diff file # относительно индекса
@@ -1 +1 @@
-created
+updated
$ git diff --cached # в индексе
@@ -0,0 +1 @@
+created
$ git diff HEAD # от последнего коммита
diff --git a/file b/file
@@ -0,0 +1 @@
+updated

При коммите сохраняется текущий индекс. Команда git commit -a эквивалентна

git add -u # добавляем в индекс измененные файлы
git commit

31.08.2009 11:29:45 allter

allter — Mon, 31 Aug 2009 11:29:45 GMT

Можно закрыть определённые файлы ref`ов (т.е., по сути, ветки) средствами DAV сервера.

31.08.2009 11:12:21 allter

allter — Mon, 31 Aug 2009 11:12:21 GMT

К сожалению, иногда увольнять надо и горе-менеджеров: часто задача достижения определённого «километрового столба» ставится приоритетной, в trunk происходит активная интеграция, а потом вдруг всё глохнет, а актуальной задачей становится, например, релиз с новой, необходимой бизнесу, функциональностью.

С Subversion`овским мерджем в таком сценарии использования остаётся только курить бамбук и реализовывать в новой интеграционной ветке, в том числе, часть функциональности, которая уже замерджена в заглохший trunk. Даже после версии 1.5, чей мердж иногда сглюкивает (в частности, на репозиториях, которые родились до 1.5 или на которых активно поколдовали с помощью svk) и приходится откатываться на покоммитный мердж. :(

А когда заказчик trunk-а оживёт, придётся синхронить изменения, сделанные в релизной ветке с trunk.

31.08.2009 11:07:43 SergeyKish

SergeyKish — Mon, 31 Aug 2009 11:07:43 GMT

Попробуйте заменить слово «svn» на hg, bzr, git.

Статья отражает функционал git для пользователей svn. Не стоит по ней судить о возможностях git.
Git выбирают за то чего в svn нет.

31.08.2009 11:06:36 TedBeer

TedBeer — Mon, 31 Aug 2009 11:06:36 GMT

собственно в этом заключается вопрос — как сделать репозитарий общим

31.08.2009 11:05:30 ayc

ayc — Mon, 31 Aug 2009 11:05:30 GMT

Да во всех scm есть собственные встроенные серверы с собственным протоколом. Но я как раз о случае, когда их использовать нельзя или невозможно. А HTTP всегда доступен, и с ним работа у Git'а самая удобная, imho.

31.08.2009 10:58:21 allter

allter — Mon, 31 Aug 2009 10:58:21 GMT

Или, что у меня гораздо чаще случается, чем описанное оратором выше: часто начинаешь делать изменения, а потом замечаешь, что коммиттить их в будущем надо будет не в эту, а в другую ветку. Для этого делаешь git add, потом, вроде git reset --soft (я пользуюсь GUI-интерфейсом gitk для этого, не знаю точных ключей) и дальше продолжаешь модифицировать изменения, после чего комиттишь.

Кстати, пользуясь svn я часто тоже делаю аналог git add: есть специальный скриптик, который запускается командой «sv» перед коммитом для того, что бы отследить изменения в текущем каталоге, которые будут закоммитчены.

31.08.2009 10:51:41 develop7

develop7 — Mon, 31 Aug 2009 10:51:41 GMT

Вот выложили бы этот мануал бы да на полгода раньше — глядишь, и не наступил бы на половину граблей, как бывший пользователь svn.