По своему опыту могу предположить, что человек просто мог не понимать как правильно реализовывать(или даже просто примитивно реализовать) то, что он хочет.
Опытным людям идеи реализаций сами по себе в голову лезут, но новичкам — не всегда.
Для меня это как посмотреть сериал или кино вечером или на выходных, только можно ещё и пользу получить. Плюс основная фишка стримов не в собственно видео, а в комьюнити и, особенно, в чате. Ты видишь чувака, который кодит на том же, на чём и ты, заходишь на стрим и спрашиваешь — слушай, а для функциональных тестов ты что используешь? Или — слушай, а ты не знаешь какую-нибудь либу, чтобы вебсокеты асинхронно держать? Или — слушай, мне нужно впилить класс, у которого четыре метода, но у каждого метода может быть несколько вариантов реализации, как это всё лучше декомпозировать? И тут же получаешь фидбек от стримера и чата. А можно ничего не спрашивать, просто смотреть и вылавливать что-то интересное.
Посмотреть как происходит процесс программирования и отладки, наверное. Правда, не могу представить что зрители такого уровня могут подсказать или посоветовать стримеру.
вся его остальная мощность тебе не нужна, но вдруг понадобиться?
Всё так. Точно так же мы склонные усложнять дизайн раньше времени, потому что «а вдруг понадобится? а вдруг надо будет расширять и вводить новые возможности» В результате имеем излишние абстракции и усложнения там где их могло бы не быть. Философская тема.
еще все проекты для Android крутятся вокруг gradle
Тут всё таки другая причина. Для Android Gralde стандарт не потому, что разработчики так захотели, а потому, что производитель так решил.
Gradle мощный, но порог вхождения у него такой же как у maven'a, если не проще, можно не использовать всю мощь. Если инструмент просто настроить и просто с ним работать, а вся его остальная мощность тебе не нужна, но вдруг понадобиться? Что выбрать? Вот и выбирают gradle, еще все проекты для Android крутятся вокруг gradle.
Git уже давно пережил стадию «моды», но многим до сих пор кажется что это мода.
К примеру, созданием веток. Я бы может быть и смерился с тем, что SVN для ветки все копирует и весить она может очень много по сравнению с git. Больше всего мне не нравится, что в SVN нельзя создавать ветки локально, коммитить локально, и решать позже — хочешь ли ты чтобы это попало в центральный репозиторий или тебе нужно еще что-то закончить или вообще этому не место в центральном репозитории.
— Но это начинает работать, только когда очень большая команда и очень большой проект. А когда это в рамках небольшой компании, достаточно централизованной, то тут преимущества Git не дает?
— Тогда нет, конечно. Если маленькая команда, и если мы еще к тому же стараемся не делать много бранчей, или, например, всё разрабатываем только в одной основной ветке с так называемыми feature-флагами — тут преимущества Git теряются. Особенно, если маленькая команда.
Не согласен. Как раз для маленькой команды (в предельном случае — один человек) Git/Mercurial гораздо удобнее тяжеловесного SVN. А главное премущество SVN как раз существенно на больших проектах — можно работать с поддеревьями
Если моя большая фича состоит из нескольких более маленьких фич и я хочу закоммитить каждую маленькую фичу, а запушить только большую — то в свне без сервера я так не смогу, а в гите — смогу. Коммиты должны быть атомарными, максимально дроблёными для того чтобы можно было bisect'ом понять, какой именно из них привнёс проблему.
Для маленьких проектов и разных вкусов — впринципе согласен, но SVN навязывает центральный репозиторий. git — же дает право выбора — хочешь центральный, хочешь локальный + центральный и каждый разработчик может выбрать сам для себя. Я работаю в маленькой команде и они используют SVN — а я хочу иметь возможность коммитить локально :)
Вы имеете в виду, что вы не можете закоммитить что-либо, что сломает билд?
Зачем сразу ломать :) На моей работе случается с регулярностью в несколько дней. Билды у нас делает QA Engineer, он говорит: «Хочу собрать билд». Разработчик: «Ой я делаю фичу — уже сделал коммит, подожди 30мин пока я закончу». Билд накатывается на демо-сервер, и что-то незаконченное там — не смерть, но сервер могут демонстрировать клиенту, там не должно быть меню на которое ты кликаешь и ничего не происходит. Я всегда, когда это слышу — «подожди пока я закомичу» — вспоминаю Git.
Стоп-стоп-стоп, с этого места подробнее.
По поводу svn update or git pull без интернета — это понятно. Я о другом — git позволяет не менять привычек независимо от того есть у вас интернет или нет — вы продолжаете разбивать задание на маленькие кусочки, и делать маленькие коммиты, коммиты — это как история проекта, вы можете откатиться к предыдущему комиту, сделать бренч для фичи — интернет не нужен. Это не тоже самое, что и ctlr+s, это намного могущественнее :) Но вы правы, что не всем это нужно — это больше зависит от стиля и привычек.
Разные команды — разные потребности — разные принципы работы. Вполне есть ситуации, когда Git реально просто не нужен.
Согласен, но после использования git, при использовании SVN я часто ощущаю, что мне не хватает гибкости git.
А когда я использую git локально вместе с SVN я думаю, что один из них лишний — лучше либо менять свои привычки, либо переходить на git. Проблема SVN — он заставляет менять привычки, и то, что в лучшую сторону — это очень спорно. Git же позволяет работать в своем стиле локально независимо от всего, а пушить на центральный репозиторий в том стиле который хочет команда.
Что svn лучше git на маленьких проектах — у меня противоположное мнение.
Не столько лучше, сколько адекватнее маленькому проекту. Если команда маленькая и разработка централизована, идеология центрального репозитория подходит лучше. В таких случаях убеждать кого-либо в том, что распределенный контроль версий лучше потому что он распределенный — все равно что утверждать, что зеленая машина лучше желтой, потому что она зеленая.
В SVN же не нравится, что комит должен быть готовой фичей, и соответственно не всегда может быть маленьким (в гите ты можешь делать сколько угодно маленькие коммиты и пушить готовую фичу).
Извините, я не понял этой фразы. Вы имеете в виду, что вы не можете закоммитить что-либо, что сломает билд? В принципе, верно. Но. Если изменение даже не компилируется, надо ли вообще стремиться его класть куда-либо? В конце концов никто не мешает иметь свою базу/ветку, если вы боитесь за сохранность данных на диске и т.п. Если оно не ломает билд, почему вы не можете его закоммитить в транк, который все равно никому не виден, кроме коллег?
Иногда у меня нет доступа к SVN серверу (потому что к примеру нет интернета под боком), я сижу и думаю о том, что git давно решил эту проблему.
Стоп-стоп-стоп, с этого места подробнее. Какую именно проблему? Если вам нужны последние изменения кого-либо из коллег, вам все равно нужен доступ к сети, какой бы СКВ ни была. А иначе СКВ вам нужна лишь для собственных коммитов, что важно только если вы будете переключаться между задачами (в противном случае весь «коммит» это Ctrl+S). Чего в отсутствие сети все равно сделать нельзя, раз трекер недоступен. Да и, например, у нас «производственный процесс» требует постоянного присутствия — либо IP телефон, либо скайп. Так что либо сеть есть, либо ты не работаешь.
Разные команды — разные потребности — разные принципы работы. Вполне есть ситуации, когда Git реально просто не нужен.
PS вполне рабочая комбинация SVN и Git локально.
Незнаю, мне он не очень показался трезвым. Сам использую только svn на работе и только git дома. Что svn лучше git на маленьких проектах — у меня противоположное мнение. В SVN же не нравится, что комит должен быть готовой фичей, и соответственно не всегда может быть маленьким (в гите ты можешь делать сколько угодно маленькие коммиты и пушить готовую фичу).
Иногда у меня нет доступа к SVN серверу (потому что к примеру нет интернета под боком), я сижу и думаю о том, что git давно решил эту проблему. Также если охото поэксперементировать, если SVN — то ничего не сделаешь, бренч создавать из пушки по слонам, в итоге работаешь вообще без контроля версий — в гит нет такой проблемы, комить локально сколько влезет.
Вообщем локальные коммиты делают гит для меня намного привлекательнее чем SVN.
Не такой уж он и липкий. Мне какой-то Шон написал всего два письма. В первом спросил, удалось ли мне всё установить и настроить. Во втором интересовался тем, пробую ли я чисто для себя или для всей команды. На каждое я ответил всего парой предложений и он отлип…
Липкий маркетинг я получил от coverity, когда мне писали несколько раз и потом звонили из Ирландии(?) и просили соединить меня с моим руководителем, чтобы показать ему (раз уж я не могу принять такого решения) все преимущества полной версии продукта.
Опытным людям идеи реализаций сами по себе в голову лезут, но новичкам — не всегда.
Всё так. Точно так же мы склонные усложнять дизайн раньше времени, потому что «а вдруг понадобится? а вдруг надо будет расширять и вводить новые возможности» В результате имеем излишние абстракции и усложнения там где их могло бы не быть. Философская тема.
Тут всё таки другая причина. Для Android Gralde стандарт не потому, что разработчики так захотели, а потому, что производитель так решил.
Git уже давно пережил стадию «моды», но многим до сих пор кажется что это мода.
Не согласен. Как раз для маленькой команды (в предельном случае — один человек) Git/Mercurial гораздо удобнее тяжеловесного SVN. А главное премущество SVN как раз существенно на больших проектах — можно работать с поддеревьями
Если моя большая фича состоит из нескольких более маленьких фич и я хочу закоммитить каждую маленькую фичу, а запушить только большую — то в свне без сервера я так не смогу, а в гите — смогу. Коммиты должны быть атомарными, максимально дроблёными для того чтобы можно было bisect'ом понять, какой именно из них привнёс проблему.
Зачем сразу ломать :) На моей работе случается с регулярностью в несколько дней. Билды у нас делает QA Engineer, он говорит: «Хочу собрать билд». Разработчик: «Ой я делаю фичу — уже сделал коммит, подожди 30мин пока я закончу». Билд накатывается на демо-сервер, и что-то незаконченное там — не смерть, но сервер могут демонстрировать клиенту, там не должно быть меню на которое ты кликаешь и ничего не происходит. Я всегда, когда это слышу — «подожди пока я закомичу» — вспоминаю Git.
По поводу svn update or git pull без интернета — это понятно. Я о другом — git позволяет не менять привычек независимо от того есть у вас интернет или нет — вы продолжаете разбивать задание на маленькие кусочки, и делать маленькие коммиты, коммиты — это как история проекта, вы можете откатиться к предыдущему комиту, сделать бренч для фичи — интернет не нужен. Это не тоже самое, что и ctlr+s, это намного могущественнее :) Но вы правы, что не всем это нужно — это больше зависит от стиля и привычек.
Согласен, но после использования git, при использовании SVN я часто ощущаю, что мне не хватает гибкости git.
А когда я использую git локально вместе с SVN я думаю, что один из них лишний — лучше либо менять свои привычки, либо переходить на git. Проблема SVN — он заставляет менять привычки, и то, что в лучшую сторону — это очень спорно. Git же позволяет работать в своем стиле локально независимо от всего, а пушить на центральный репозиторий в том стиле который хочет команда.
Один мой друг сказал что на определённом уровне начинаем продавать мы все. Главное дойти до этого уровня :)
Сейлзы это, а не маркетинг. Сейлзы. И да, это как джава и дажавскрипт, звучит похоже, но совсем не то.
Не столько лучше, сколько адекватнее маленькому проекту. Если команда маленькая и разработка централизована, идеология центрального репозитория подходит лучше. В таких случаях убеждать кого-либо в том, что распределенный контроль версий лучше потому что он распределенный — все равно что утверждать, что зеленая машина лучше желтой, потому что она зеленая.
Извините, я не понял этой фразы. Вы имеете в виду, что вы не можете закоммитить что-либо, что сломает билд? В принципе, верно. Но. Если изменение даже не компилируется, надо ли вообще стремиться его класть куда-либо? В конце концов никто не мешает иметь свою базу/ветку, если вы боитесь за сохранность данных на диске и т.п. Если оно не ломает билд, почему вы не можете его закоммитить в транк, который все равно никому не виден, кроме коллег?
Стоп-стоп-стоп, с этого места подробнее. Какую именно проблему? Если вам нужны последние изменения кого-либо из коллег, вам все равно нужен доступ к сети, какой бы СКВ ни была. А иначе СКВ вам нужна лишь для собственных коммитов, что важно только если вы будете переключаться между задачами (в противном случае весь «коммит» это Ctrl+S). Чего в отсутствие сети все равно сделать нельзя, раз трекер недоступен. Да и, например, у нас «производственный процесс» требует постоянного присутствия — либо IP телефон, либо скайп. Так что либо сеть есть, либо ты не работаешь.
Разные команды — разные потребности — разные принципы работы. Вполне есть ситуации, когда Git реально просто не нужен.
PS вполне рабочая комбинация SVN и Git локально.
Иногда у меня нет доступа к SVN серверу (потому что к примеру нет интернета под боком), я сижу и думаю о том, что git давно решил эту проблему. Также если охото поэксперементировать, если SVN — то ничего не сделаешь, бренч создавать из пушки по слонам, в итоге работаешь вообще без контроля версий — в гит нет такой проблемы, комить локально сколько влезет.
Вообщем локальные коммиты делают гит для меня намного привлекательнее чем SVN.