Использование git во Flash разработке

    Я давно уже начал писать эту статью, но меня опередили (8.
    Основная задумка была объяснить братьям флэшерам как работать с git. В статье я попытался описать свой личный опыт, а не просто перечислить очевидные плюсы git. Поэтому она будет полезна всем.

    В первую очередь буду рад дополнениям и исправлениям. И конечно же вопросам.

    Что такое git


    git — это распределенная система контроля версий. Отличается от SVN отсутствием необходимости в центральном репозитории (который все же хорошо было бы держать) и легкостью работы с ветками (branch). Изначально я решил попробовать его в работе прочитав эту статью, что всем рекомендую.

    У себя в компании я смог перевести клиентскую разработку на git и до сих пор не пожалел ни минуты. Время от времени я натыкаюсь на споры по поводу какая система контроля версий лучше, часто приходится объяснять чем все-таки мне нравится git.


    Почему git


    Все мы понимаем, что использовать систему контроля версий жизненно необходимо. git в повседневном использовании показал себя очень хорошо и позволил решить ряд проблем. Приведу основные плюсы и «фишки».
    1. Распределенность
      Создать репозиторий в локальной папке можно просто написав
    2. Наличие стабильного клиента
      Процесс разработки без ветвлений выглядит примерно так: версия… разработка… версия… разработка…
      Видно, что в каждый момент времени наличие стабильной версии, на которой можно поправить баги и зарелизить, не гарантировано. А точнее, получается так, что исправить некий выловленный баг можно только закончив разработку текущей версии. Простые ветки в git позволяют в любое время достать версию любого предыдущего релиза и работать с ней не мешая идущей разработке. Исправить баги в отдельной ветке, смержить в предыдущий релиз и в текущую разработку.
    3. Удобство использования
      git хранит все свои данные в одном каталоге, а не плодит повсюду папки .svn. Переключить проект с одной ветки на другую можно всего одной командой или парой кликов в клиенте. При этом содержимое папки проекта заменяется новым, которое соответствует выбранной ветке. Для разных веток не нужно создавать новые папки или проекты. В большинстве случаев, Flash Builder сам обновит все классы и перекомпилит зависимости.
    4. Нет необходимости в постоянном конекте к центральному хранилищу
      Как я уже сказал, все комиты сохраняются локально и становятся частью общего репозитория только тогда, когда непосредственно пушатся в него. Это сложно вообразить, но порой получается так, что нет доступа в интернет, а работать нужно. Или вы как обычно забыли настроить VPN к рабочему репозиторию. Радует скорость комитов и ощущение полного контроля над локальной копией.
    5. Удобные частичные комиты
      Непосредственно перед комитом помечаются файлы, которые в него войдут с помощью git add. При этом существует возможность в отдельный комит внести часть изменений в файле, а не файл целиком.
    6. Возможность припрятать изменения.
      В git есть интересная возможность — припрятать (stash) незакомиченные файлы и потом достать их снова. Иногда бывает полезно таким образом переносить или временно откатывать изменения, например, я часто забываю переключать ветки.
    7. Наличие графических клиентов.
      Для git не такой уж и большой выбор графических клиентов. Мне больше всего понравился GUI клиент SmartGit. Он кроссплатформенный и для некоммерческого использования доступен бесплатно. Обладает всеми нужными функцими, но все же иногда бывает нужно залезть в Terminal и выполнить пару команд git. Хорошо бы в них примерно разбираться. Для Винды есть TortoiseGit, на Маке я пользовался некоторое время GitX, но тогда он был уж сильно хуже, чем SmartGit. Для Eclipse (то есть для Flash Builder) есть плагин EGit, который давно мне чем-то не понравился. Надо будет вернуться к нему еще раз, тем более он только что обновился. Возможно, это не фишка клиента, а часть дистрибутива git, но тем не менее, хочется упомянуть еще классное отображение веток. В сложном проекте выглядит как карта метро Нью Йорка. Люблю я такие абстрактные картиночки.

    TODO или что еще нужно проверить


    Я так и не удосужился поставить git-svn и соединить git репозитории с их svn копиями, потому что у нас в компании официально используют svn, но мы не могли больше терпеть. Надеюсь, все перейдут в итоге на git и это не понадобится.

    Пока же я предлагал GitHub как интересный вариант хранения проектов с разграничением доступа. Но, понимаете ли, корпоративная секурность итд (хотя код воруют направо и налево и без этого). Сам я использую его для своих личных проектов. Удобненько.

    Установка и настройка


    Git. Mac / Linux


    Для начала нужно установить сам git. Линуксоиды без сомнения разберутся и сами, а скорее всего он у них уже установлен. Маководы могут скачать дистрибутив с официального сайта или установить через MacPorts. Как ставить MacPorts тоже разобраться труда не составляет.

    В MacPorts открываем Terminal и вводим.
    sudo port

    Скорее всего не через админский акаунт ничего установить не разрешит, так что вызываем через sudo и вводим пароль. Дальше смотрим какие есть репозитории начинающиеся с git.
    list git*

    На экране появится что-то типа
    git-core                       @1.7.2.1        devel/git-core
    GitX                           @0.7.1          devel/GitX

    GitX — это GUI клиент, о котором я уже писал. Нас же интересует git-core. Чтобы установить его, нужно написать
    install git-core

    Проверить правильность установки можно набрав в консоли git --version.

    Для доступа к удаленным репозиториям Вам понадобится SSH ключ. Сгенерить его на Mac не составляет никаких проблем.

    Git. Windows

    Для Windows существует порт msysgit. Качаем последнюю версию и устанавливаем.
    Git изначально какбы чужероден для Windows. С этим могут быть связаны некоторые проблемы. Например, мы какое-то время не могли заставить его работать с удаленными репозиториями. Ругался на SSH ключ. Спасибо GitHub'у за решение этой проблемы. Так вот, не пытайтесь сгенерить ключ с помощью Putty. Чтобы сгенерить правильный ключ нужно:
    1. Запустить Git Bash console из Start -> Programs -> Git
    2. Выполнить ssh-keygen -t rsa -C "your@email.com", чтобы сгенерить ключ


    GUI клиент

    Теперь ставим мой любимый SmartGit. Очень приятно, что он кроссплатформенный.

    Во время установки SmartGit, если не найдет файл .gitconfig, спросит имя и e-mail, которые будут использоваться в информации о комитах.

    Переносы строк

    При работе с git репозиторием с разных операционных систем, рано или поздно (лучше рано) сталкиваешься с проблемой переносов строк. Сообщество так и не пришло к единому мнению, но GitHub рекомендует следующие настройки:
    1. Создавать репозиторий лучше не с Windows машины
    2. На Linux и Mac установить параметр core.autocrlf в значение input
    3. На Windows установить параметр core.autocrlf в значение true

    Это делается либо командой git config --global core.autocrlf true либо редактированием .gitconfig. Туда нужно добавить
    [core]
    autocrlf = true

    При этих настройках пользователи Mac будут работать с LF переносами строк и комитить LF в репозиторий, а пользователи Windows будут работать с привычными CRLF, но комитить LF.

    Если сразу же не настроить переносы строк, то при каждом пуше большинство файлов будут помечаться как измененные, хотя никаких изменений в них нет. При этом все равно время от времени появляются такие файлы, им вручную приходится делать revert. Подскажите, если кто знает что с этим можно сделать?

    Перевод существующего проекта


    Данный способ предполагает полную потерю истории SVN. Начало, так сказать, с чистого листа.

    Сделайте svn export проекта, чтобы избавиться от .svn папок. Или в корне проекта выполните команду find ./ -name ".svn" | xargs rm -Rf

    Если у вас проект состоит из нескольких отдельных Flash Builder подпроектов, имеет смысл сразу же их перенести в одну папку и создать один git репозиторий в ней, а не отдельный на каждый подпроект. В будущем будет проще отмечать версии проекта в целом, вместо того, чтобы по каждому подпроекту искать нужное его состояние где-то в прошлом. Если вы решили перенести папку с проектом, лучше его удалить из проектов Flash Builder (разумеется, не удаляя при этом содержимое каталога).

    В каталоге с будущим git репозиторием рекомендую сразу создать файл .gitignore со следующим содержимым:
    bin
    bin-debug
    bin-release

    Это скажет git не включать в репозиторий скомпилированные бинарники проекта.

    Далее запускаем SmartGit, выбираем Open an existing or create a new local Git working tree и указываем папку с проектом. SmartGit создаст в ней новый репозиторий.

    Сразу же нужно найти в списке файл .gitignore, выделить его, нажать кнопку Stage и Commit. Первый Commit Message пусть будет что-то вроде «initial commit». Теперь, если зарефрешить текущее состояние каталога, исчезнут все файлы упомянутые в .gitignore. Они вам не нужны. Выделяем все остальные файлы, Stage, Commit, в окне комита отметьте галочку Amend foregoing commit..., тем самым вместо нового комита вы добавите текущие изменение к последнему (возможно, вы увидите множество сообщений CRLF will be replaced by LF in… — это означает, что git следуя настройкам меняет концы строк файлов, которые добавляются в репозиторий, на правильный LF).

    Поздравляю, теперь у вас есть свой git репозиторий.

    Если вы вдруг создали репозиторий до того, как выставить правильные настройки переносов строк, то следуйте инструкции GitHub и выполните следующий скрипт:
    # Remove everything from the index
    $ git rm --cached -r .


    # Re-add all the deleted files to the index
    # You should get lots of messages like: «warning: CRLF will be replaced by LF in <file>.»
    $ git diff --cached --name-only -z | xargs -0 git add

    # Commit
    $ git commit -m «Fix CRLF»

    # If you're doing this on a Unix/Mac OSX clone then optionally remove
    # the working tree and re-check everything out with the correct line endings.
    $ git ls-files -z | xargs -0 rm
    $ git checkout .

    Если вы удаляли проект из Flash Builder, сейчас самое время добавить его заново (через File -> Import -> Flash Builder Project) и убедиться, что все работает. Возможно, придется сделать некоторые изменения, например в путях импорта и конфигах, если вы переносили проекты в одну папку. После сделанных изменений не забудьте их закомитить.

    Работа с проектом


    Если вы еще не прочитали эту статью, рекомендую сделать это сейчас, потому что описанный ниже процесс работы с проектом в git практически полностью взят оттуда. Во время написания этой статьи я все еще работаю на Mail.ru и пишу клиенты социальных игр на Флэше. Отсюда некоторая специфика.

    Раз уж мы используем git, будем на полную пользоваться его основной фишкой — ветками. Итак, все проекты у меня состоят из набора веток с разными функциями и строго определенным алгоритмом работы с ними.
    • master — основная ветка содержит только релизные версии, которые сейчас онлайн. Они помечены тэгами (tag) с датой заливки. От мало информативных номеров версий я отказался. Если вдруг что-то ломается на боевом сервере, мы без проблем переключаемся на master, делаем с него ветку, фиксим баг и мержим обратно (плюс еще в другие ветки, чтобы потом заного тот же баг не фиксить)
    • develop — основная девелоперская ветка. Отражает стабильное состояние разработки, которое когда-то в будущем уйдет в релиз и будет смержено в master.
    • dev-* — ветки для отдельных фич. Многие из них локальные и в главный репозиторий не попадают. В них ведется разработка конкретных новых фич игры. Это могут быть совсем небольшие изменения на один-два комита, а может быть огромный патч, который разрастается на месяц  и более.
    • fix-* — локальные ветки срочных фиксов. Обычно появляются от  master, реже от develop. Сразу мержатся в нужные места.
    • release — временная ветка для релиза, которая вольется в master и будет удалена. В нужный момент бранчится с develop, и в нее вносятся необходимые правки перед заливкой.

    Алгоритм работы следующий:
    • Практически для каждого изменения заводится своя девелоперская ветка, которые либо в итоге будут смержены в develop, либо удалены за ненадобностью.
    • Ветки более-менее больших изменений идут в центральный репозиторий, мелкие обычно остаются локально у разработчиков.
    • Слияние больших фичей я стараюсь контролировать, просматривая проделанные изменения. Очень удобно на данном этапе отсекать всякий говнокод.
    • Во время подготовки к релизу, создается ветка release, которая потом мержится в master. В ней делаются временные изменения, которые нигде больше не нужны, например «нам в этом релизе нужно спрятать эту кнопку, потому что функционал еще не готов». На этом этапе лучше больших багов не иметь, потому что тогда придется делать отдельную ветку с фиксами этих багов и постоянно переключаться между ней и release.
    • После заливки, release мержится в master и удаляется. Текущее состояние master помечается тэгом с датой заливки.
    • Разработка продолжается.

    Тем самым, у нас всегда есть исходник текущей онлайн версии, куда можно оперативно внести какие-то изменения. Каждый разработчик занят своим делом и не пачкает своими грязными экспериментами стерильный центральный репозиторий. При этом продолжает записываться история комитов, которую всегда можно при надобности поднять.

    Проблемы, с которыми я столкнулся


    Конечно, не все так идеально, как вы могли подумать. На пути к просвещению мне все же пришлось понаступать на грабли, о которых я напишу ниже. Возможно, эта информации кому-то пригодится.
    1. Сопротивление админов
      Я несколько раз пытался объяснить зачем нам еще одна система контроля версий, ведь вроде бы есть отличная SVN. Админы жаловались, что git сложно интегрировать в существующую систему раздачи прав и разграничения доступа к ресурсам в сети. Это дело так с мертвой точки и не сдвинулось, пришлось мне «центральный репозиторий держать у себя локально».
    2. Обучение коллег
      Коллег пришлось заставить перейти на новую систему контроля версий, понять чем оно отличается от привычного SVN и научиться пользоваться новым софтом. Ничего сложного на самом деле, но нужно быть готовым к последующим постоянным вопросам.
    3. Проблема переносов строк
      О проблеме и ее решении я уже писал выше, но так как это конкретно выносило мой мозг какое-то время, я не мог об этом не написать в разделе «проблемы». Очень важно пофиксить переносы строк в самом начале проекта, когда существует только одна ветка. Потом это обернется в солидную головную боль.
    4. Руки из ж…
      Что касается юниксоподобных систем и командной строки, тут у меня руки растут явно не из того места. Будучи какое-то время центральным репозиторием на Маке, мне постоянно пришлось сталкиваться со следующими проблемами, связанными с тем, что я с самого начала все правильно не настроил: залоченный файлы и владельцы файлов.Каким-то образом файлы git репозитория становились залоченными так, что никак, даже из самого-самого рута разлочиваться не хотели. Гугл подсказал скрипт, который рекурсивно разлочивает файлы в каталоге.После пуша ко мне от коллег разработчиков, некоторые файлы переходили под владение nobody, что приводило к полной неработоспособности репозитория. Приходилось каталогу каждый раз рекурсивно выставлять права, типа, sudo chmod -R 777 /users/valyard/Work/work/Panda/.git/

      В итоге я написал скрипт, который делал эти две вещи на всех проектах, и запускал его время от времени.
    5. Внимательнее смотрите что идет в репозиторий, а что нет
      Разумеется, скомпилированные бинарники и графические ассеты нужно сразу добавить в .gitignore. У нас в проекте есть ant скрипт для сборки барахла и он немного отличается на разных машинах. Возможно, его стоило тоже туда добавить, но я просто сделал два разных скрипта: для винды и для мака.
    6. Надоедливые файлы проекта
      Почему-то Flash Builder время от времени в метаданных проекта считает своим долгом перенести половину строк сверху вниз, чем он не делает ничего полезного, зато раздражает git при отображении изменений. Но, все же, не комитить файлы проекта я считаю плохой идеей.
    7. Проблема генерации SSH ключей на WIndows
    8. Нелюбовь флэшеров к консоли
      Как выяснилось, флэшеры не любят работать в консоли. А GUI клиенты предоставляют лишь малую часть функционала git. Порой приходится лезть в командную строку, чтобы выполнить какую-то операцию посложнее.

    Полезные советы


    Пара слов в конце.
    1. Убедитесь, что Вы понимаете отличия git от svn.
    2. Постарайтесь донести это до начальства.
    3. Найдите человека, который сможет грамотно настроить главный git репозиторий.
    4. Постарайтесь все же использовать один и тот же IDE в команде, тогда можно комитить файлы проекта.
    5. Разделите проект на несколько репозиториев.
    6. Делайте комиты и мержи чаще, все-таки даже такой классный инструмент как git не может автоматически смержить две ветки с двухмесячной историей комитов. Придется посидеть вручную потыкать кнопочки.
    7. Не повторяйте моих ошибок.
    8. Не слушайте тех, кто ругает git.

    Полезные ссылки



    Итог


    Но все же все минусы были перекрыты огромными плюсами. Были моменты, когда я готов был поцеловать себя в зад за то, что все-таки перевел проект на git, чего и Вам желаю (конечно, не поцеловать меня в зад, а перевести проект на git)!

    P.S. Вопросы.


    1. Как и кто у вас контролирует слияние с основной веткой (master) и есть ли механизм разграничения полномочий для выполнения подобных операций?
      Контролирует главный флэшер на проекте. В моих проектах это делаю я. На уровне git я не знаю есть ли какие-то разграничения по доступным операциям.
    Поделиться публикацией

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 97

      0
      Покажите админам gitosis, он им понравится.
        0
        совпадение это или нет, но в день публикации они как раз настроили центральный репозиторий именно на gitosis
        не знаю есть ли альтернативы (кроме разве что решение от github)
          +1
          gitolite
            +1
            у гитхаба есть кстати fi.github.com, но это надо уломать руководство.
              0
              а что он стоит? сайт умалчивает
                0
                думаю надо написать им и узнать.

                я мечтаю о том что наша команда перейдет на гит, неговоря уже о том чтобы думать о приобретении такого шикарного продукта.

                я пока тихонько использую git svn
              0
            +5
            В отличие от других систем контроля версий, git хранит все свои данные в одном каталоге, а не плодит повсюду папки .svn.

            Кроме SVN никто и не плодит папки .svn. Лучше прямо скажите, что кроме GIT и SVN вы ничего не пробовали. Например Mercurial (Hg) тоже держит все в одной папке.
              0
              поправил
                0
                Почему, CVS плодит, например.
                  +1
                  mercurial вообще прелесть, к тому же любимый питон…
                    +1
                    Они все хороши. Ну, кроме SourceSafe :)
                    Просто Git, например, создает реальное ощущение того, что больше ничего не нужно. И не зря — используя его и правда больше ничего не нужно.
                  +3
                  Все-таки коммитить файлы проекта — не лучшая идея. Нельзя всех заставлять использовать одну IDE — как бы ни были хороши Aptana, прочие Eclipse-производные, и так далее — они не идеальны для всех.

                  Так же нехорошо держать под контролем версий настройки копий проектов — такие вещи должны генерироваться полуавтоматически и игнорироваться системой контроля версий — иначе это кончится десятком почти одинаковых файлов с именами вида «k12th.settings.py». Почему я должен в диффах видеть, как кто-то у себя переименовал папку с проектом?

                  Насчет бинарников — их не надо выключать из проекта, а надо просто указать, что данные файлы — бинарные (то есть, что их не надо пытаться диффать и мерджить). PSD-файлы бывает полезно версионировать — особенно в случаях типа «а вот три месяца назад у нас была кнопка с иконкой для того-то, давайте ее вернем».

                  Если админы не понимают, чем git лучше svn — это плохие админы:) Хорошие админы приложат все усилия, чтобы разрулить проблемы прав.
                    0
                    ну тут как договоритесь
                    например, у нас все работают на Flash Builder, файлы проекта одни на всех и не часто меняются
                    такая вот утопия
                      0
                      В утопии можно, да:)
                      0
                      Это решается соглашениями в команде — за этим следит team lead. Кроме прочего, нужно поддерживать постоянную интеграцию (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 =)
                        0
                        У меркуриала смешанная нумерация (линейная и хеш), может стоит попробовать его, если это так критично?
                          +1
                          не поможет, номерки в разных репозиториях нельзя сравнивать.
                          0
                          Можно ли как-нибудь, используя Git, использовать старую нумерацию, пускай даже извращенными методами?

                          У вас желания неправильные. Цель не в том, что номерки расходятся, а в том что понять синхронизирован ли локальный репозиторий с удаленным. Мы уже почти месяц с большим проектом на mercurial, и проблемы такой не возникло еще.
                            +6
                            В гите для подобного есть комманда «git describe» которая генерирует user-friendly версию. Примерно такую

                            v2.1.5-86-g655efd3

                            Эта комманда говорит что текущая ветка основана на таге v2.1.5, отстоит от него на 86 коммитов и затем hash последнего коммита.
                              0
                              Благодарю, этого коммента я и ждал.
                              И следом: а если тэга не было изначально? :)
                                0
                                Тогда ничего не получится :( Git не может «зацепится» ни за какое имя.
                            +1
                            > Маководы могут скачать дистрибутив с официального сайта или установить через MacPorts.

                            А еще можно через Homebrew. Он тянет меньше зависимых пакетов, и по максимуму использует установленные либы, в отличие от Macports, который кучу библиотек, которые уже есть в системе, инсталит по новой.
                              0
                              А не могли бы вы поподробнее рассказать про слияние веток? по какому алгоритму оно происходит? Вот есть файл в мастере
                              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
                                это не смотреть — случайно нажал enter (( мс ниже
                                0
                                а как в GIT происходит слияние веток, а конкретно файлов, на пальцах?
                                допустим в 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() {};
                                

                                Что будет в итоге?
                                  +1
                                  конфликт будет :-)
                                    +1
                                    В итоге будет merge conflict как и в любой другой VCS без встроенного искусственного интеллекта.
                                      +1
                                      Ну я больше по меркуриалу, там будет конфликт. В нем вообще нет родной мержилки для файлов, в мерж это больше операция объединения голов в ветках чем слива изменений в одном файле.
                                        0
                                        а что такое «объединения голов в ветках»? на пальцах )) перезаписать из одной ветки файлами из другой?
                                          0
                                          какой тогда тайный смысл в GIT кроме локального удобства разработчика? ну есть ветка, мы мерджим её с другой. Этот мердж происходит без проблем только в теоретических случаях. На практике мы апдейтимся до текущей версии master потом как-то руками пытаемся впихнуть наши измеменения.
                                            +1
                                            ИМХО, если два человека меняют в одном месте что-то это проблема не системы контроля версий а организации процесса, как уже заметили, тут никакая система контроля версий не поможет.

                                            Мерж в распределенных системах лучше (я говорю за Меркуриал) в том, сохраняется история кто чего с чем мержил, в отличии от SVN.

                                            Вы пробовали вести ветки в SVN? А потом вливать изменения в транк? Там проще было застелиться, иногда конфликты были такие тупые…
                                              0
                                              знаю по перфорсу — вот это действительно, смержить ветки за пару недель — задача на полдня. где в гите был бы фастфорвард
                                                0
                                                Согласен полностью насчет проблем с мерджем, но что тут скажешь — вопрос не самих репозиториев, а способов работы с ними и (важно!) того как построено само решение — ноги растут именно оттуда. С использованием SOLID нечасто приходится проводить «сложные мерджи» одних и тех же файлов — все должно быть развязано и независимо.
                                        +2
                                        Статья хорошая, годная. Вот хотелось бы побольше узнать о том, почему вы перешли с корп СВН на самопальный ГИТ и как вы пропустили Меркуриал?

                                        also
                                        when i see «chmod -R 777» i shit bricks.
                                          0
                                          Я полагаю, что люди повелись на более-менее вменяемый GUI клиент.

                                          Мы вот перешли на меркуриал, меня смутили набор команд в гите в кучей труднозапоминаемых ключей, когда в меркуриале все как-то проще, ну и уже упомянутая доточенная напильником поддержка винды.

                                          Но я наслушался матюков в свою сторону :-) после перехода со SmartSVN.

                                          TortoroiseHg весьма странный SmartHg еще не выпустили (и не факт что выпустят). Не все программеры привыкли в коммандной строке работать. А из IDE много не сделаешь…

                                            0
                                            versionsapp.com/
                                            «apple design arward '09»

                                            тогда расскажите, чем хг лучше свн.
                                              0
                                              Ну мы же не холивары тут разводим. Здесь больше концептуальное обсуждение чем распределенная система контроля версий лучше/хуже чем цетрализированная.

                                              Если есть время, то послушайте первые три UTP подкаста Уптутуна: utp.umputun.com

                                              В кратце: ветки вести намного проще в гите/меркуриале. Что выбрать — личное дело каждой группы разработчиков.
                                                +1
                                                Спасибо.
                                          +1
                                          А как вы решаете (или не решаете) такую проблему?

                                          Судя по описанию у вас фичи разработчиков находятся в локальных ветках. Допустим, что в релиз ХХ вы решили поставить фичи 1,2,3 но в последний момент поняли что фича 2 там не надо и нужно ставить только 1 и 3.

                                          После того как девелоперы закоммитили в интеграционную ветку свои изменения их пересобрать по частям как-то сложновато. Мы не придумали как это сделать без лишнего головняка.

                                            0
                                            и мы
                                              0
                                              можно замарочится и вести ветку на каждую фичу. согласен, что это в некоторой степени гемор, но зато для сборки клиента можно делать выборки из бранчей.
                                                +2
                                                Это не геморой, а правильное использование веток :))
                                                  0
                                                  ну если фичи мелкие то много времени уходит на switch веток. плюс параллельные фиксы багов в отдельную ветку. в общем привыкать довольно сложно.
                                                    +1
                                                    Если отталкиваться от SVN, то да, они (бранчи) хоть в буке (SVNBook) описываются, но от них как правило отказываются. В git всё гораздо прозрачней. В любом случае при правильном подходе 1 фича = 1 разработчик(группа) на единый момент времени, а не 10 фич = 1 разработчик.
                                                      0
                                                      не бывает 1 фича = 1 разработчик. обычно 10 разработчиков = 100 фич.
                                                      к тому же причём тут свн? мы же про гит говорим.
                                                        +1
                                                        Но фичи делаются по очереди)). Просто я не вижу больших проблем при мёрдже в гите и почему там уходит много времени на это.
                                                          0
                                                          Согласен, rebase, fast forward merge, и никаких траблов :)
                                                          Разумеется, если все это правильно использовать.
                                                            0
                                                            вы не правы. вот делаете Вы фичу. к вам подбегает взъерошенный геймдиз и начинает в панике рассказывает о критическом баге, который прямо сейчас нужно залить. а за спиной у него стоит серверник, который хочет, что вы сделали ему клиент, с его фичёй. но вы то делаете совершенно другую фичу.

                                                            но я тоже люблю верить в утопию )
                                                              0
                                                              Баги в транке правятся. Серверник отправляется к менеджерам проекта, т.е. в стек :))
                                                                0
                                                                ага. утопия она прекрасна )
                                                                  0
                                                                  Утопия = наличие адекватных менеджеров проекта (хотя я тебя понимаю):)
                                                                +1
                                                                В контексте Git, используйте stash, который потом сольете с исправленной версией (если это тот же проект). Создаете новую ветку, пишете новую фичу, сливаете в соответствующую изначальную (допустим, master) ветку, достаете данные из stash и продолжаете работать.
                                                                  0
                                                                  спасибо. я умею пользоваться гитом. и если вы считаете постоянное выполнение данных операций верхо удобства, то дальнейшая беседа бессмысленна. я же чётка сформулировал, «что это в некоторой степени гемор».
                                                                    0
                                                                    Ну вот и славно, что умеете. Значит ваш вопрос был просто не в том контексте, о чем я подумал.
                                                                    В общем, целом и глобальном — идеальной утопии (как же вы любите это слово :) не бывает — разумеется, нет идеальных средств, но нет и нерешаемых ситуаций. Мы, видимо, просто о разном говорили.

                                                                    P.S. И нет, эти команды — не верх удобства. Нужно правильно организовывать работу (и в целом, и с SCM — в частности).
                                                                      0
                                                                      я вопросов не задавал ) я констатировал факты.
                                                                        0
                                                                        отстань от человека!
                                                                        0
                                                                        Ну, мы друг друга поняли :)
                                                        +1
                                                        Не правда. На своей шкуре испробовано. Когда у тебя 5 тасков, то забываешь где писал какой код. При постоянных свичах очень часто можно забыть закоммитить текущие изменения / оставить некоторые классы в другой ветке и не заметить этого. При таком режиме версионность из плюса превращается в минус и время тратится на анализ логов и исправление собственных ошибок. В топку.
                                                          +2
                                                          А Вас не учили правилу «сделал таск — закоммитил»?)) На одной работе мы координально решали такие вещи (с свн). На каждую задачу поднимали вообще новую копию проекта и в ней делали всё, потом коммитили и убивали локально :)
                                                            0
                                                            А Вы дорогу всегда на зеленый свет переходите? Когда на бою критичный из-за которого завтра вам закроют приложение, не до хороших манер в свн. Поэтому работа идет другим способом. Бранчи делаются на усмотрение разработчика и если он делает комплексную фичу коммитить он может что хочет и когда хочет. Когда задача готова он реинтегрейтит таск в текущий бранч разработки. Никаких четких правил на этот счет.
                                                              0
                                                              Буду категоричен — у вас неправильно организована работа.

                                                              «коммитить он может что хочет и когда хочет» (а тем более — комплексную фичу!)
                                                              «Никаких четких правил на этот счет.»

                                                              Этого никак и никогда нельзя допускать. Это то, что однозначно (лишь вопрос времени) ведет к краху проекта. В такие моменты (завтра закроют приложение) — как нельзя больше нужна организация. Иначе, вы сами того не осознавая, потратите куда больше времени на «ручные правки», «костыли» и «временные решения».
                                                                0
                                                                Да. Если фича на 15 минут, ее можно сделать прямо на ветке разработки. если фича на 2 дня, то делаем отдельную под это ветку и работаем с ней. Я бы с вами согласился насчет краха, если-бы у меня не было за плечами готовых проектов, которые сделаны и сданы в срок, окупили себя и уже по году работают в чистую прибыль. Я думаю Ваш подход имеет право на жизнь в долгостроях. У нас разработка на пол года и мы не успеваем зарасти костылями.
                                                                  +1
                                                                  Дело не во времени, а в организации процесса.
                                                                  0
                                                                  Ну, я не хочу никого учить работать, я просто высказываю свое видение. Просто вы заявляете о проблеме, а я для себя вижу, как ее решить. Если у вас есть свое (неважно какое, главное — рабочее) решение — используйте его.
                                                                +1
                                                                Бррр… Давайте по полкам.
                                                                Фича — новый функционал
                                                                Багфикс — исправление ошибок.

                                                                1 фича = 1 бранч
                                                                1 багфикс = комит в транк

                                                                Ситуация. Я работаю над новой фичей (придумайте сами какой), тут ко мне подбегает менеджер проекта и говорит, что есть баг, который нужно срочно пофиксить.

                                                                Мои действия. Я поднимаю проект заново (в отдельной папке), правлю баг и заливаю в репозиторий (если свн), или просто свитч на другую ветку (если тот же гит).

                                                                Укажите где я тут не прав.
                                                                  0
                                                                  Есть пул фич на 2 недели. Разработчики работают вместе на 1 бранче и коммитят изменения на свое усмотрение. Если фича долгоиграющая и придется разобрать проект, то разработчик создает себе отдельный бранч под это. Т.е. вводим принцип ответственности перед другими разработчиками а не правила.
                                                                    0
                                                                    Игра понятиев)) Любое правило исходит из этого.
                                                                      +1
                                                                      девочки, не ссорьтесь.
                                                                      всякого рода паттерны как раз и нужны для того, чтобы избежать проблем. если у вас есть паттерн веток и комитов, то если все будут ему следовать и не делать грязных хаков, то все будет хорошо.
                                                                        0
                                                                        Что же все так на слово «паттерн» подсели. Давайте использовать слово «правила», оно больше подходит :).
                                                              0
                                                              Ну, как можно про что-то «забыть» или «не заметить»? Это уже вопрос самой организации рабочего процесса. При желании или при безответственности можно в чем угодно навести хаос.

                                                              P.S. Версионность, в данном случае — единственный выход избавления от полного хаоса.
                                                                +1
                                                                Не забывает только анонимус и cron демон. Разработчик в первую очередь должен выполнить задачу в минимальный срок и любые рутинные процедуры отнимают ценное время, а при наличии ошибки еще и время на их исправление. Еще раз. Я исхожу из постулата, то разработчик неизбежно ошибется и чем меньше оставить ему мест для ошибок тем эффективней будет разработка в целом.
                                                                  0
                                                                  «Я исхожу из постулата, то разработчик неизбежно ошибется и чем меньше оставить ему мест для ошибок тем эффективней будет разработка в целом.»

                                                                  Именно так. Поэтому я и ответил на ваш комментарий выше, что нельзя пускать на что-либо на самотек и на усмотрение торопящегося девелопера (разберется, мол).
                                                            0
                                                            Согласен с предыдущим комментатором — это правильный подход. А затем, при необходимости коммита в основную ветку — нужно определить приоритеты и действовать последовательно. Ну а то, что какая-то фича, вдруг, просто «не нужна» — это скорее частный случай. Большинство разрабатываемых фич, все-таки нужно.
                                                          0
                                                          А в чем сложность пересобрать и как это зависит от репозитория? Есть такая техника как постоянная интеграция (CI), и ее нужно придерживаться. Иначе в любом случае «пересобирать сложновато» будет.
                                                          0
                                                          Ну в другой систме контроля версий это тоже не работало гладко.

                                                          Вопрос. Как исключить фичу Х из релиза? У нас релиз раз в неделю и не всегда все уходит на продакшн. Скажем 15 фич из девелоперской ветки ставятся, а 3 нет, как их безболезненно вырезать?
                                                            0
                                                            чет не там «ответить нажал :-)»
                                                            0
                                                            Git — прекрасная VC-система. И она годится для разработки на чем угодно — например, отлично работает с C#/Visual Studio, используя Git Source Control Provider и GitExtensions.

                                                            Минус один — не так очевидно, с чего начать работу с Git. Зато, начав, уже не хочется переходить обратно на SVN/Mercurial/Perforce. Советую всем, кто не уверен, попробовать.

                                                            И еще — я не фанат командной строки, поэтому лично мне удобнее использовать GUI для всех основных сценариев.
                                                              0
                                                              Для VS.NET оченно не хватает что-то типо VisualSVN, но для git…

                                                              GitExtensions мягко говоря сакс :(
                                                                0
                                                                Там еще работать и работать им, но и этого хватает. Да, VisualSVN хорош, для Гит интеграцию осуществляет Git SC Provider.
                                                              +1
                                                              Думаю, стоит упомянуть, что у git есть проблемы с именами файлов в UTF-8
                                                                +2
                                                                А зачем файлы так называть?
                                                                  +4
                                                                  Как, вы разве не называете файлы типа: "مرحباالتطبيقالعالمي.php"?? :)
                                                                    0
                                                                    файлы всякие нужны. файлы всякие важны.

                                                                    Тем более, это флеш. У дизайнеров бывают файлы «фон.jpg»
                                                                0
                                                                Я позволю себе сравнить с subversion, с моей точки зрения

                                                                2. Простые ветки в git позволяют в любое время достать версию любого предыдущего релиза и работать с ней не мешая идущей разработке. Исправить баги в отдельной ветке, смержить в предыдущий релиз и в текущую разработку.


                                                                Ну так и в subversion все так же

                                                                3. git хранит все свои данные в одном каталоге, а не плодит повсюду папки .svn. Переключить проект с одной ветки на другую можно всего одной командой или парой кликов в клиенте. При этом содержимое папки проекта заменяется новым, которое соответствует выбранной ветке..


                                                                Насчет папок .svn — не вижу тут большой проблемы. Лучше было бы без них, но мне они не мешают особо.

                                                                Про переключение — в subversion переключиться с ветки на ветку также легко, и содержимое аналогично заменяется. Возможно, тут есть ньюансы, и git переключает лучше, но этого я из текста статьи не понял.

                                                                4. Как я уже сказал, все комиты сохраняются локально и становятся частью общего репозитория только тогда, когда непосредственно пушатся в него. Это сложно вообразить, но порой получается так, что нет доступа в интернет, а работать нужно.


                                                                Ну тут да, если нет интернета — ветку не создать. Пока мне лично не сильно мешало, однако, вещь полезная, безусловно плюс.

                                                                5. Удобные частичные комиты
                                                                Непосредственно перед комитом помечаются файлы, которые в него войдут с помощью git add. При этом существует возможность в отдельный комит внести часть изменений в файле, а не файл целиком.


                                                                В subverion также помечаются нужные файлы, часть файла закоммитить… хм. Ну, не знаю.

                                                                6. Возможность припрятать изменения.


                                                                Пока не понял, зачем это нужно.

                                                                Итого для себя один плюс — создание веток, когда нет интернета. Не густо, прямо скажем.

                                                                Сопротивление админов...


                                                                Ну, в таком раскладе, если админ обеспечивает «интернет», то его недоумение мне лично понятно — никаких других плюсов я лично пока не вижу.

                                                                Резюмируя — тема крупных преимуществ git (по сравнению с svn) не раскрыта, на мой взгляд. Однако, нутром чувствую, что-то у git есть. Возможно, там гораздо лучше реализован merge и переключение веток.
                                                                  +2
                                                                  Извините, но вы не можете сравнивать не попробовав. Нельзя рассуждать о достоинствах езды на автомобиле, если до этого вы ездили только на велосипеде.
                                                                  Ну да, тут надо крутить педали, а там нажимать на них, какая разница, не вижу особых преимуществ…
                                                                  Попользуйтесь хотя бы месяц, и вы сами все поймете.
                                                                    +1
                                                                    Я ведь сравниваю и рассуждаю на основе изложенного материала и опыта использования subversion. Да, переключение между ветвями и merge не такие гладкие, как хотелось бы, если в git что-то сделано гораздо лучше, хотелось бы знать, как и что именно.

                                                                    Зачем нужна статья, которая не раскрывает преимуществ?
                                                                      0
                                                                      Эта статья не сравнивает 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
                                                                        Если статья не сравнивает, тогда аргументация «Почему git» в терминах «основные плюсы» наверное не очень правильна. Плюсы — они же относительные.

                                                                        Да вот и автор пишет сам: «Отличается от SVN отсутствием необходимости в центральном репозитории (который все же хорошо было бы держать)». Т.е. как бы плюс, но не особо и нужный, ибо все равно центральный репозиторий нужен.

                                                                        Теперь по пунктам

                                                                        1. Как же на завязан, если сливать в центральный репозиторий все равно придется.
                                                                        2. Вот это-то и не раскрыто совершенно на примерах. Типа вот в svn такая-то операция делается вот так, а в git — по другому, видите, гораздо лучше, особенно слияние. Пока не вижу. Про кучу локальных веток я понял.
                                                                        3. Что мешает переключиться на другую ветку-то?
                                                                        4. Это не могу оценить, ни разу не требовалось

                                                                        Все равно получается, что текста вроде как много, но «почему git» предлагается узнать на собственном опыте.
                                                                  0
                                                                  Еще, для правильного использования веток есть отличный набор высокуровнивых расширений — git flow. Описание есть в статье Why aren't you using got flow, а сам проект живет на github nvie/gitflow.

                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                  Самое читаемое