Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 97
Покажите админам gitosis, он им понравится.
В отличие от других систем контроля версий, git хранит все свои данные в одном каталоге, а не плодит повсюду папки .svn.
Кроме SVN никто и не плодит папки .svn. Лучше прямо скажите, что кроме GIT и SVN вы ничего не пробовали. Например Mercurial (Hg) тоже держит все в одной папке.
Все-таки коммитить файлы проекта — не лучшая идея. Нельзя всех заставлять использовать одну IDE — как бы ни были хороши Aptana, прочие Eclipse-производные, и так далее — они не идеальны для всех.
Так же нехорошо держать под контролем версий настройки копий проектов — такие вещи должны генерироваться полуавтоматически и игнорироваться системой контроля версий — иначе это кончится десятком почти одинаковых файлов с именами вида «k12th.settings.py». Почему я должен в диффах видеть, как кто-то у себя переименовал папку с проектом?
Насчет бинарников — их не надо выключать из проекта, а надо просто указать, что данные файлы — бинарные (то есть, что их не надо пытаться диффать и мерджить). PSD-файлы бывает полезно версионировать — особенно в случаях типа «а вот три месяца назад у нас была кнопка с иконкой для того-то, давайте ее вернем».
Если админы не понимают, чем git лучше svn — это плохие админы:) Хорошие админы приложат все усилия, чтобы разрулить проблемы прав.
Так же нехорошо держать под контролем версий настройки копий проектов — такие вещи должны генерироваться полуавтоматически и игнорироваться системой контроля версий — иначе это кончится десятком почти одинаковых файлов с именами вида «k12th.settings.py». Почему я должен в диффах видеть, как кто-то у себя переименовал папку с проектом?
Насчет бинарников — их не надо выключать из проекта, а надо просто указать, что данные файлы — бинарные (то есть, что их не надо пытаться диффать и мерджить). PSD-файлы бывает полезно версионировать — особенно в случаях типа «а вот три месяца назад у нас была кнопка с иконкой для того-то, давайте ее вернем».
Если админы не понимают, чем git лучше svn — это плохие админы:) Хорошие админы приложат все усилия, чтобы разрулить проблемы прав.
ну тут как договоритесь
например, у нас все работают на Flash Builder, файлы проекта одни на всех и не часто меняются
такая вот утопия
например, у нас все работают на Flash Builder, файлы проекта одни на всех и не часто меняются
такая вот утопия
Это решается соглашениями в команде — за этим следит team lead. Кроме прочего, нужно поддерживать постоянную интеграцию (CI) и автоматическую сборку (вот финальная сборка и тестовые/продакшн-настройки могут быть в мастер-ветке, специфичные настройки разработчики могут хранить в локальных ветках).
Насчет разных IDE и файлов проектов — есть такая тема, но тут ничего не поделаешь — как я уже сказал, в мастер-ветке можно хранить файл уже интегрированного рабочего проекта, когда все работает, тесты выполняются и не предполагается, что кто-то сделает что-то, что сломает содержимое мастер-ветки (ну, и CI в помощь — этот метод предполагает, что если кто-то что-то ломает своим коммитом — должен это исправить).
Насчет разных IDE и файлов проектов — есть такая тема, но тут ничего не поделаешь — как я уже сказал, в мастер-ветке можно хранить файл уже интегрированного рабочего проекта, когда все работает, тесты выполняются и не предполагается, что кто-то сделает что-то, что сломает содержимое мастер-ветки (ну, и CI в помощь — этот метод предполагает, что если кто-то что-то ломает своим коммитом — должен это исправить).
Простите, не очень понял, как связаны CI и файл проекта от IDE? Если сборка в CI осуществляется каким-нибудь, например, Ant'ом — то ему нужен build.xml, а не .nbproject от моей NetBeans.
Я неправильно выразился. В общем, нужно сделать так, чтобы поддерживался файл проекта (.csproj, напрмер), актуальный для текущей рабочей версии проекта (или, точнее, для части проекта — ведь не весь проект может создаваться одним средством). Я имел в виду под CI всю концепцию, методику, а не только автоматический билд решения.
Ну, если среда/платформа подразумевает, что файл проекта и файл билда — одно и то же (как в случае с .Net, если я правильно понял), то таки да, вы правы.
Я просто хочу сказать, что в общем случае файл сборки и файл проекта — не одно и то же, и что тащить вспомогательные файлы в проект не очень хорошо:)
Я просто хочу сказать, что в общем случае файл сборки и файл проекта — не одно и то же, и что тащить вспомогательные файлы в проект не очень хорошо:)
Нет, нет, в .NET файл проекта и файл билд инструкции для NAnt — это разные вещи. Просто одно дело билд, а другое дело — исходники проекта. Думаю, с исходниками всяко надо иметь вспомогательные файлы, ведь надо запускать проект в его актуальном состоянии сразу после checkout, например, из HEAD-ревизии. Или, по вашему, нет? :)
У меркуриала смешанная нумерация (линейная и хеш), может стоит попробовать его, если это так критично?
Можно ли как-нибудь, используя Git, использовать старую нумерацию, пускай даже извращенными методами?
У вас желания неправильные. Цель не в том, что номерки расходятся, а в том что понять синхронизирован ли локальный репозиторий с удаленным. Мы уже почти месяц с большим проектом на mercurial, и проблемы такой не возникло еще.
В гите для подобного есть комманда «git describe» которая генерирует user-friendly версию. Примерно такую
v2.1.5-86-g655efd3
Эта комманда говорит что текущая ветка основана на таге v2.1.5, отстоит от него на 86 коммитов и затем hash последнего коммита.
v2.1.5-86-g655efd3
Эта комманда говорит что текущая ветка основана на таге v2.1.5, отстоит от него на 86 коммитов и затем hash последнего коммита.
> Маководы могут скачать дистрибутив с официального сайта или установить через MacPorts.
А еще можно через Homebrew. Он тянет меньше зависимых пакетов, и по максимуму использует установленные либы, в отличие от Macports, который кучу библиотек, которые уже есть в системе, инсталит по новой.
А еще можно через Homebrew. Он тянет меньше зависимых пакетов, и по максимуму использует установленные либы, в отличие от Macports, который кучу библиотек, которые уже есть в системе, инсталит по новой.
А не могли бы вы поподробнее рассказать про слияние веток? по какому алгоритму оно происходит? Вот есть файл в мастере
Программист 1 добавил изменение:
public class Test {
private var data:Array;
private data1:Array;
public function Test() extends MovieCLip {
trace('Test');
}
public function test1() extends MovieCLip {
trace('test1');
}
}
Программист 2 добавил изменение:
public class Test {
private var data:Array;
public function Test() extends MovieCLip {
trace();
}
}
Программист 1 добавил изменение:
public class Test {
private var data:Array;
private data1:Array;
public function Test() extends MovieCLip {
trace('Test');
}
public function test1() extends MovieCLip {
trace('test1');
}
}
Программист 2 добавил изменение:
а как в GIT происходит слияние веток, а конкретно файлов, на пальцах?
допустим в master у нас было:
Программист 1 добавил пару переменных и функцию
Программист 2 параллельно так же работал на этим файлом он добавил свои переменные
Что будет в итоге?
допустим в master у нас было:
var test:Array;
function test() {};
Программист 1 добавил пару переменных и функцию
var test:Array;
var test1:Array;
function test(func_var1:Array) {};
function test1() {};
Программист 2 параллельно так же работал на этим файлом он добавил свои переменные
var test:Array;
var test2:Array;
function test(func_var2:Array) {};
function test2() {};
Что будет в итоге?
конфликт будет :-)
В итоге будет merge conflict как и в любой другой VCS без встроенного искусственного интеллекта.
Ну я больше по меркуриалу, там будет конфликт. В нем вообще нет родной мержилки для файлов, в мерж это больше операция объединения голов в ветках чем слива изменений в одном файле.
а что такое «объединения голов в ветках»? на пальцах )) перезаписать из одной ветки файлами из другой?
какой тогда тайный смысл в GIT кроме локального удобства разработчика? ну есть ветка, мы мерджим её с другой. Этот мердж происходит без проблем только в теоретических случаях. На практике мы апдейтимся до текущей версии master потом как-то руками пытаемся впихнуть наши измеменения.
ИМХО, если два человека меняют в одном месте что-то это проблема не системы контроля версий а организации процесса, как уже заметили, тут никакая система контроля версий не поможет.
Мерж в распределенных системах лучше (я говорю за Меркуриал) в том, сохраняется история кто чего с чем мержил, в отличии от SVN.
Вы пробовали вести ветки в SVN? А потом вливать изменения в транк? Там проще было застелиться, иногда конфликты были такие тупые…
Мерж в распределенных системах лучше (я говорю за Меркуриал) в том, сохраняется история кто чего с чем мержил, в отличии от SVN.
Вы пробовали вести ветки в SVN? А потом вливать изменения в транк? Там проще было застелиться, иногда конфликты были такие тупые…
знаю по перфорсу — вот это действительно, смержить ветки за пару недель — задача на полдня. где в гите был бы фастфорвард
Согласен полностью насчет проблем с мерджем, но что тут скажешь — вопрос не самих репозиториев, а способов работы с ними и (важно!) того как построено само решение — ноги растут именно оттуда. С использованием SOLID нечасто приходится проводить «сложные мерджи» одних и тех же файлов — все должно быть развязано и независимо.
Статья хорошая, годная. Вот хотелось бы побольше узнать о том, почему вы перешли с корп СВН на самопальный ГИТ и как вы пропустили Меркуриал?
also
when i see «chmod -R 777» i shit bricks.
also
when i see «chmod -R 777» i shit bricks.
Я полагаю, что люди повелись на более-менее вменяемый GUI клиент.
Мы вот перешли на меркуриал, меня смутили набор команд в гите в кучей труднозапоминаемых ключей, когда в меркуриале все как-то проще, ну и уже упомянутая доточенная напильником поддержка винды.
Но я наслушался матюков в свою сторону :-) после перехода со SmartSVN.
TortoroiseHg весьма странный SmartHg еще не выпустили (и не факт что выпустят). Не все программеры привыкли в коммандной строке работать. А из IDE много не сделаешь…
Мы вот перешли на меркуриал, меня смутили набор команд в гите в кучей труднозапоминаемых ключей, когда в меркуриале все как-то проще, ну и уже упомянутая доточенная напильником поддержка винды.
Но я наслушался матюков в свою сторону :-) после перехода со SmartSVN.
TortoroiseHg весьма странный SmartHg еще не выпустили (и не факт что выпустят). Не все программеры привыкли в коммандной строке работать. А из IDE много не сделаешь…
Ну мы же не холивары тут разводим. Здесь больше концептуальное обсуждение чем распределенная система контроля версий лучше/хуже чем цетрализированная.
Если есть время, то послушайте первые три UTP подкаста Уптутуна: utp.umputun.com
В кратце: ветки вести намного проще в гите/меркуриале. Что выбрать — личное дело каждой группы разработчиков.
Если есть время, то послушайте первые три UTP подкаста Уптутуна: utp.umputun.com
В кратце: ветки вести намного проще в гите/меркуриале. Что выбрать — личное дело каждой группы разработчиков.
А как вы решаете (или не решаете) такую проблему?
Судя по описанию у вас фичи разработчиков находятся в локальных ветках. Допустим, что в релиз ХХ вы решили поставить фичи 1,2,3 но в последний момент поняли что фича 2 там не надо и нужно ставить только 1 и 3.
После того как девелоперы закоммитили в интеграционную ветку свои изменения их пересобрать по частям как-то сложновато. Мы не придумали как это сделать без лишнего головняка.
Судя по описанию у вас фичи разработчиков находятся в локальных ветках. Допустим, что в релиз ХХ вы решили поставить фичи 1,2,3 но в последний момент поняли что фича 2 там не надо и нужно ставить только 1 и 3.
После того как девелоперы закоммитили в интеграционную ветку свои изменения их пересобрать по частям как-то сложновато. Мы не придумали как это сделать без лишнего головняка.
и мы
можно замарочится и вести ветку на каждую фичу. согласен, что это в некоторой степени гемор, но зато для сборки клиента можно делать выборки из бранчей.
Это не геморой, а правильное использование веток :))
ну если фичи мелкие то много времени уходит на switch веток. плюс параллельные фиксы багов в отдельную ветку. в общем привыкать довольно сложно.
Если отталкиваться от SVN, то да, они (бранчи) хоть в буке (SVNBook) описываются, но от них как правило отказываются. В git всё гораздо прозрачней. В любом случае при правильном подходе 1 фича = 1 разработчик(группа) на единый момент времени, а не 10 фич = 1 разработчик.
не бывает 1 фича = 1 разработчик. обычно 10 разработчиков = 100 фич.
к тому же причём тут свн? мы же про гит говорим.
к тому же причём тут свн? мы же про гит говорим.
Но фичи делаются по очереди)). Просто я не вижу больших проблем при мёрдже в гите и почему там уходит много времени на это.
Согласен, rebase, fast forward merge, и никаких траблов :)
Разумеется, если все это правильно использовать.
Разумеется, если все это правильно использовать.
вы не правы. вот делаете Вы фичу. к вам подбегает взъерошенный геймдиз и начинает в панике рассказывает о критическом баге, который прямо сейчас нужно залить. а за спиной у него стоит серверник, который хочет, что вы сделали ему клиент, с его фичёй. но вы то делаете совершенно другую фичу.
но я тоже люблю верить в утопию )
но я тоже люблю верить в утопию )
Баги в транке правятся. Серверник отправляется к менеджерам проекта, т.е. в стек :))
В контексте Git, используйте stash, который потом сольете с исправленной версией (если это тот же проект). Создаете новую ветку, пишете новую фичу, сливаете в соответствующую изначальную (допустим, master) ветку, достаете данные из stash и продолжаете работать.
спасибо. я умею пользоваться гитом. и если вы считаете постоянное выполнение данных операций верхо удобства, то дальнейшая беседа бессмысленна. я же чётка сформулировал, «что это в некоторой степени гемор».
Ну вот и славно, что умеете. Значит ваш вопрос был просто не в том контексте, о чем я подумал.
В общем, целом и глобальном — идеальной утопии (как же вы любите это слово :) не бывает — разумеется, нет идеальных средств, но нет и нерешаемых ситуаций. Мы, видимо, просто о разном говорили.
P.S. И нет, эти команды — не верх удобства. Нужно правильно организовывать работу (и в целом, и с SCM — в частности).
В общем, целом и глобальном — идеальной утопии (как же вы любите это слово :) не бывает — разумеется, нет идеальных средств, но нет и нерешаемых ситуаций. Мы, видимо, просто о разном говорили.
P.S. И нет, эти команды — не верх удобства. Нужно правильно организовывать работу (и в целом, и с SCM — в частности).
А Вас не учили правилу «сделал таск — закоммитил»?)) На одной работе мы координально решали такие вещи (с свн). На каждую задачу поднимали вообще новую копию проекта и в ней делали всё, потом коммитили и убивали локально :)
Буду категоричен — у вас неправильно организована работа.
«коммитить он может что хочет и когда хочет» (а тем более — комплексную фичу!)
«Никаких четких правил на этот счет.»
Этого никак и никогда нельзя допускать. Это то, что однозначно (лишь вопрос времени) ведет к краху проекта. В такие моменты (завтра закроют приложение) — как нельзя больше нужна организация. Иначе, вы сами того не осознавая, потратите куда больше времени на «ручные правки», «костыли» и «временные решения».
«коммитить он может что хочет и когда хочет» (а тем более — комплексную фичу!)
«Никаких четких правил на этот счет.»
Этого никак и никогда нельзя допускать. Это то, что однозначно (лишь вопрос времени) ведет к краху проекта. В такие моменты (завтра закроют приложение) — как нельзя больше нужна организация. Иначе, вы сами того не осознавая, потратите куда больше времени на «ручные правки», «костыли» и «временные решения».
Бррр… Давайте по полкам.
Фича — новый функционал
Багфикс — исправление ошибок.
1 фича = 1 бранч
1 багфикс = комит в транк
Ситуация. Я работаю над новой фичей (придумайте сами какой), тут ко мне подбегает менеджер проекта и говорит, что есть баг, который нужно срочно пофиксить.
Мои действия. Я поднимаю проект заново (в отдельной папке), правлю баг и заливаю в репозиторий (если свн), или просто свитч на другую ветку (если тот же гит).
Укажите где я тут не прав.
Фича — новый функционал
Багфикс — исправление ошибок.
1 фича = 1 бранч
1 багфикс = комит в транк
Ситуация. Я работаю над новой фичей (придумайте сами какой), тут ко мне подбегает менеджер проекта и говорит, что есть баг, который нужно срочно пофиксить.
Мои действия. Я поднимаю проект заново (в отдельной папке), правлю баг и заливаю в репозиторий (если свн), или просто свитч на другую ветку (если тот же гит).
Укажите где я тут не прав.
Ну, как можно про что-то «забыть» или «не заметить»? Это уже вопрос самой организации рабочего процесса. При желании или при безответственности можно в чем угодно навести хаос.
P.S. Версионность, в данном случае — единственный выход избавления от полного хаоса.
P.S. Версионность, в данном случае — единственный выход избавления от полного хаоса.
«Я исхожу из постулата, то разработчик неизбежно ошибется и чем меньше оставить ему мест для ошибок тем эффективней будет разработка в целом.»
Именно так. Поэтому я и ответил на ваш комментарий выше, что нельзя пускать на что-либо на самотек и на усмотрение торопящегося девелопера (разберется, мол).
Именно так. Поэтому я и ответил на ваш комментарий выше, что нельзя пускать на что-либо на самотек и на усмотрение торопящегося девелопера (разберется, мол).
Согласен с предыдущим комментатором — это правильный подход. А затем, при необходимости коммита в основную ветку — нужно определить приоритеты и действовать последовательно. Ну а то, что какая-то фича, вдруг, просто «не нужна» — это скорее частный случай. Большинство разрабатываемых фич, все-таки нужно.
А в чем сложность пересобрать и как это зависит от репозитория? Есть такая техника как постоянная интеграция (CI), и ее нужно придерживаться. Иначе в любом случае «пересобирать сложновато» будет.
Ну в другой систме контроля версий это тоже не работало гладко.
Вопрос. Как исключить фичу Х из релиза? У нас релиз раз в неделю и не всегда все уходит на продакшн. Скажем 15 фич из девелоперской ветки ставятся, а 3 нет, как их безболезненно вырезать?
Вопрос. Как исключить фичу Х из релиза? У нас релиз раз в неделю и не всегда все уходит на продакшн. Скажем 15 фич из девелоперской ветки ставятся, а 3 нет, как их безболезненно вырезать?
Git — прекрасная VC-система. И она годится для разработки на чем угодно — например, отлично работает с C#/Visual Studio, используя Git Source Control Provider и GitExtensions.
Минус один — не так очевидно, с чего начать работу с Git. Зато, начав, уже не хочется переходить обратно на SVN/Mercurial/Perforce. Советую всем, кто не уверен, попробовать.
И еще — я не фанат командной строки, поэтому лично мне удобнее использовать GUI для всех основных сценариев.
Минус один — не так очевидно, с чего начать работу с Git. Зато, начав, уже не хочется переходить обратно на SVN/Mercurial/Perforce. Советую всем, кто не уверен, попробовать.
И еще — я не фанат командной строки, поэтому лично мне удобнее использовать GUI для всех основных сценариев.
Думаю, стоит упомянуть, что у git есть проблемы с именами файлов в UTF-8
Я позволю себе сравнить с subversion, с моей точки зрения
Ну так и в subversion все так же
Насчет папок .svn — не вижу тут большой проблемы. Лучше было бы без них, но мне они не мешают особо.
Про переключение — в subversion переключиться с ветки на ветку также легко, и содержимое аналогично заменяется. Возможно, тут есть ньюансы, и git переключает лучше, но этого я из текста статьи не понял.
Ну тут да, если нет интернета — ветку не создать. Пока мне лично не сильно мешало, однако, вещь полезная, безусловно плюс.
В subverion также помечаются нужные файлы, часть файла закоммитить… хм. Ну, не знаю.
Пока не понял, зачем это нужно.
Итого для себя один плюс — создание веток, когда нет интернета. Не густо, прямо скажем.
Ну, в таком раскладе, если админ обеспечивает «интернет», то его недоумение мне лично понятно — никаких других плюсов я лично пока не вижу.
Резюмируя — тема крупных преимуществ git (по сравнению с svn) не раскрыта, на мой взгляд. Однако, нутром чувствую, что-то у git есть. Возможно, там гораздо лучше реализован merge и переключение веток.
2. Простые ветки в git позволяют в любое время достать версию любого предыдущего релиза и работать с ней не мешая идущей разработке. Исправить баги в отдельной ветке, смержить в предыдущий релиз и в текущую разработку.
Ну так и в subversion все так же
3. git хранит все свои данные в одном каталоге, а не плодит повсюду папки .svn. Переключить проект с одной ветки на другую можно всего одной командой или парой кликов в клиенте. При этом содержимое папки проекта заменяется новым, которое соответствует выбранной ветке..
Насчет папок .svn — не вижу тут большой проблемы. Лучше было бы без них, но мне они не мешают особо.
Про переключение — в subversion переключиться с ветки на ветку также легко, и содержимое аналогично заменяется. Возможно, тут есть ньюансы, и git переключает лучше, но этого я из текста статьи не понял.
4. Как я уже сказал, все комиты сохраняются локально и становятся частью общего репозитория только тогда, когда непосредственно пушатся в него. Это сложно вообразить, но порой получается так, что нет доступа в интернет, а работать нужно.
Ну тут да, если нет интернета — ветку не создать. Пока мне лично не сильно мешало, однако, вещь полезная, безусловно плюс.
5. Удобные частичные комиты
Непосредственно перед комитом помечаются файлы, которые в него войдут с помощью git add. При этом существует возможность в отдельный комит внести часть изменений в файле, а не файл целиком.
В subverion также помечаются нужные файлы, часть файла закоммитить… хм. Ну, не знаю.
6. Возможность припрятать изменения.
Пока не понял, зачем это нужно.
Итого для себя один плюс — создание веток, когда нет интернета. Не густо, прямо скажем.
Сопротивление админов...
Ну, в таком раскладе, если админ обеспечивает «интернет», то его недоумение мне лично понятно — никаких других плюсов я лично пока не вижу.
Резюмируя — тема крупных преимуществ git (по сравнению с svn) не раскрыта, на мой взгляд. Однако, нутром чувствую, что-то у git есть. Возможно, там гораздо лучше реализован merge и переключение веток.
Извините, но вы не можете сравнивать не попробовав. Нельзя рассуждать о достоинствах езды на автомобиле, если до этого вы ездили только на велосипеде.
Ну да, тут надо крутить педали, а там нажимать на них, какая разница, не вижу особых преимуществ…
Попользуйтесь хотя бы месяц, и вы сами все поймете.
Ну да, тут надо крутить педали, а там нажимать на них, какая разница, не вижу особых преимуществ…
Попользуйтесь хотя бы месяц, и вы сами все поймете.
Я ведь сравниваю и рассуждаю на основе изложенного материала и опыта использования subversion. Да, переключение между ветвями и merge не такие гладкие, как хотелось бы, если в git что-то сделано гораздо лучше, хотелось бы знать, как и что именно.
Зачем нужна статья, которая не раскрывает преимуществ?
Зачем нужна статья, которая не раскрывает преимуществ?
Эта статья не сравнивает git с svn, а рассказывает об опыте применения git во флэш-разработке.
Если коротко:
1) Скорость. Гит не завязан на сеть и поэтому задержки при выполнении локальных операций практически не ощущаются. Опять же пока не попользуешься не узнаешь, как это было долго при использовании svn.
2) Ну про ветки уже все сказали. В SVN они есть, но большие проблемы при их создании, поддержке а главное слиянии. Еще одно большое отличие — в SVN ветки должны быть глобальными, т.е. существовать в центр. репозитории, а в Git можно иметь кучу локальных о которых никто не знает.
3) Возможность отложить изменения (stash). Очень часто бывает что ты в середине чего-то и не можешь коммитить прямо сейчас, т.к. сломаешь центр. репозиторий (в случае svn), а нужно очень срочно сделать багфикс на новых изменениях других разработчиков. Делаешь git stash и твоя раб. копия снова чиста. Можно обновиться, быстро исправить, закоммитить и накатить обратно свои изменения для продолжения прерванной работы.
4) Есть такая вещь как amending commit — можно исправить предыдущий коммит, добавить в него файлы, изменить сообщение в коммите, как если бы его вообще не было.
И таких вещей еще очень много, я описал только то, что первое пришло на ум.
Из минусов:
1) высокий входной порог
2) сдвиг парадигмы SVN (тут нужно думать по-другому, посмотрите hginit.com/00.html, там про Mercurial, но мысль в целом похожа),
3) много различных команд, хотя для начала нужно всего 3-4
4) мало GUI средств, основная работа идет в консоли, многих это пугает
Если коротко:
1) Скорость. Гит не завязан на сеть и поэтому задержки при выполнении локальных операций практически не ощущаются. Опять же пока не попользуешься не узнаешь, как это было долго при использовании svn.
2) Ну про ветки уже все сказали. В SVN они есть, но большие проблемы при их создании, поддержке а главное слиянии. Еще одно большое отличие — в SVN ветки должны быть глобальными, т.е. существовать в центр. репозитории, а в Git можно иметь кучу локальных о которых никто не знает.
3) Возможность отложить изменения (stash). Очень часто бывает что ты в середине чего-то и не можешь коммитить прямо сейчас, т.к. сломаешь центр. репозиторий (в случае svn), а нужно очень срочно сделать багфикс на новых изменениях других разработчиков. Делаешь git stash и твоя раб. копия снова чиста. Можно обновиться, быстро исправить, закоммитить и накатить обратно свои изменения для продолжения прерванной работы.
4) Есть такая вещь как amending commit — можно исправить предыдущий коммит, добавить в него файлы, изменить сообщение в коммите, как если бы его вообще не было.
И таких вещей еще очень много, я описал только то, что первое пришло на ум.
Из минусов:
1) высокий входной порог
2) сдвиг парадигмы SVN (тут нужно думать по-другому, посмотрите hginit.com/00.html, там про Mercurial, но мысль в целом похожа),
3) много различных команд, хотя для начала нужно всего 3-4
4) мало GUI средств, основная работа идет в консоли, многих это пугает
Если статья не сравнивает, тогда аргументация «Почему git» в терминах «основные плюсы» наверное не очень правильна. Плюсы — они же относительные.
Да вот и автор пишет сам: «Отличается от SVN отсутствием необходимости в центральном репозитории (который все же хорошо было бы держать)». Т.е. как бы плюс, но не особо и нужный, ибо все равно центральный репозиторий нужен.
Теперь по пунктам
1. Как же на завязан, если сливать в центральный репозиторий все равно придется.
2. Вот это-то и не раскрыто совершенно на примерах. Типа вот в svn такая-то операция делается вот так, а в git — по другому, видите, гораздо лучше, особенно слияние. Пока не вижу. Про кучу локальных веток я понял.
3. Что мешает переключиться на другую ветку-то?
4. Это не могу оценить, ни разу не требовалось
Все равно получается, что текста вроде как много, но «почему git» предлагается узнать на собственном опыте.
Да вот и автор пишет сам: «Отличается от SVN отсутствием необходимости в центральном репозитории (который все же хорошо было бы держать)». Т.е. как бы плюс, но не особо и нужный, ибо все равно центральный репозиторий нужен.
Теперь по пунктам
1. Как же на завязан, если сливать в центральный репозиторий все равно придется.
2. Вот это-то и не раскрыто совершенно на примерах. Типа вот в svn такая-то операция делается вот так, а в git — по другому, видите, гораздо лучше, особенно слияние. Пока не вижу. Про кучу локальных веток я понял.
3. Что мешает переключиться на другую ветку-то?
4. Это не могу оценить, ни разу не требовалось
Все равно получается, что текста вроде как много, но «почему git» предлагается узнать на собственном опыте.
Еще, для правильного использования веток есть отличный набор высокуровнивых расширений — git flow. Описание есть в статье Why aren't you using got flow, а сам проект живет на github nvie/gitflow.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование git во Flash разработке