Comments 97
Покажите админам gitosis, он им понравится.
0
В отличие от других систем контроля версий, git хранит все свои данные в одном каталоге, а не плодит повсюду папки .svn.
Кроме SVN никто и не плодит папки .svn. Лучше прямо скажите, что кроме GIT и SVN вы ничего не пробовали. Например Mercurial (Hg) тоже держит все в одной папке.
+5
Все-таки коммитить файлы проекта — не лучшая идея. Нельзя всех заставлять использовать одну IDE — как бы ни были хороши Aptana, прочие Eclipse-производные, и так далее — они не идеальны для всех.
Так же нехорошо держать под контролем версий настройки копий проектов — такие вещи должны генерироваться полуавтоматически и игнорироваться системой контроля версий — иначе это кончится десятком почти одинаковых файлов с именами вида «k12th.settings.py». Почему я должен в диффах видеть, как кто-то у себя переименовал папку с проектом?
Насчет бинарников — их не надо выключать из проекта, а надо просто указать, что данные файлы — бинарные (то есть, что их не надо пытаться диффать и мерджить). PSD-файлы бывает полезно версионировать — особенно в случаях типа «а вот три месяца назад у нас была кнопка с иконкой для того-то, давайте ее вернем».
Если админы не понимают, чем git лучше svn — это плохие админы:) Хорошие админы приложат все усилия, чтобы разрулить проблемы прав.
Так же нехорошо держать под контролем версий настройки копий проектов — такие вещи должны генерироваться полуавтоматически и игнорироваться системой контроля версий — иначе это кончится десятком почти одинаковых файлов с именами вида «k12th.settings.py». Почему я должен в диффах видеть, как кто-то у себя переименовал папку с проектом?
Насчет бинарников — их не надо выключать из проекта, а надо просто указать, что данные файлы — бинарные (то есть, что их не надо пытаться диффать и мерджить). PSD-файлы бывает полезно версионировать — особенно в случаях типа «а вот три месяца назад у нас была кнопка с иконкой для того-то, давайте ее вернем».
Если админы не понимают, чем git лучше svn — это плохие админы:) Хорошие админы приложат все усилия, чтобы разрулить проблемы прав.
+3
ну тут как договоритесь
например, у нас все работают на Flash Builder, файлы проекта одни на всех и не часто меняются
такая вот утопия
например, у нас все работают на Flash Builder, файлы проекта одни на всех и не часто меняются
такая вот утопия
0
Это решается соглашениями в команде — за этим следит team lead. Кроме прочего, нужно поддерживать постоянную интеграцию (CI) и автоматическую сборку (вот финальная сборка и тестовые/продакшн-настройки могут быть в мастер-ветке, специфичные настройки разработчики могут хранить в локальных ветках).
Насчет разных IDE и файлов проектов — есть такая тема, но тут ничего не поделаешь — как я уже сказал, в мастер-ветке можно хранить файл уже интегрированного рабочего проекта, когда все работает, тесты выполняются и не предполагается, что кто-то сделает что-то, что сломает содержимое мастер-ветки (ну, и CI в помощь — этот метод предполагает, что если кто-то что-то ломает своим коммитом — должен это исправить).
Насчет разных IDE и файлов проектов — есть такая тема, но тут ничего не поделаешь — как я уже сказал, в мастер-ветке можно хранить файл уже интегрированного рабочего проекта, когда все работает, тесты выполняются и не предполагается, что кто-то сделает что-то, что сломает содержимое мастер-ветки (ну, и CI в помощь — этот метод предполагает, что если кто-то что-то ломает своим коммитом — должен это исправить).
0
Простите, не очень понял, как связаны CI и файл проекта от IDE? Если сборка в CI осуществляется каким-нибудь, например, Ant'ом — то ему нужен build.xml, а не .nbproject от моей NetBeans.
0
Я неправильно выразился. В общем, нужно сделать так, чтобы поддерживался файл проекта (.csproj, напрмер), актуальный для текущей рабочей версии проекта (или, точнее, для части проекта — ведь не весь проект может создаваться одним средством). Я имел в виду под CI всю концепцию, методику, а не только автоматический билд решения.
0
Ну, если среда/платформа подразумевает, что файл проекта и файл билда — одно и то же (как в случае с .Net, если я правильно понял), то таки да, вы правы.
Я просто хочу сказать, что в общем случае файл сборки и файл проекта — не одно и то же, и что тащить вспомогательные файлы в проект не очень хорошо:)
Я просто хочу сказать, что в общем случае файл сборки и файл проекта — не одно и то же, и что тащить вспомогательные файлы в проект не очень хорошо:)
0
Нет, нет, в .NET файл проекта и файл билд инструкции для NAnt — это разные вещи. Просто одно дело билд, а другое дело — исходники проекта. Думаю, с исходниками всяко надо иметь вспомогательные файлы, ведь надо запускать проект в его актуальном состоянии сразу после checkout, например, из HEAD-ревизии. Или, по вашему, нет? :)
0
До этого топика очень скептично относился к Git.
Интересует однако вот какой момент:
В SVN для меня одним из больших плюсов является наглядность нумерации ревизий, то есть имея на руках r196 а в транке r205, я точно знаю что я пропустил достаточно неплохой апдейт.
В Git же ревизия нумеруется исходя из SHA-1 хэша коммита (насколько я понял из данного документа, если не прав — поправьте пожалуйста).
Можно ли как-нибудь, используя Git, использовать старую нумерацию, пускай даже извращенными методами?
Спасибо за статью, начну браться за Git =)
Интересует однако вот какой момент:
В SVN для меня одним из больших плюсов является наглядность нумерации ревизий, то есть имея на руках r196 а в транке r205, я точно знаю что я пропустил достаточно неплохой апдейт.
В Git же ревизия нумеруется исходя из SHA-1 хэша коммита (насколько я понял из данного документа, если не прав — поправьте пожалуйста).
Можно ли как-нибудь, используя Git, использовать старую нумерацию, пускай даже извращенными методами?
Спасибо за статью, начну браться за Git =)
0
У меркуриала смешанная нумерация (линейная и хеш), может стоит попробовать его, если это так критично?
0
Можно ли как-нибудь, используя Git, использовать старую нумерацию, пускай даже извращенными методами?
У вас желания неправильные. Цель не в том, что номерки расходятся, а в том что понять синхронизирован ли локальный репозиторий с удаленным. Мы уже почти месяц с большим проектом на mercurial, и проблемы такой не возникло еще.
0
В гите для подобного есть комманда «git describe» которая генерирует user-friendly версию. Примерно такую
v2.1.5-86-g655efd3
Эта комманда говорит что текущая ветка основана на таге v2.1.5, отстоит от него на 86 коммитов и затем hash последнего коммита.
v2.1.5-86-g655efd3
Эта комманда говорит что текущая ветка основана на таге v2.1.5, отстоит от него на 86 коммитов и затем hash последнего коммита.
+6
А не могли бы вы поподробнее рассказать про слияние веток? по какому алгоритму оно происходит? Вот есть файл в мастере
Программист 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 добавил изменение:
0
а как в 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() {};
Что будет в итоге?
0
конфликт будет :-)
+1
В итоге будет merge conflict как и в любой другой VCS без встроенного искусственного интеллекта.
+1
Ну я больше по меркуриалу, там будет конфликт. В нем вообще нет родной мержилки для файлов, в мерж это больше операция объединения голов в ветках чем слива изменений в одном файле.
+1
а что такое «объединения голов в ветках»? на пальцах )) перезаписать из одной ветки файлами из другой?
0
какой тогда тайный смысл в GIT кроме локального удобства разработчика? ну есть ветка, мы мерджим её с другой. Этот мердж происходит без проблем только в теоретических случаях. На практике мы апдейтимся до текущей версии master потом как-то руками пытаемся впихнуть наши измеменения.
0
ИМХО, если два человека меняют в одном месте что-то это проблема не системы контроля версий а организации процесса, как уже заметили, тут никакая система контроля версий не поможет.
Мерж в распределенных системах лучше (я говорю за Меркуриал) в том, сохраняется история кто чего с чем мержил, в отличии от SVN.
Вы пробовали вести ветки в SVN? А потом вливать изменения в транк? Там проще было застелиться, иногда конфликты были такие тупые…
Мерж в распределенных системах лучше (я говорю за Меркуриал) в том, сохраняется история кто чего с чем мержил, в отличии от SVN.
Вы пробовали вести ветки в SVN? А потом вливать изменения в транк? Там проще было застелиться, иногда конфликты были такие тупые…
+1
знаю по перфорсу — вот это действительно, смержить ветки за пару недель — задача на полдня. где в гите был бы фастфорвард
0
Согласен полностью насчет проблем с мерджем, но что тут скажешь — вопрос не самих репозиториев, а способов работы с ними и (важно!) того как построено само решение — ноги растут именно оттуда. С использованием SOLID нечасто приходится проводить «сложные мерджи» одних и тех же файлов — все должно быть развязано и независимо.
0
Статья хорошая, годная. Вот хотелось бы побольше узнать о том, почему вы перешли с корп СВН на самопальный ГИТ и как вы пропустили Меркуриал?
also
when i see «chmod -R 777» i shit bricks.
also
when i see «chmod -R 777» i shit bricks.
+2
Я полагаю, что люди повелись на более-менее вменяемый GUI клиент.
Мы вот перешли на меркуриал, меня смутили набор команд в гите в кучей труднозапоминаемых ключей, когда в меркуриале все как-то проще, ну и уже упомянутая доточенная напильником поддержка винды.
Но я наслушался матюков в свою сторону :-) после перехода со SmartSVN.
TortoroiseHg весьма странный SmartHg еще не выпустили (и не факт что выпустят). Не все программеры привыкли в коммандной строке работать. А из IDE много не сделаешь…
Мы вот перешли на меркуриал, меня смутили набор команд в гите в кучей труднозапоминаемых ключей, когда в меркуриале все как-то проще, ну и уже упомянутая доточенная напильником поддержка винды.
Но я наслушался матюков в свою сторону :-) после перехода со SmartSVN.
TortoroiseHg весьма странный SmartHg еще не выпустили (и не факт что выпустят). Не все программеры привыкли в коммандной строке работать. А из IDE много не сделаешь…
0
0
Ну мы же не холивары тут разводим. Здесь больше концептуальное обсуждение чем распределенная система контроля версий лучше/хуже чем цетрализированная.
Если есть время, то послушайте первые три UTP подкаста Уптутуна: utp.umputun.com
В кратце: ветки вести намного проще в гите/меркуриале. Что выбрать — личное дело каждой группы разработчиков.
Если есть время, то послушайте первые три UTP подкаста Уптутуна: utp.umputun.com
В кратце: ветки вести намного проще в гите/меркуриале. Что выбрать — личное дело каждой группы разработчиков.
0
А как вы решаете (или не решаете) такую проблему?
Судя по описанию у вас фичи разработчиков находятся в локальных ветках. Допустим, что в релиз ХХ вы решили поставить фичи 1,2,3 но в последний момент поняли что фича 2 там не надо и нужно ставить только 1 и 3.
После того как девелоперы закоммитили в интеграционную ветку свои изменения их пересобрать по частям как-то сложновато. Мы не придумали как это сделать без лишнего головняка.
Судя по описанию у вас фичи разработчиков находятся в локальных ветках. Допустим, что в релиз ХХ вы решили поставить фичи 1,2,3 но в последний момент поняли что фича 2 там не надо и нужно ставить только 1 и 3.
После того как девелоперы закоммитили в интеграционную ветку свои изменения их пересобрать по частям как-то сложновато. Мы не придумали как это сделать без лишнего головняка.
+1
и мы
0
можно замарочится и вести ветку на каждую фичу. согласен, что это в некоторой степени гемор, но зато для сборки клиента можно делать выборки из бранчей.
0
Это не геморой, а правильное использование веток :))
+2
ну если фичи мелкие то много времени уходит на switch веток. плюс параллельные фиксы багов в отдельную ветку. в общем привыкать довольно сложно.
0
Если отталкиваться от SVN, то да, они (бранчи) хоть в буке (SVNBook) описываются, но от них как правило отказываются. В git всё гораздо прозрачней. В любом случае при правильном подходе 1 фича = 1 разработчик(группа) на единый момент времени, а не 10 фич = 1 разработчик.
+1
не бывает 1 фича = 1 разработчик. обычно 10 разработчиков = 100 фич.
к тому же причём тут свн? мы же про гит говорим.
к тому же причём тут свн? мы же про гит говорим.
0
Но фичи делаются по очереди)). Просто я не вижу больших проблем при мёрдже в гите и почему там уходит много времени на это.
+1
Согласен, rebase, fast forward merge, и никаких траблов :)
Разумеется, если все это правильно использовать.
Разумеется, если все это правильно использовать.
0
вы не правы. вот делаете Вы фичу. к вам подбегает взъерошенный геймдиз и начинает в панике рассказывает о критическом баге, который прямо сейчас нужно залить. а за спиной у него стоит серверник, который хочет, что вы сделали ему клиент, с его фичёй. но вы то делаете совершенно другую фичу.
но я тоже люблю верить в утопию )
но я тоже люблю верить в утопию )
0
Баги в транке правятся. Серверник отправляется к менеджерам проекта, т.е. в стек :))
0
В контексте Git, используйте stash, который потом сольете с исправленной версией (если это тот же проект). Создаете новую ветку, пишете новую фичу, сливаете в соответствующую изначальную (допустим, master) ветку, достаете данные из stash и продолжаете работать.
+1
спасибо. я умею пользоваться гитом. и если вы считаете постоянное выполнение данных операций верхо удобства, то дальнейшая беседа бессмысленна. я же чётка сформулировал, «что это в некоторой степени гемор».
0
Ну вот и славно, что умеете. Значит ваш вопрос был просто не в том контексте, о чем я подумал.
В общем, целом и глобальном — идеальной утопии (как же вы любите это слово :) не бывает — разумеется, нет идеальных средств, но нет и нерешаемых ситуаций. Мы, видимо, просто о разном говорили.
P.S. И нет, эти команды — не верх удобства. Нужно правильно организовывать работу (и в целом, и с SCM — в частности).
В общем, целом и глобальном — идеальной утопии (как же вы любите это слово :) не бывает — разумеется, нет идеальных средств, но нет и нерешаемых ситуаций. Мы, видимо, просто о разном говорили.
P.S. И нет, эти команды — не верх удобства. Нужно правильно организовывать работу (и в целом, и с SCM — в частности).
0
UFO just landed and posted this here
А Вас не учили правилу «сделал таск — закоммитил»?)) На одной работе мы координально решали такие вещи (с свн). На каждую задачу поднимали вообще новую копию проекта и в ней делали всё, потом коммитили и убивали локально :)
+2
UFO just landed and posted this here
Буду категоричен — у вас неправильно организована работа.
«коммитить он может что хочет и когда хочет» (а тем более — комплексную фичу!)
«Никаких четких правил на этот счет.»
Этого никак и никогда нельзя допускать. Это то, что однозначно (лишь вопрос времени) ведет к краху проекта. В такие моменты (завтра закроют приложение) — как нельзя больше нужна организация. Иначе, вы сами того не осознавая, потратите куда больше времени на «ручные правки», «костыли» и «временные решения».
«коммитить он может что хочет и когда хочет» (а тем более — комплексную фичу!)
«Никаких четких правил на этот счет.»
Этого никак и никогда нельзя допускать. Это то, что однозначно (лишь вопрос времени) ведет к краху проекта. В такие моменты (завтра закроют приложение) — как нельзя больше нужна организация. Иначе, вы сами того не осознавая, потратите куда больше времени на «ручные правки», «костыли» и «временные решения».
0
UFO just landed and posted this here
Бррр… Давайте по полкам.
Фича — новый функционал
Багфикс — исправление ошибок.
1 фича = 1 бранч
1 багфикс = комит в транк
Ситуация. Я работаю над новой фичей (придумайте сами какой), тут ко мне подбегает менеджер проекта и говорит, что есть баг, который нужно срочно пофиксить.
Мои действия. Я поднимаю проект заново (в отдельной папке), правлю баг и заливаю в репозиторий (если свн), или просто свитч на другую ветку (если тот же гит).
Укажите где я тут не прав.
Фича — новый функционал
Багфикс — исправление ошибок.
1 фича = 1 бранч
1 багфикс = комит в транк
Ситуация. Я работаю над новой фичей (придумайте сами какой), тут ко мне подбегает менеджер проекта и говорит, что есть баг, который нужно срочно пофиксить.
Мои действия. Я поднимаю проект заново (в отдельной папке), правлю баг и заливаю в репозиторий (если свн), или просто свитч на другую ветку (если тот же гит).
Укажите где я тут не прав.
+1
UFO just landed and posted this here
Игра понятиев)) Любое правило исходит из этого.
0
девочки, не ссорьтесь.
всякого рода паттерны как раз и нужны для того, чтобы избежать проблем. если у вас есть паттерн веток и комитов, то если все будут ему следовать и не делать грязных хаков, то все будет хорошо.
всякого рода паттерны как раз и нужны для того, чтобы избежать проблем. если у вас есть паттерн веток и комитов, то если все будут ему следовать и не делать грязных хаков, то все будет хорошо.
+1
Ну, как можно про что-то «забыть» или «не заметить»? Это уже вопрос самой организации рабочего процесса. При желании или при безответственности можно в чем угодно навести хаос.
P.S. Версионность, в данном случае — единственный выход избавления от полного хаоса.
P.S. Версионность, в данном случае — единственный выход избавления от полного хаоса.
0
UFO just landed and posted this here
«Я исхожу из постулата, то разработчик неизбежно ошибется и чем меньше оставить ему мест для ошибок тем эффективней будет разработка в целом.»
Именно так. Поэтому я и ответил на ваш комментарий выше, что нельзя пускать на что-либо на самотек и на усмотрение торопящегося девелопера (разберется, мол).
Именно так. Поэтому я и ответил на ваш комментарий выше, что нельзя пускать на что-либо на самотек и на усмотрение торопящегося девелопера (разберется, мол).
0
Согласен с предыдущим комментатором — это правильный подход. А затем, при необходимости коммита в основную ветку — нужно определить приоритеты и действовать последовательно. Ну а то, что какая-то фича, вдруг, просто «не нужна» — это скорее частный случай. Большинство разрабатываемых фич, все-таки нужно.
0
А в чем сложность пересобрать и как это зависит от репозитория? Есть такая техника как постоянная интеграция (CI), и ее нужно придерживаться. Иначе в любом случае «пересобирать сложновато» будет.
0
Ну в другой систме контроля версий это тоже не работало гладко.
Вопрос. Как исключить фичу Х из релиза? У нас релиз раз в неделю и не всегда все уходит на продакшн. Скажем 15 фич из девелоперской ветки ставятся, а 3 нет, как их безболезненно вырезать?
Вопрос. Как исключить фичу Х из релиза? У нас релиз раз в неделю и не всегда все уходит на продакшн. Скажем 15 фич из девелоперской ветки ставятся, а 3 нет, как их безболезненно вырезать?
0
Git — прекрасная VC-система. И она годится для разработки на чем угодно — например, отлично работает с C#/Visual Studio, используя Git Source Control Provider и GitExtensions.
Минус один — не так очевидно, с чего начать работу с Git. Зато, начав, уже не хочется переходить обратно на SVN/Mercurial/Perforce. Советую всем, кто не уверен, попробовать.
И еще — я не фанат командной строки, поэтому лично мне удобнее использовать GUI для всех основных сценариев.
Минус один — не так очевидно, с чего начать работу с Git. Зато, начав, уже не хочется переходить обратно на SVN/Mercurial/Perforce. Советую всем, кто не уверен, попробовать.
И еще — я не фанат командной строки, поэтому лично мне удобнее использовать GUI для всех основных сценариев.
0
Думаю, стоит упомянуть, что у git есть проблемы с именами файлов в UTF-8
+1
Я позволю себе сравнить с 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 и переключение веток.
0
Извините, но вы не можете сравнивать не попробовав. Нельзя рассуждать о достоинствах езды на автомобиле, если до этого вы ездили только на велосипеде.
Ну да, тут надо крутить педали, а там нажимать на них, какая разница, не вижу особых преимуществ…
Попользуйтесь хотя бы месяц, и вы сами все поймете.
Ну да, тут надо крутить педали, а там нажимать на них, какая разница, не вижу особых преимуществ…
Попользуйтесь хотя бы месяц, и вы сами все поймете.
+2
Я ведь сравниваю и рассуждаю на основе изложенного материала и опыта использования subversion. Да, переключение между ветвями и merge не такие гладкие, как хотелось бы, если в git что-то сделано гораздо лучше, хотелось бы знать, как и что именно.
Зачем нужна статья, которая не раскрывает преимуществ?
Зачем нужна статья, которая не раскрывает преимуществ?
+1
Эта статья не сравнивает 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 средств, основная работа идет в консоли, многих это пугает
0
Если статья не сравнивает, тогда аргументация «Почему git» в терминах «основные плюсы» наверное не очень правильна. Плюсы — они же относительные.
Да вот и автор пишет сам: «Отличается от SVN отсутствием необходимости в центральном репозитории (который все же хорошо было бы держать)». Т.е. как бы плюс, но не особо и нужный, ибо все равно центральный репозиторий нужен.
Теперь по пунктам
1. Как же на завязан, если сливать в центральный репозиторий все равно придется.
2. Вот это-то и не раскрыто совершенно на примерах. Типа вот в svn такая-то операция делается вот так, а в git — по другому, видите, гораздо лучше, особенно слияние. Пока не вижу. Про кучу локальных веток я понял.
3. Что мешает переключиться на другую ветку-то?
4. Это не могу оценить, ни разу не требовалось
Все равно получается, что текста вроде как много, но «почему git» предлагается узнать на собственном опыте.
Да вот и автор пишет сам: «Отличается от SVN отсутствием необходимости в центральном репозитории (который все же хорошо было бы держать)». Т.е. как бы плюс, но не особо и нужный, ибо все равно центральный репозиторий нужен.
Теперь по пунктам
1. Как же на завязан, если сливать в центральный репозиторий все равно придется.
2. Вот это-то и не раскрыто совершенно на примерах. Типа вот в svn такая-то операция делается вот так, а в git — по другому, видите, гораздо лучше, особенно слияние. Пока не вижу. Про кучу локальных веток я понял.
3. Что мешает переключиться на другую ветку-то?
4. Это не могу оценить, ни разу не требовалось
Все равно получается, что текста вроде как много, но «почему git» предлагается узнать на собственном опыте.
+1
Еще, для правильного использования веток есть отличный набор высокуровнивых расширений — git flow. Описание есть в статье Why aren't you using got flow, а сам проект живет на github nvie/gitflow.
0
Sign up to leave a comment.
Использование git во Flash разработке