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