Хабрахабр / Комментарии к посту «Git Workflow» в блоге «Git»

Хабрахабр / Комментарии к посту «Git Workflow» в блоге «Git» http://habrahabr.ru/rss/post/60030/ ru editor@habrahabr.ru habrahabr.ru Sat, 11 Feb 2012 12:00:14 GMT http://habrahabr.ru/ http://habrahabr.ru/i/logo.gif Хабрахабр 25.02.2011 11:55:46 VlK http://habrahabr.ru/blogs/Git/60030/#comment_3693254 http://habrahabr.ru/blogs/Git/60030/#comment_3693254 Fri, 25 Feb 2011 11:55:46 GMT VlK 25.02.2011 10:55:32 VladSavitsky http://habrahabr.ru/blogs/Git/60030/#comment_3693084 http://habrahabr.ru/blogs/Git/60030/#comment_3693084 Fri, 25 Feb 2011 10:55:32 GMT VladSavitsky 24.02.2011 12:09:51 VlK http://habrahabr.ru/blogs/Git/60030/#comment_3690207 http://habrahabr.ru/blogs/Git/60030/#comment_3690207
В общем, могу сразу обозначить для вас слабые стороны.

1) неприятная работа с большими бинарниками по понятным причинам;

2) пустые директории или файлы в силу архитектуры git невозможны;

3) по первости несколько путает терминология git;

4) роль репозитария несколько уже по сравнению с svn. Если в svn в структуре репозитария запросто можно хранить вообще весь проектный мусор (бинарную документацию pdf или doc, к примеру; исходники сопровождающего проект сайта), то git хотя и позволяет вытаскивать отдельные файлы или директории, но не предназначен для этого. В svn же бранчи — это просто папки, все равно, что хранится.

Из преимуществ.

1) все, что хочется делать с кодом или текстом — в git лучше, быстрее, разнообразнее. Это можно понять и оценить, только поработав; обычно пользователи svn слабо представляют себе разнообразие альтернативных методов работы с хранилищами кода.

2) конечно же, полноценная работа без Инета в силу распределенной природы.

3) вы указали хостинг репозитариев. А вот у меня, к примеру, есть две машины: офисная и домашний ноут. И я запросто делаю синхронизацию кода в любую сторону, без посредников, платных или бесплатных.

Далее мысли в целом по текущему положению дел с системами.

За распределенными репозами образца git — будущее. Это поняли уже все. Даже Фаулер где-то писал про неизбежность постепенного перехода, хотя в первых блог-постах на тему сильно сомневался. Конечно, переход с svn на git, hg, bzк не повысит вашу работоспособность, но определенно упростить жизнь.]]> Thu, 24 Feb 2011 12:09:51 GMT VlK 24.02.2011 10:27:39 VladSavitsky http://habrahabr.ru/blogs/Git/60030/#comment_3689943 http://habrahabr.ru/blogs/Git/60030/#comment_3689943 Отвечу по пунктам.
1) Папки с точкой в начале (.svn) в линуксе — это скрытые папки, хотя я у себя включил показ скрытых папок и они мне не мешают. Когда нужно получить код без этих папок — делаю svn export.
2) Для личных проектов я завожу репоз на assembla.com — пара минут и он готов. По работе мы под каждый тикет создаем ветку и потом мержим в транк (по моему это классическое использование). Тикеты обычно большие, но бывают и на 5 коммитов. Создание бранча в svn дело быстрое, потому как ничего никуда не копируется физически. Мерж тоже 3-4 команды, если нет конфликтов, которые нужно разрулить руками, но это тоже не так и сложно.

Насколько я понимаю, переезд в другую локальную сеть для SVN не проблема, а вот проблема в том, что нужно постоянное наличие инета и локально работать без инета сложно.

Пока я так понимаю, что git несколько иначе работает, чем svn. У него есть свои плюсы и свои минусы, которые нужно и полезно знать. ]]> Thu, 24 Feb 2011 10:27:39 GMT VladSavitsky 23.02.2011 22:05:43 VlK http://habrahabr.ru/blogs/Git/60030/#comment_3688906 http://habrahabr.ru/blogs/Git/60030/#comment_3688906
Вообще, у концепции ветвления в svn принципиально другой смысл, хранятся они по-другому и используются значительно реже.

Но, признаюсь, жил бы и жил я нормально безо всех этих радостей, если бы не было двух вещей в svn:

1) по проекту разбросан мусор в виде .svn в каждой директории

2) НЕУДОБНО для каждого мелкого личного проекта заводить центральный репоз, потом из него в директорию проекта checkout делать.

А еще в git что очень хорошо, так это удобство настройки файлом .git/config. Переехал с ноутом в другую локальную сеть — достаточно просто сменить адрес условно-центрального репоза — и дальше в работу.

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

Сейчас же даже на работе уже настроил гейт от git к корпоративному svn и пользуюсь в свое удовольствие.]]> Wed, 23 Feb 2011 22:05:43 GMT VlK 23.02.2011 19:44:53 VladSavitsky http://habrahabr.ru/blogs/Git/60030/#comment_3688501 http://habrahabr.ru/blogs/Git/60030/#comment_3688501 Перед этим все изменения должны быть закомичены.
Не вижу пока преимущества Git в этом.]]> Wed, 23 Feb 2011 19:44:53 GMT VladSavitsky 27.08.2010 08:12:13 VlK http://habrahabr.ru/blogs/Git/60030/#comment_3195499 http://habrahabr.ru/blogs/Git/60030/#comment_3195499
Впрочем, есть gitolite или что-то такое.

Короче. Не знаю ничего про gitweb + git(osis) :)]]> Fri, 27 Aug 2010 08:12:13 GMT VlK 26.08.2010 14:36:17 roller http://habrahabr.ru/blogs/Git/60030/#comment_3192961 http://habrahabr.ru/blogs/Git/60030/#comment_3192961
впрочем уже поднял gitweb, про гитозис читал, но для одиноко стоящего разработчика в поле это имхо перебор.

интересно кстати, совместимы ли гитозис и gitweb? ]]> Thu, 26 Aug 2010 14:36:17 GMT roller 26.08.2010 07:09:14 VlK http://habrahabr.ru/blogs/Git/60030/#comment_3190971 http://habrahabr.ru/blogs/Git/60030/#comment_3190971
Я так вообще для всех своих сколь угодно серьезных проектов завел на личном сервере gitosis, который позволяет в некоторых рамках удобно управлять группой репозитариев и (удаленным) доступом к ним по публичным ключам ssh.

А для мелких… Для мелких нужна просто возможность контролировать поток небольших изменений и веточек. Вот тут как раз и получается так удобно сделать git init.

Вы все еще скучаете по svn, да? :) ]]> Thu, 26 Aug 2010 07:09:14 GMT VlK 25.08.2010 21:56:24 roller http://habrahabr.ru/blogs/Git/60030/#comment_3190222 http://habrahabr.ru/blogs/Git/60030/#comment_3190222 Wed, 25 Aug 2010 21:56:24 GMT roller 11.09.2009 12:53:49 ivanych http://habrahabr.ru/blogs/Git/60030/#comment_1974504 http://habrahabr.ru/blogs/Git/60030/#comment_1974504
— Разработчик1 в своем локальном бранче1 сделал некую правку1. Смержил бранч1 с бранчем master. Отправил master в центральный репозиторий.

— Разработчик2 в своем локальном бранче2 сделал некую правку2. Смержил бранч2 с бранчем master. Отправил master в центральный репозиторий.

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

Вопрос — как главному разработчику обновить рабочий проект, так, чтобы в него попала только хорошая правка1, а плохая правка2 не попала?

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

Если ответ — не надо было допускать плохую правку в master, то тогда возникает другой вопрос — а как тогда вообще обмениваться правками?]]> Fri, 11 Sep 2009 12:53:49 GMT ivanych 26.05.2009 11:23:50 lomeo http://habrahabr.ru/blogs/Git/60030/#comment_1651784 http://habrahabr.ru/blogs/Git/60030/#comment_1651784 Tue, 26 May 2009 11:23:50 GMT lomeo 25.05.2009 14:28:22 VlK http://habrahabr.ru/blogs/Git/60030/#comment_1648756 http://habrahabr.ru/blogs/Git/60030/#comment_1648756
Сложный путь — вроде того, что я описал одним моим сообщением выше, когда лезем в историю, физически ее меняем…

Путь, что мне больше по душе — сделать revert слияния:

git revert 81a94bb976dfaaaae42ae2600b7e9e88645ebd81 -m 1

здесь хэш определяет коммит слияния, ключ "-m 1" обозначает номер оставляемой ветки, обычно первый (ветка, в которую вливались).
]]> Mon, 25 May 2009 14:28:22 GMT VlK 22.05.2009 18:35:09 23kota http://habrahabr.ru/blogs/Git/60030/#comment_1643255 http://habrahabr.ru/blogs/Git/60030/#comment_1643255
Ну а в общем, в своей работе разве у вас нет какой-нибудь пятёрки коммитов, которые постоянно болтаются на вашем рабочем бранче и которые хочется всегда видеть у себя но никогда в основном репозитории? Или это только с моим стилем работы что-то не так?]]> Fri, 22 May 2009 18:35:09 GMT 23kota 22.05.2009 18:24:28 mOlind http://habrahabr.ru/blogs/Git/60030/#comment_1643226 http://habrahabr.ru/blogs/Git/60030/#comment_1643226 Fri, 22 May 2009 18:24:28 GMT mOlind 22.05.2009 17:07:34 23kota http://habrahabr.ru/blogs/Git/60030/#comment_1643066 http://habrahabr.ru/blogs/Git/60030/#comment_1643066
Но это конфигурации, в них редко делаются правки. А если это центровой и очень популярный в проекте файл, в который довольно часто льются коммиты и в котором так удобно держать свой код, который, например, дапмит в файл только вам нужные данные?]]> Fri, 22 May 2009 17:07:34 GMT 23kota 22.05.2009 16:28:50 Paul http://habrahabr.ru/blogs/Git/60030/#comment_1642990 http://habrahabr.ru/blogs/Git/60030/#comment_1642990 центральный свн будет полон того что там могло бы и не находитсяИ кому это мешает? К тому же ветки после слияния в транк можно удалять, чтобы глаза не мозолили.

учитывая что свн копирует файлы для создании ветки/тэга

Не копирует.

многие просто побоятся/поленятся что-то коммитить в общий репозиторий т.к. этот код еще сырой

Если это частная ветка, то какая разница, в общем она репозитории или в частном?

в результате каждый коммит это уже почти полноценная фича которая заливается в общий свн репозиторий и о легковесности слияния не может быть и речи

Это, как уже обсуждалось, зависит от политики коммитов.

Вот работа оффлайн — это пожалуй единственный весомый аргумент, из приведенных вами.]]> Fri, 22 May 2009 16:28:50 GMT Paul 22.05.2009 16:22:03 Shchvova http://habrahabr.ru/blogs/Git/60030/#comment_1642964 http://habrahabr.ru/blogs/Git/60030/#comment_1642964 www.spheredev.org/wiki/Git_for_the_lazy]]> Fri, 22 May 2009 16:22:03 GMT Shchvova 22.05.2009 15:03:24 mOlind http://habrahabr.ru/blogs/Git/60030/#comment_1642732 http://habrahabr.ru/blogs/Git/60030/#comment_1642732 p.s. git есть уже и под win и под mac os x. и GUI есть тоже кросплатформенный. (qgit например)]]> Fri, 22 May 2009 15:03:24 GMT mOlind 22.05.2009 14:56:36 mOlind http://habrahabr.ru/blogs/Git/60030/#comment_1642704 http://habrahabr.ru/blogs/Git/60030/#comment_1642704 Fri, 22 May 2009 14:56:36 GMT mOlind 22.05.2009 14:50:56 mOlind http://habrahabr.ru/blogs/Git/60030/#comment_1642691 http://habrahabr.ru/blogs/Git/60030/#comment_1642691 Fri, 22 May 2009 14:50:56 GMT mOlind 22.05.2009 09:29:38 VlK http://habrahabr.ru/blogs/Git/60030/#comment_1641528 http://habrahabr.ru/blogs/Git/60030/#comment_1641528
Например,

git revert BAD_COMMIT_TAG

отменит какое-то из коммитов в истории, который вы пометили как плохой.

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

Другой способ, если изменения не коснулись кого-либо кроме вас — команда git rebase, отвечающая за физические изменения в истории проекта. Пример:

git tag BAD_TAG work~5 — отмечаем проблемный коммит (пять коммитов назад по истории в ветке work) тэгом

git checkout BAD_TAG — переключаемся на этот коммит

… убираем ненужные вещи

git commit --amend — собственно, коммит модификации

git rebase --onto HEAD BAD_TAG work — накладываем последующие коммиты на внесенные изменения
]]> Fri, 22 May 2009 09:29:38 GMT VlK 22.05.2009 04:10:42 evilbloodydemon http://habrahabr.ru/blogs/Git/60030/#comment_1640673 http://habrahabr.ru/blogs/Git/60030/#comment_1640673 Fri, 22 May 2009 04:10:42 GMT evilbloodydemon 22.05.2009 00:45:21 23kota http://habrahabr.ru/blogs/Git/60030/#comment_1640587 http://habrahabr.ru/blogs/Git/60030/#comment_1640587
Пока что не нашёл простого способа заставить системы контроля версий (и git в частности) работать в таком стиле, но мне кажется, что подобный стиль очевиден и многие должны с ним столкнуться. Как вы поступаете в таком случае?]]> Fri, 22 May 2009 00:45:21 GMT 23kota 21.05.2009 16:56:37 Devgru http://habrahabr.ru/blogs/Git/60030/#comment_1639683 http://habrahabr.ru/blogs/Git/60030/#comment_1639683 Thu, 21 May 2009 16:56:37 GMT Devgru 21.05.2009 16:45:43 Jenyay http://habrahabr.ru/blogs/Git/60030/#comment_1639651 http://habrahabr.ru/blogs/Git/60030/#comment_1639651 Thu, 21 May 2009 16:45:43 GMT Jenyay 21.05.2009 15:01:27 LaggyLuke http://habrahabr.ru/blogs/Git/60030/#comment_1639399 http://habrahabr.ru/blogs/Git/60030/#comment_1639399 Мне сейчас неудобно экспериментировать, под рукой только корпоративный сервер.]]> Thu, 21 May 2009 15:01:27 GMT LaggyLuke 21.05.2009 14:53:18 Devgru http://habrahabr.ru/blogs/Git/60030/#comment_1639373 http://habrahabr.ru/blogs/Git/60030/#comment_1639373 git push origin foobar:refs/heads/foobar
использовать
git push origin foobar:foobar
? Это ведь будет работать, или нет?]]> Thu, 21 May 2009 14:53:18 GMT Devgru 21.05.2009 12:21:44 Iskin http://habrahabr.ru/blogs/Git/60030/#comment_1638682 http://habrahabr.ru/blogs/Git/60030/#comment_1638682 Thu, 21 May 2009 12:21:44 GMT Iskin 21.05.2009 11:56:13 evilbloodydemon http://habrahabr.ru/blogs/Git/60030/#comment_1638592 http://habrahabr.ru/blogs/Git/60030/#comment_1638592 Thu, 21 May 2009 11:56:13 GMT evilbloodydemon 21.05.2009 10:56:02 VlK http://habrahabr.ru/blogs/Git/60030/#comment_1638346 http://habrahabr.ru/blogs/Git/60030/#comment_1638346
Финансисты же — народ консервативный, даже в айтишной сфере; им проще судить о том, что было и сейчас в зените популярности; а том же, что только входит в мэйнстрим, они рассуждать не могут и не будут. Тут надо обращаться к аналитикам другого рода… Прежде всего надо спрашивать у самих разработчиков.

Svn сделала историю; более того, стала символом всех централизованных систем благодаря своей простоте и логичности. Естественно, что прежде чем икона сменится, пройдет минимум несколько лет. ]]> Thu, 21 May 2009 10:56:02 GMT VlK 21.05.2009 10:49:29 VlK http://habrahabr.ru/blogs/Git/60030/#comment_1638316 http://habrahabr.ru/blogs/Git/60030/#comment_1638316
кривая обучения вполне себе обычная для таких систем: показал несколько команд, объяснил как пользоваться, подсказал, где доки хорошие лежал. Вот и все. Как документация нормальная появилась — сразу налет таинственности слетел.

Это все больше очередная айтишная легенда, вроде стиля такого. ]]> Thu, 21 May 2009 10:49:29 GMT VlK 21.05.2009 10:47:41 vovkab http://habrahabr.ru/blogs/Git/60030/#comment_1638309 http://habrahabr.ru/blogs/Git/60030/#comment_1638309 Thu, 21 May 2009 10:47:41 GMT vovkab 21.05.2009 10:44:36 Iskin http://habrahabr.ru/blogs/Git/60030/#comment_1638299 http://habrahabr.ru/blogs/Git/60030/#comment_1638299 code.google.com/p/nbgit/
Eclipse: code.google.com/p/egit/]]> Thu, 21 May 2009 10:44:36 GMT Iskin 21.05.2009 10:43:36 Iskin http://habrahabr.ru/blogs/Git/60030/#comment_1638294 http://habrahabr.ru/blogs/Git/60030/#comment_1638294 Thu, 21 May 2009 10:43:36 GMT Iskin 21.05.2009 10:42:29 Iskin http://habrahabr.ru/blogs/Git/60030/#comment_1638286 http://habrahabr.ru/blogs/Git/60030/#comment_1638286 Thu, 21 May 2009 10:42:29 GMT Iskin 21.05.2009 10:40:54 Iskin http://habrahabr.ru/blogs/Git/60030/#comment_1638279 http://habrahabr.ru/blogs/Git/60030/#comment_1638279 los-t.livejournal.com/tag/git+guts]]> Thu, 21 May 2009 10:40:54 GMT Iskin 21.05.2009 09:54:37 genacvale http://habrahabr.ru/blogs/Git/60030/#comment_1638141 http://habrahabr.ru/blogs/Git/60030/#comment_1638141 Thu, 21 May 2009 09:54:37 GMT genacvale 21.05.2009 09:49:13 vovkab http://habrahabr.ru/blogs/Git/60030/#comment_1638125 http://habrahabr.ru/blogs/Git/60030/#comment_1638125 eigenclass.org/hiki/gibak-backup-system-introduction

из описания почему пришлось делать gibak:
The major thing missing in Git when used as a backup tool is support for file metadata (mostly file permissions) and empty directories (git just ignores them). git-home-history doesn't handle them at all, and etckeeper relies on metastore to preserve a snapshot of the metadata (owner, group, permissions, mtime, etc.) in a .metastore file located at the top of the git repository (/etc in the case of etckeeper).]]> Thu, 21 May 2009 09:49:13 GMT vovkab 21.05.2009 09:47:29 genacvale http://habrahabr.ru/blogs/Git/60030/#comment_1638121 http://habrahabr.ru/blogs/Git/60030/#comment_1638121
но опять получается что все это зависит от того как устроена работа.
я смотрю редко, для того чтобы узнать что я закоммитил в предыдущие разы. вы смотрите каждый раз для того чтобы что-то ненужное не ушло в общественный репозитарий.

]]> Thu, 21 May 2009 09:47:29 GMT genacvale