Комментарии 69
НЛО прилетело и опубликовало эту надпись здесь
antonarhipov тут ваш маркетинг назвали земляным червяком!
Не такой уж он и липкий. Мне какой-то Шон написал всего два письма. В первом спросил, удалось ли мне всё установить и настроить. Во втором интересовался тем, пробую ли я чисто для себя или для всей команды. На каждое я ответил всего парой предложений и он отлип…
Сейлзы это, а не маркетинг. Сейлзы. И да, это как джава и дажавскрипт, звучит похоже, но совсем не то.
Очень порадовал трезвый взгляд на Git.
Незнаю, мне он не очень показался трезвым. Сам использую только svn на работе и только git дома. Что svn лучше git на маленьких проектах — у меня противоположное мнение. В SVN же не нравится, что комит должен быть готовой фичей, и соответственно не всегда может быть маленьким (в гите ты можешь делать сколько угодно маленькие коммиты и пушить готовую фичу).
Иногда у меня нет доступа к SVN серверу (потому что к примеру нет интернета под боком), я сижу и думаю о том, что git давно решил эту проблему. Также если охото поэксперементировать, если SVN — то ничего не сделаешь, бренч создавать из пушки по слонам, в итоге работаешь вообще без контроля версий — в гит нет такой проблемы, комить локально сколько влезет.
Вообщем локальные коммиты делают гит для меня намного привлекательнее чем SVN.
Иногда у меня нет доступа к SVN серверу (потому что к примеру нет интернета под боком), я сижу и думаю о том, что git давно решил эту проблему. Также если охото поэксперементировать, если SVN — то ничего не сделаешь, бренч создавать из пушки по слонам, в итоге работаешь вообще без контроля версий — в гит нет такой проблемы, комить локально сколько влезет.
Вообщем локальные коммиты делают гит для меня намного привлекательнее чем SVN.
Что svn лучше git на маленьких проектах — у меня противоположное мнение.
Не столько лучше, сколько адекватнее маленькому проекту. Если команда маленькая и разработка централизована, идеология центрального репозитория подходит лучше. В таких случаях убеждать кого-либо в том, что распределенный контроль версий лучше потому что он распределенный — все равно что утверждать, что зеленая машина лучше желтой, потому что она зеленая.
В SVN же не нравится, что комит должен быть готовой фичей, и соответственно не всегда может быть маленьким (в гите ты можешь делать сколько угодно маленькие коммиты и пушить готовую фичу).
Извините, я не понял этой фразы. Вы имеете в виду, что вы не можете закоммитить что-либо, что сломает билд? В принципе, верно. Но. Если изменение даже не компилируется, надо ли вообще стремиться его класть куда-либо? В конце концов никто не мешает иметь свою базу/ветку, если вы боитесь за сохранность данных на диске и т.п. Если оно не ломает билд, почему вы не можете его закоммитить в транк, который все равно никому не виден, кроме коллег?
Иногда у меня нет доступа к SVN серверу (потому что к примеру нет интернета под боком), я сижу и думаю о том, что git давно решил эту проблему.
Стоп-стоп-стоп, с этого места подробнее. Какую именно проблему? Если вам нужны последние изменения кого-либо из коллег, вам все равно нужен доступ к сети, какой бы СКВ ни была. А иначе СКВ вам нужна лишь для собственных коммитов, что важно только если вы будете переключаться между задачами (в противном случае весь «коммит» это Ctrl+S). Чего в отсутствие сети все равно сделать нельзя, раз трекер недоступен. Да и, например, у нас «производственный процесс» требует постоянного присутствия — либо IP телефон, либо скайп. Так что либо сеть есть, либо ты не работаешь.
Разные команды — разные потребности — разные принципы работы. Вполне есть ситуации, когда Git реально просто не нужен.
PS вполне рабочая комбинация SVN и Git локально.
Для маленьких проектов и разных вкусов — впринципе согласен, но SVN навязывает центральный репозиторий. git — же дает право выбора — хочешь центральный, хочешь локальный + центральный и каждый разработчик может выбрать сам для себя. Я работаю в маленькой команде и они используют SVN — а я хочу иметь возможность коммитить локально :)
Зачем сразу ломать :) На моей работе случается с регулярностью в несколько дней. Билды у нас делает QA Engineer, он говорит: «Хочу собрать билд». Разработчик: «Ой я делаю фичу — уже сделал коммит, подожди 30мин пока я закончу». Билд накатывается на демо-сервер, и что-то незаконченное там — не смерть, но сервер могут демонстрировать клиенту, там не должно быть меню на которое ты кликаешь и ничего не происходит. Я всегда, когда это слышу — «подожди пока я закомичу» — вспоминаю Git.
По поводу svn update or git pull без интернета — это понятно. Я о другом — git позволяет не менять привычек независимо от того есть у вас интернет или нет — вы продолжаете разбивать задание на маленькие кусочки, и делать маленькие коммиты, коммиты — это как история проекта, вы можете откатиться к предыдущему комиту, сделать бренч для фичи — интернет не нужен. Это не тоже самое, что и ctlr+s, это намного могущественнее :) Но вы правы, что не всем это нужно — это больше зависит от стиля и привычек.
Согласен, но после использования git, при использовании SVN я часто ощущаю, что мне не хватает гибкости git.
А когда я использую git локально вместе с SVN я думаю, что один из них лишний — лучше либо менять свои привычки, либо переходить на git. Проблема SVN — он заставляет менять привычки, и то, что в лучшую сторону — это очень спорно. Git же позволяет работать в своем стиле локально независимо от всего, а пушить на центральный репозиторий в том стиле который хочет команда.
Вы имеете в виду, что вы не можете закоммитить что-либо, что сломает билд?
Зачем сразу ломать :) На моей работе случается с регулярностью в несколько дней. Билды у нас делает QA Engineer, он говорит: «Хочу собрать билд». Разработчик: «Ой я делаю фичу — уже сделал коммит, подожди 30мин пока я закончу». Билд накатывается на демо-сервер, и что-то незаконченное там — не смерть, но сервер могут демонстрировать клиенту, там не должно быть меню на которое ты кликаешь и ничего не происходит. Я всегда, когда это слышу — «подожди пока я закомичу» — вспоминаю Git.
Стоп-стоп-стоп, с этого места подробнее.
По поводу svn update or git pull без интернета — это понятно. Я о другом — git позволяет не менять привычек независимо от того есть у вас интернет или нет — вы продолжаете разбивать задание на маленькие кусочки, и делать маленькие коммиты, коммиты — это как история проекта, вы можете откатиться к предыдущему комиту, сделать бренч для фичи — интернет не нужен. Это не тоже самое, что и ctlr+s, это намного могущественнее :) Но вы правы, что не всем это нужно — это больше зависит от стиля и привычек.
Разные команды — разные потребности — разные принципы работы. Вполне есть ситуации, когда Git реально просто не нужен.
Согласен, но после использования git, при использовании SVN я часто ощущаю, что мне не хватает гибкости git.
А когда я использую git локально вместе с SVN я думаю, что один из них лишний — лучше либо менять свои привычки, либо переходить на git. Проблема SVN — он заставляет менять привычки, и то, что в лучшую сторону — это очень спорно. Git же позволяет работать в своем стиле локально независимо от всего, а пушить на центральный репозиторий в том стиле который хочет команда.
Как однажды кто-то сказал в каком-то чате, git svn это более удобный клиент svn, чем просто svn.
Я работаю в маленькой команде и они используют SVN — а я хочу иметь возможность коммитить локально :)
У нас используется гит локально, но случаи, когда он нужен — перечесть по пальцам за годы.
Зачем сразу ломать :) На моей работе случается с регулярностью в несколько дней. Билды у нас делает QA Engineer, он говорит: «Хочу собрать билд». Разработчик: «Ой я делаю фичу — уже сделал коммит, подожди 30мин пока я закончу». Билд накатывается на демо-сервер, и что-то незаконченное там — не смерть, но сервер могут демонстрировать клиенту, там не должно быть меню на которое ты кликаешь и ничего не происходит. Я всегда, когда это слышу — «подожди пока я закомичу» — вспоминаю Git.
Ну вот видите, я же говорю — команды и принципы разные, и есть случаи, когда гит не нужен. Нет, минусят, чудаки.
У нас билд делается автоматизировано с юнит тестированием несколько раз в сутки, так что явный слом виден сразу, а «логический» никого не волнует — это же Dev ветка. В релизные ветки изменения мёрджаться только после QA на Dev ветке. Поэтому репозиторий можно собрать любому в любой момент, через интернет-портал и ни разу не было «подожди, ща доделаю».
Я о другом — git позволяет не менять привычек независимо от того есть у вас интернет или нет — вы продолжаете разбивать задание на маленькие кусочки, и делать маленькие коммиты, коммиты — это как история проекта, вы можете откатиться к предыдущему комиту, сделать бренч для фичи — интернет не нужен.
У нас просто другой принцип работы: изначально фича разбивается на части, на разные «таски»/«тикеты», каждый из которых — законченная часть, между которыми ты не скачешь. Это планирование дисциплинирует, помогает декомпозировать задачу.
Это не тоже самое, что и ctlr+s, это намного могущественнее :) Но вы правы, что не всем это нужно — это больше зависит от стиля и привычек.
Вот я о том и говорю — в нашей команде (судя по тому, что я читаю от оппонентов) по-другому построена работа. Случаев, когда Git был бы нужен локально за годы работы я могу вспомнить 2 или 3. У нас не бывает такого, что ты пилишь фичу и тебе нужно срочно пофиксить что-то в этом же модуле, вот прямо вчера надо пофиксить. Благодаря хорошо поставленному QA и «живому тестированию» на малых клиентах у нас не бывает ситуаций, когда надо сидеть и по ночам что-то пилить. Или переключаться с фич на фиксы. Плюс к тому под-команды организованы так, что в каждой группе люди примерно одного уровня и каждый может работать с каждой частью системы. Да, есть «свои» области, но что-то срочное может сделать другой. Например, пока я пилю фичу, мой коллега может сделать фикс и попросить сделать ревью на всякий случай. Для этого нужен только дифф, чтобы посмотреть, что он написал.
Такого, чтобы было нужно срочно прервать разработку и фиксить тот же модуль, за годы работы было 2-3 случая, я без проблем обошелся простым копированием в tmp папку и обратно. Отпуска, или неравномерная загруженность. Но это — исключения.
Проблема SVN — он заставляет менять привычки, и то, что в лучшую сторону — это очень спорно
Это если ваши привычки изначально гитовые. В нашем случае все наоборот.
Два дополнения вслед:
1) Ни демо, ни установка клиенту никогда не идет из dev репозитория, только из стабильного/RC, поэтому каждодневные коммиты никак те ветки не ломают
2) Про «не надо ломать привычки» — Git стал массовым относительно недавно, если сравнивать с централизованными СКВ. Так что это вопрос открытый: переход в какую сторону заставляет менять привычки.
1) Ни демо, ни установка клиенту никогда не идет из dev репозитория, только из стабильного/RC, поэтому каждодневные коммиты никак те ветки не ломают
2) Про «не надо ломать привычки» — Git стал массовым относительно недавно, если сравнивать с централизованными СКВ. Так что это вопрос открытый: переход в какую сторону заставляет менять привычки.
Если моя большая фича состоит из нескольких более маленьких фич и я хочу закоммитить каждую маленькую фичу, а запушить только большую — то в свне без сервера я так не смогу, а в гите — смогу. Коммиты должны быть атомарными, максимально дроблёными для того чтобы можно было bisect'ом понять, какой именно из них привнёс проблему.
я хочу закоммитить каждую маленькую фичу, а запушить только большую — то в свне без сервера я так не смогу, а в гите — смогу.
Коммитится в центральный репозиторий каждая малая часть, хоть каждый день по нескольку раз (ведь мы разрабатываем одну часть, доводим до какой-то точки и потом переключаемся на другую). В чем проблема коммитить все изменения, не ломающие билд, в dev ветку?
Так мы ж вроде обсуждали ситуацию когда центральный репозиторий недоступен?
В разных командах по-разному. Я не могу начать работу без сети — не могу отметить начало рабочего дня. Да и для того, чтобы начать работать над другой фичей, перед чем нужно скинуть файлы в репозиторий, мне нужен доступ к трекеру, где собственно записано, что надо делать. Есть сеть — есть репозиторий, есть список тикетов.
Да и начать можно с того, работают ли вообще в конторе N люди удаленно?
У всех по-разному.
Да и начать можно с того, работают ли вообще в конторе N люди удаленно?
У всех по-разному.
А, ну я часто работаю из дома и мне нет никакой потребности иметь доступ к серверу гита чтобы начать полноценно работать. У меня часто бывает достаточно много задач, я прекрасно могу их форкать от мастера и мёрджить обратно без всякого доступа к сети. В офисе мне надо будет сделать просто pull --rebase и push.
Для этого придуманы ветки. Комитьте в фичеветку, а в вашем пожелании слово пуш замените на мёрдж ;)
Так мы ж вроде обсуждали ситуацию когда центральный репозиторий недоступен?
А, ну для этого есть же всякие hgoversvn или как там их называют. Когда на прежней работе один чистый чекаут занимал 40 минут это было спасением.
Собственно, в SVN всего две проблемы — сложные мёрджи из-за отсутствия трекинга файлов и переименований, а так же наличие центрального сервера без доступа к которому нельзя сделать несоклько коммитов
И ме-е-едленная работа при сколько-нибудь выше среднего размере репозотория.
сложные мёрджи из-за отсутствия трекинга файлов и переименований
Переименования отслеживаются в SVN
а так же наличие центрального сервера без доступа к которому нельзя сделать несоклько коммитов
Зачем? Нет, серьезно — как часто вам приходится работать без сети?
Централизованной разработка бывает крайне редко, в подавляющем большинстве случаев (если исключить команду из одного человека) она ведётся распределённой.
Мне кажется, мы вкладываем в «централизованный» разный смысл.
— Но это начинает работать, только когда очень большая команда и очень большой проект. А когда это в рамках небольшой компании, достаточно централизованной, то тут преимущества Git не дает?
— Тогда нет, конечно. Если маленькая команда, и если мы еще к тому же стараемся не делать много бранчей, или, например, всё разрабатываем только в одной основной ветке с так называемыми feature-флагами — тут преимущества Git теряются. Особенно, если маленькая команда.
Не согласен. Как раз для маленькой команды (в предельном случае — один человек) Git/Mercurial гораздо удобнее тяжеловесного SVN. А главное премущество SVN как раз существенно на больших проектах — можно работать с поддеревьями
Вообще само противопоставление ложно. Git и SVN — это не две взаимоисключающие альтернативы. У нас на работе вообще TFS в качестве хранилища кода. Однако ничто не мешает мне использовать Git локально, а в основное хранилище коммитить только после того, как успешно смержу новый код с чужими изменениями внутри своего репозитория.
То есть вы считаете, что неполноценность (неудобность) TFS без локального Git — это нормально и так и должно быть? Какие преимущества дает TFS?
TFS используется только потому, что в нём одновременно есть ещё и система тикетов, и какие-то чисто менеджерские инструменты для анализа того, на что уходит время. Но если отвечать на поставленный вопрос, то… да, я считаю, что неполноценность TFS — это нормально. В том смысле, что это неизбежно. Это один из законов Джона Галла: «Любая система по мере роста постепенно утрачивает основные функции.» Другими словами, TFS нельзя ни починить, ни заменить равным по функциональному охвату аналогом, который был бы лучше. Можно лишь как-то компенсировать отдельные его недостатки при помощи других систем.
НЛО прилетело и опубликовало эту надпись здесь
Если «фичи» делать отключаемыми, то теоретически должно и с одним trunk-ом всё получиться.
А в чем проблема? Все коммитится в транк, фичи, прошедшие QA, мёрджатся в релизные ветки. Что именно вы считаете «тяжеловатым»?
Также с 1 единственным trunk-ом и pull request-ами фич слышал о таком workflow: замержить pullrequest может только другой разработчик, который должен сначала сделать code review. Вообще, эта идея мне очень понравилась:
1) code review само по себе отлично и мне кажется может сильно поднять общий уровень команды и качество кода
2) решает проблему совместного владения кодом
3) взгляд со стороны может помочь выявить ошибки до merge pull request
1) code review само по себе отлично и мне кажется может сильно поднять общий уровень команды и качество кода
2) решает проблему совместного владения кодом
3) взгляд со стороны может помочь выявить ошибки до merge pull request
У нас workflow при работе с SVN построен так:
1) В транк (дев ветка) может коммитить любой что угодно, что не ломает компиляцию и юнит тесты (ну и то что не ломает фнукционал явно)
2) Транк — только для разработчиков, клиенты его никак не видят, на их работу ничто не влияет
2.5) Если код сложный и ты не уверен, запрашиваешь у коллеги ревью по номеру тикета, в котором записаны все твои коммиты
3) Когда нужно заdeployить что-то клиенту, сначала конкретная сборка (по номеру) из транка тестируется QA, они дают добро на мёрдж в RC ветку
4) Из dev в rc мерджатся конкретные коммиты для этой функции
5) rc конкретной версии тестируется QA как на эту фичу, так и на основной функционал (периодически)
6) Прошедшая все проверки rc версия штампуется как стабильная и может быть установлена клиенту или на демо-сервер.
Естественно, в случае, если все сработало и код не отправлен на доработку.
1) В транк (дев ветка) может коммитить любой что угодно, что не ломает компиляцию и юнит тесты (ну и то что не ломает фнукционал явно)
2) Транк — только для разработчиков, клиенты его никак не видят, на их работу ничто не влияет
2.5) Если код сложный и ты не уверен, запрашиваешь у коллеги ревью по номеру тикета, в котором записаны все твои коммиты
3) Когда нужно заdeployить что-то клиенту, сначала конкретная сборка (по номеру) из транка тестируется QA, они дают добро на мёрдж в RC ветку
4) Из dev в rc мерджатся конкретные коммиты для этой функции
5) rc конкретной версии тестируется QA как на эту фичу, так и на основной функционал (периодически)
6) Прошедшая все проверки rc версия штампуется как стабильная и может быть установлена клиенту или на демо-сервер.
Естественно, в случае, если все сработало и код не отправлен на доработку.
НЛО прилетело и опубликовало эту надпись здесь
А из транка нужные фичи как выбираются? Cherry picking?
По revision, если одни куском или по номеру таска, что проще.
А всякие svn-ы так умеют, или нужно вручную конкретные файлы переносить?
И так и так можно. Можно… ща выгвоворю… смёрджить фичу в другой бранч целиком. А можно руками (иногда приходится руками, в силу разницы между ветками, тут никто не поможет, никакая СКВ).
А если две фичи один и тот же файл изменяют? А если команда больше и фич в разработке много?
Конфликт, ресолв, пересобрать, проверить, мердж.
А чем SVN тяжеловесен?
Как минимум, необходимостью иметь и админить свой сервер. Гугл-код закрыли, остался только вроде помоечный sourceforge из публичных и бесплатных, которые поддерживают svn? И то не знаю, как там с приватными репами. Для Git есть Bitbucket, Gitlab. Завел проект за 5 минут и вперед.
@gvsmirnov выше написал, почему он не располагает к мелким коммитам, бранчам c экспериментами, активной параллельной работе в нескольких направлениях. Это то, что нужно в начале проекта.
К примеру, созданием веток. Я бы может быть и смерился с тем, что SVN для ветки все копирует и весить она может очень много по сравнению с git. Больше всего мне не нравится, что в SVN нельзя создавать ветки локально, коммитить локально, и решать позже — хочешь ли ты чтобы это попало в центральный репозиторий или тебе нужно еще что-то закончить или вообще этому не место в центральном репозитории.
А и ещё, в Git ведь тоже можно с поддеревьями работать. Не знаю, на сколько хорошо это работает, но команда такая имеется.
Я имел ввиду в первую очередь скачивание и пуш только поддерева, с которым работаешь. Натыкался на это. Но оказывается уже есть: http://stackoverflow.com/questions/600079/how-do-i-clone-a-subdirectory-only-of-a-git-repository, и довольно давно.
Gradle мощный, но порог вхождения у него такой же как у maven'a, если не проще, можно не использовать всю мощь. Если инструмент просто настроить и просто с ним работать, а вся его остальная мощность тебе не нужна, но вдруг понадобиться? Что выбрать? Вот и выбирают gradle, еще все проекты для Android крутятся вокруг gradle.
Git уже давно пережил стадию «моды», но многим до сих пор кажется что это мода.
Git уже давно пережил стадию «моды», но многим до сих пор кажется что это мода.
вся его остальная мощность тебе не нужна, но вдруг понадобиться?
Всё так. Точно так же мы склонные усложнять дизайн раньше времени, потому что «а вдруг понадобится? а вдруг надо будет расширять и вводить новые возможности» В результате имеем излишние абстракции и усложнения там где их могло бы не быть. Философская тема.
еще все проекты для Android крутятся вокруг gradle
Тут всё таки другая причина. Для Android Gralde стандарт не потому, что разработчики так захотели, а потому, что производитель так решил.
Ну и потому что с зоопарком Андройда ничем другим не справиться.
Ну тут очень тонкий момент. И намой взгляд нужно смотреть в том ключе, а мешают ли те функции, которые на данный момент являются избыточными?
В случае с SVN/Git — у гита есть практически всё, что есть у SVN, но и много всего другого тоже. При этом наличие дополнительных возможносте практически никак не влияет, если его использовать как SVN. Как бы дико это не звучало. Но если понадобится, если команда дозреет, то можно просто начать использовать.
В случае с Gradle/Maven — все несколько сложнее. Да Gradle в целом функциональнее. Но это функциональность в ряде случаев может явно сыграть в минус и это ничем нельзя (пока) компенсировать.
К чему это я? А к тому, что я часто встречаю аналогичную аргументацию, мол сейчас не нужно, по этому будем использовать другое. А на практике оказывается, что когда дополнительная функциональность понадобилась — то уже поздно. Собственно, тот факт, что понадобились продвинутые функции уже и означает, что поздно. Нештатная ситуация — вот она, а средст для её разрешения нету.
Из личного опыта: у нас изначально использовался Mercurial. Хотя на первых этапах использование было в стиле SVN. Но когда понадобилось — никаких проблем.
При этом мы изначально взяли Maven. И до сих пор на нём. Но когда вылазят нестандартные ситуации, то начинается адъ и Израиль с Ant вставками. А иногда и до JavaScript вставок через Ant вставки дело доходит. Но и мигрировать на Gradle не можем т.к. энтерпрайз, много больших команд и нету полного доверия между разработчиками (привет вашему докладу с Барухом).
Так что не всё так однозначно и надо подходить к вопросу вдумчиво и осторожно.
В случае с SVN/Git — у гита есть практически всё, что есть у SVN, но и много всего другого тоже. При этом наличие дополнительных возможносте практически никак не влияет, если его использовать как SVN. Как бы дико это не звучало. Но если понадобится, если команда дозреет, то можно просто начать использовать.
В случае с Gradle/Maven — все несколько сложнее. Да Gradle в целом функциональнее. Но это функциональность в ряде случаев может явно сыграть в минус и это ничем нельзя (пока) компенсировать.
К чему это я? А к тому, что я часто встречаю аналогичную аргументацию, мол сейчас не нужно, по этому будем использовать другое. А на практике оказывается, что когда дополнительная функциональность понадобилась — то уже поздно. Собственно, тот факт, что понадобились продвинутые функции уже и означает, что поздно. Нештатная ситуация — вот она, а средст для её разрешения нету.
Из личного опыта: у нас изначально использовался Mercurial. Хотя на первых этапах использование было в стиле SVN. Но когда понадобилось — никаких проблем.
При этом мы изначально взяли Maven. И до сих пор на нём. Но когда вылазят нестандартные ситуации, то начинается адъ и Израиль с Ant вставками. А иногда и до JavaScript вставок через Ant вставки дело доходит. Но и мигрировать на Gradle не можем т.к. энтерпрайз, много больших команд и нету полного доверия между разработчиками (привет вашему докладу с Барухом).
Так что не всё так однозначно и надо подходить к вопросу вдумчиво и осторожно.
Но когда вылазят нестандартные ситуации, то начинается адъ и Израиль с Ant вставками.
Это, простите чисто ваши особенности. Тот же groovy вполне доступен из сборки maven, и очень давно был. gaven наверное уже лет 8 существует. И он поверьте, не менее гибкий в конечном счете, чем gradle — может быть просто слегка другой.
По поводу IDEA vs Eclipse. Работал в Eclipse более 10 лет. В этом году перешел на IDEA по трем причинам (в порядке убывания веса): месяцами не чинящиеся баги, в частности с лямбдами, невменяемый автокомплит (когда вместо своих классов сначала показываются одноименные классы из дремучих дебрей JDK), ужасная dark theme.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Java DevTools: модно не значит хорошо