Пользователь
0,0
рейтинг
14 сентября 2010 в 14:11

Разработка → Почему Git

Git*
Было время, когда я ничего не знал про VCS, ни что это такое, ни тем более зачем это мне. И верхом своих достижений считал папочку с архивами версий. К моменту осознания необходимости системы контроля версий я уже набил шишек и прочувствовал необходимость такого инструмента. Но борландовский аналог CVS меня не впечатлил. У каждого файла свой номер версии. Как мне получить срез определенного релиза я так и не разобрался. А в это время SVN победоносно шла сквозь умы разработчиков. Черт, это было то, чего мне так не хватало. Прочитав доку и начав работать я просто влюбился в нее. Да, были трудности и определенные неудобства, но куда без них.
Так я и работал бы в SVN, но ничего не стоит на месте. В интернете уже потекли тонкие ручейки новостей про Git. Я не кидаюсь за каждой новой технологией, и прошло уже достаточно много времени, пока мне не прожужжали этим Git’ом все мозги. Мне стало любопытно, я вначале присматривался, примерялся, а потом плюнул и начал новый проект на Git. Мучался с ребятами 2 недели, накачал литературы, написал шпаргалку… ничего, привыкли, … а потом меня поперло.

Теперь меня регулярно просят рассказать про Git и что в нем такого. Уже надоело, поэтому этот пост для тех, кто еще сомневается.


Все локально
Репозиторий, история, ветки и коммиты.
Отсюда вытекает 2 важных следствия: все очень быстро, и второе — вы получаете абсолютный контроль над репозиторием.
  • Создать репозиторий в текущей директории — «git init». Все.
  • Всего одна папочка .git и никакой порнографии ввиде .svn в каждой директории.
  • Интернет не нужен. Работать одному вообще шикарно — локальный репозиторий, который разворачивается за доли секунды. Работа в распределенной команде — у каждого своя копия репозитория, никто не зависит от доступности центрального сервера.
  • Не надо задумываться о создании системы резервного копирования. У каждого участника есть копия, из которой можно поднять оригинал.
    Поднимите руки те, кто поднимал потерянный svn-репо из своей копии git-репозитория.
  • В своем репозитории вы делаете все, что хотите. Любые ветки, никто их не увидит.
    Черт, я помню как мне запрещали в SVN создавать отдельную ветку для работы над экспериментальной версией.

Контроль
В Git можно делать с коммитами и историей все что угодно:
  • Удалить коммит, как будто его и не было
  • Изменить комментарий коммита
  • Поменять коммиты местами
  • Объединить несколько коммитов в один, особенно когда нужно «докоммитить» что-то забытое
  • Разбить коммит на несколько
Ветки:
  • Перенести/скопировать коммит из одной ветки в другую
  • Переместить ветку в любую точку
Очень хорошо это описано здесь: http://gq.net.ru/2009/12/16/git-history-rewrite/
От таких возможностей сносит голову и кому-то это может показаться слишком опасным. Да, пару раз я терял коммиты из-за своих неопытных манипуляций и потом рылся в «корзине», чтобы их восстановить.
Но по мере того, как привыкаешь к этому и понимаешь что и как работает, у тебя вырастают крылья, и ты начинаешь работать намного эффективнее, получая попутно кучу удовольствия от этого.


Ветки
Git — это ветки. Это настолько просто, гибко и удобно, что все делается в ветках. От релиза, до маленьких задач.
  • Создать ветку, переключиться в нее, объединить ветки, вернуться назад — это рутинные операции.
  • Мерджить одно удовольствие. Есть конфликты или нет, все проходит очень легко и никогда ничего не теряется.
  • За исключением релизных, большинство веток очень короткие и живут 1–3 дня.

Коммит
Чтобы сделать коммит, надо указать какие именно изменения нужно туда положить. Изменения, а не файлы. «git add» надо вызывать как для измененных, так и для новых файлов. Таким образом подготавливается временное состояние, которое я называю «временный коммит» (в оригинале «staging area» или «index»).
В чем преимущество:
  • Я всегда могу посмотреть что я буду коммитить, а что не попадет в коммит
  • Поскольку git принимает «изменения», я могу положить в коммит только часть изменений в одном файле, а другую часть в этом же файле откатить или положить в другой коммит.

    Последнее время я использую только «git add -p» — Git показывает чанк за чанком (набор изменений в рамках файла) и спрашивает добавить в коммит или нет. Так я вижу, что я изменил и буду коммитить. И поэтому в коммит у меня никогда не попадут отладочный код, комментарии, лишние правки, пробелы. И коммиты получаются четкими и атомарными.

Диф и лог
  • Я могу посмотреть диф всей ветки или группы коммитов, чтобы не листать по коммиту, особенно, если они неграмотно оформлены.
  • Могу посмотреть разницу между 2 ветками, посмотреть какими коммитами они отличаются.
  • Посмотреть диф без учета пробелов (git diff -b -w), если кто-то увлекся форматированием и превратил диф в одну сплошную кашу
  • Могу в конфиге настроить кучу алиасов, которые будут выводить логи коммитов в разных форматах, например, сформировать change-log.
Лог — это вообще бездна возможностей.


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


Bisect
Команда для поиска коммита, в котором была допущена ошибка. Я указываю коммит, где я точно знаю, что этой ошибки нет. И коммит, где эта ошибка уже есть. Далее Git бинарным поиском выбирает коммит для проверки, переключается на него и предлагает ответить, есть здесь ошибка или нет. И так до тех пор, пока не будет найден ошибочный коммит. Если есть возможность, то можно написать скрипт, который будет автоматически проверять наличие ошибки и возвращать соответствующий код. Отдать этот скрипт в bisect и получить битую правку.


git-svn — для тех, кто в подполье
Вы можете локально работать в Git и коммитить при этом в SVN. Никто даже не догадается, если вы сами не проколетесь по своей счастливой физиономии. Вы можете легко объединиться со своими коллегами подпольщиками и делиться веткам и правками из своих репозиториев.


Субмодули
Git позволяет включать в проект другие проекты. Подключаются они как субмодули:
  $ git submodule add git://github.com/maxim-oleinik/sfDoctrine2Plugin.git plugins/sfDoctrine2Plugin

Git создаст директорию «plugins/sfDoctrine2Plugin» и развернет там еще один репозиторий, а под контроль поставит хеш ревизии. Если зайти в эту директорию, то мы попадем уже в другой проект. Там можно работать и коммитить как обычно, только в родительском проекте Git покажет, что подпроект обновился и предложит сохранить ссылку на новый коммит.
  • Удобно работать в основном проекте и одновременно коммитить в разные субмодули.
  • В Git нельзя подключить указанную директории из другого проекта, как это делает svn:externals. Только весь проект целиком.
    В том и суть, чтобы выделять самостоятельные модули и оформлять их в отдельные репозитарии. Правда, становится немного неудобно работать, когда у субмодулей есть свои субмодули и т.д.

GUI и консоль
Я, честно говоря, не знаю какой есть GUI у Git. Я никогда им не пользовался и рекомендую не лишать себя удовольствия работы с Git’ом в консоли. Не превращайтесь в мартышек, которые ищут нужную кнопку или галочку в интерфейсе, вместо того, чтобы просто набрать команду в консоли.
Ладно, без обид. Я просто хотел сказать, что работа в консоли намного богаче и удобнее.
У кого нет нормальной консоли… ну, тогда выбирайте GUI, IDE или… OS, у которой эта консоль есть.
Единственным окошком, которым я регулярно пользуюсь, — это «gitk -all &». Он показывает дерево коммитов с ветками и тегами. Очень удобно смотреть где ты сейчас находишься, где какие ветки и как они переплетаются. Там есть простой поиск и просмотр дифа.


Работа в команде
  • В git нельзя закрыть доступ к определенной ветке или модулю. Или все или ничего. Но это еще ни разу не создало мне проблем. Если кто-то ошибся и закоммитил не туда, куда ему следовало (как мы заранее договорились), тогда я просто откачу эти правки так, как будто их и никогда и не было, и проведу разъяснительную беседу.
    Как вариант, можно выделить отдельный репозитарий с ограниченным доступом и рабочий — для всех.
  • Все задачи делаются атомарно в ветках и в таком же виде передаются на ревью и мердж. Т. е. при желании, ни один коммит не попадет в основной ствол без ревью.
  • Очень удобно проводить ревью задачи, которая выполнена в отдельной ветке. Посмотреть полный диф всех коммитов, что-то исправить, прокомментировать, отправить обратно на доработку, а потом объединить отдельные коммиты и слить в основную ветку.

GitHub
Это классная платформа, где можно бесплатно разместить и опубликовать свой репозиторий. Где живет куча проектов, которые форкаются, развиваются и обсуждаются. Сейчас там лежат все мои проекты.
Бесплатно для открытых проектов и мин 200 руб/мес, чтобы закрыть доступ.



Это конечно, далеко не все, что может Git. Есть еще куча всего, чего я не рассказал и чего я до сих пор еще не знаю. Я постарался осветить принципиальные моменты.
У Git’a, конечно, есть и определенные минусы и трудности, но без них не бывает. Да они и не существенны. Чаще всего это вопрос git-way.
Правда у Git’а есть один серьезный минус — он не для ленивых. Поэтому подумайте заранее, прежде чем предлагать Git таким ребятам.

Что дальше


Дальше — начинать работать. Можно читать кучу обзоров и обсуждать сколько угодно, но до тех пор пока не начнешь работать, ничего не изменится.
За один день я перерыл доку и начал работать, 2 недели привыкал, через месяц учил остальных, через 3 — расправил крылья.

Как начать
  1. Скачать, установить и настроить, я думаю, ни у кого не возникнет проблем. Почитаете еще статьи в этом блоге про настройки и прочие фишки.
  2. Прочитайте любую книгу из списке указанного ниже. Правда, прочитайте. Хоть по диагонали, зато будете знать, что вообще есть. Это легко сделать за пару часов.
  3. И начинайте работать над новым проектом или переносите существующий (импортировать не составить труда).
Есть чит-шит, который поможет с командами на первое время. Есть «git help <команда>». Рекомендую не лениться и регулярно читать хелп для каждой новой команды, а потом еще читать и перечитывать. Так я узнал большинство возможностей, тонкостей и нюансов.
Ну и пишите, если что не понятно. Мне очень трудно понять, какие очевидные для меня вещи, не понятны новичкам. За второй статьей дело не станет.

Ссылки:
Максим Олейник @Partizan
карма
105,9
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (265)

  • +8
    Зря вы так против gui. Есть команда git gui которая является простенькой надстройкой над консолью. Так вот эта git gui ползена новичкам, если не понятно, как сделать операцию в консоли. Можно не заниматься нудными поисками в гугле, а просто сделать операцию в графическом интерфейсе.
    Вот например, я все ещё не понял какой командой надо помечать файлы в которых я разрешил конфликты при мерже. И ничуть не страдаю от того, что приходится написать git gui и дотянуться до мыши. (Подскажите, если не сложно)
    • 0
      Черт, промахнулся. Ответил ниже.
    • 0
      > И ничуть не страдаю от того, что приходится написать git gui и дотянуться до мыши.
      Не ленитесь учиться. Я себя очень часто заставляю залезать в хелп или гуглить, чтобы понять как что-то работает.
    • +2
      Ещё есть удобный SmartGit.
      • 0
        Спасибо, посмотрю.
        • 0
          Я тоже рекомендую.
    • +3
      Виндузятники используют TortoiseGIT и нахваливают.
      • 0
        Тортилла есть для всего как я понял. По крайней мере в своё время скачивал для CVS, потом SVN, а последней для mercurial.
        • 0
          Самый развитый — для SVN.
          Давно хотел перейти на DVCS, выбрал BZR, но под него Tortoise оказался глючный и недоделанный.
          А вот под Git Tortoise вподне работоспособен и развит — поэтому теперь я работаю с Git.
    • 0
      git-gui и gitk убоги.

      Для Linux есть gitg, для OS X — GitX. Они замечательно комбинируют в себе возможности этих двух утилит.
  • 0
    > какой командой надо помечать файлы в которых я разрешил конфликты
    git add path/to/file
    • 0
      Немаловажно еще и то, что решать коммиты в git — одно удовольствие. Порой даже даже жалеешь, что после очередного мержа всё прошло гладко:)
      • 0
        да ладно, все равно файл становится кашей с символами >>> и <<<, который надо разрулить вручную
        • +1
          попробуйте git mergetool
          • 0
            спасибо попробую
    • 0
      Спасибо. Вероятно я раньше что-то делал не так. Сейчас проверил — действительно работает.
  • +8
    Хорошая статья, давно хотел узнать чем же хорош Git.

    Теперь кто нибудь напишите чем хорош Mercurial)
    • +11
      бОльшая часть описанных здесь фич применима и к Mercurial'у
      • +3
        Ну и bazaar туда же
    • +1
      • +2
        Там только «гитхаб» плюс по отношению к хг. Стейджинг — это недо-mq, cheap local branching — это вообще три раз порванный баян.
      • +4
        Вот правильный ответ gitvsmercurial.com/
  • +21
    Топик скорее не «Почему Git?», а «Почему распределенный VCS?», все плюсы есть и у конкурентов (например в mercurial).
    • –1
      Не все. Например, нет stash.
      • 0
        ну, у каждого есть свои плюсы и минусы. Например, rerere, но зато есть hg serve и т.д.
      • +1
        stash разве не заменяет банальным diff?

        как-то так:

        hg diff > stash.patch
        hg revert
        ...work
        hg commit
        ...work
        hg commit
        patch stash.patch
        • 0
          s/заменяет/заменяется/
      • +8
        stash в меркуриале — shelve.
      • +2
        • 0
          Уже два :) Вот бы ещё кто показал расширение, позволяющее в changeset, не отправленный в удалённую репу, добавить изменения как в darcs amend-record. Тогда остальные DVCS (для моих требований) будут совсем не нужны.
          • +2
            hg rollback для начала. А вообще — mq такое может, например так:
            hg qimport -r .
            hg qrefresh -e
            hg qfinish .
            

            1) импортировать как патч mq можно только голову или коммит, у которого дети — уже патчи
            2) -e — редактировать сообщение, можно опустить, естественно

            Вообще стоит просто почитать hg help mq. Я как-то давно уже хочу написать руководство по mq, но руки никак не доходят. %)

            Attic, кстати, это нечто среднее между mq и shelve. С помощью mq тоже можно эмулировать stash.
          • 0
            Да, сначала откатиться hg rollback, а далее надо включить встроенно расширение mercurial.selenic.com/wiki/RecordExtension
        • 0
          Для меня является большим перепоном то, что для того что-бы сделать так как работает git из коробки(т/е так как мне нужно) — нужно доставить пачку плагинов в mq (и это каждому члену комманды — время внедрения нового человека в команду затягиватся) — хотя если работать одному то это наверное даже плюс
          • 0
            «доставить пачку плагинов в mq» звучит странно, учитывая что mq — сам по себе плагин. :)

            Да, меня эта тема тоже немного волнует, и у меня есть некоторые мысли по поводу того, что б сделать, чтобы это улучшить.
          • +1
            Я не знаю, какой ОС пользуетесь вы, но в ОС семейства «неготовых к десктопам» плагины к mercurial не доустанавливаются, а включаются.
          • +2
            Здесь есть резон:
            В гите есть 150 команд, в меркуриале по умолчанию 10. Цифры примерный!!!

            Если хотите функционал пошире — включите необходимое. Большинству не нужно, они не должны путаться, страдать и т.п. от обилия команд.

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

            У меня не «из коробки» только 2 расширения.
      • +1
        есть. mq, attic — на выбор
      • 0
        что если я редактировал одну ветку, потом мне срочно потребовалось переключиться в другую ветку, я там наредактировал, а потом мне потребовалось переключиться в третюю?
        • +2
          hg help shelve, ага?
          • 0
            я про гит спрашивал…
            • 0
              git stash
              • 0
                и? можно сделать 3 стэша и переключаться между ними?
                • 0
                  да, хоть сто. просто по имени будете к ним обращаться.
                  • 0
                    а в качестве имени будет хэш чтоли? или можно как-то задать имя?
                    • 0
                      git stash save «my stash name»
                      • 0
                        а в доке написано, что там не имя и какой-то мессадж пишется…
                        • 0
                          Точно, сейчас проверил. Там нумерованные стеши. То ли я что-то перепутал, то ли разработчики что-то поменяли. Я редко использую больше одного стеша.
                    • 0
                      Почитайте тут progit.org/book/ch6-3.html очень хорошо описана работа с git'ом.

                      … If you want to apply one of the older stashes, you can specify it by naming it, like this: git stash apply stash@{2}
                      • 0
                        ясно, главное не запутаться в этих стэшах %-) а то в скрине я всё время путаюсь где у меня что ._.
                        • 0
                          в конце концов, если нужно столько переключаться, то можно и закоммитить изменения. а потом возвращению в ветку изменить/удалить его или так оставить
    • 0
      В топике нет ни слова о распределенности.
  • 0
    pragprog.com/titles/tsgit/pragmatic-version-control-using-git — вот эту сейчас читаю. Достаточно понятно изъясняется с примерами по каждой упомянутой команде. Возможно стоит добавить в список. Хотя я других не читал по этой теме, сравнить не с чем.
    • 0
      Спасибо, добавил в список.
  • +5
    Какое-то последнее время нездоровое количество визга по поводу Git-а. Был у меня один проект, который надо было делать вдвоем, а сервер поднимать не хотелось. Поставили Git, зачли репозитарий.

    Сразу же выяснилось — в Git-е нельзя создать пустую папку. Мелочь, скажете вы? Вроде бы да, но, согласитесь, пустые папки бывают нужны — например, папка для данных приложения, которая будет потом заполняться рантаймом, а так же начальная структура каталогов. Пришлось всюду положить по пустому файлу, что само по себе костыль.

    Дальше — больше. Хорошо, начальная структура каталогов, первый проект — все это было сделано, закоммичено, проблем не вызвало. Что дальше? А дельше надо передать проект своему напарнику. И тут выяснятся, что сделать этого напрямую мы не можем. Что надо поднимать либо веб-сервис с WebDav, либо чтобы он имел доступ к моей ФС, либо поднимать git-server. Напрямую p2p два клиента без поднимания костылей подключиться и сделать push не могут. А значит все равно нужен какой-то эталонный центральный сервер.

    А если все равно нужен центральный сервер, то в чем прелесть? По сути — только в простом управлении ветками. Причем именно в их создании/удалении, т.к. опции типа редактирования коммитов — это, конечно, клево, но так ли уж сильно нужно?
    • +9
      > Напрямую p2p два клиента без поднимания костылей подключиться и сделать push не могут
      Могут напрямую через ssh
      • +1
        Вот именно! А еще есть hg bundle. И можно хоть мылу/аське/шаре коммитами кидаться.
        • 0
          Ой, сорри, я о Mercurial. :) Но в git'е тоже такое можно. :)
      • +3
        Я так понимаю, что речь идет про git+ssh? Честно скажу, Git я собрался использовать после того как посмотрел презентацию Git-а на Google Tech Days, проводимую самим Линусом Торвальдсом (линк). Там был вот такой кадр:



        Глядя на нее, я ожидал поддержки p2p соединений на уровне самого Git-а. Например, подключение на удаленный адрес: порт, открываемый коллегой, либо чего-то в этом роде.

        А получается, что все эти веселые смайлики сидят исключительно на *nix машинах, на каждом установлен и настроен SSHd, созданы аккаунты для каждого из соседей (!!!), а когда появляется новый член, все, видимо, дружно создают ему по аккаунту, когда уходит — дружно его удаляют. Кроме того, SSH — это ведь как бы не только Git, не так ли? Значит за каждым из компов сидит сисадмин, который не поленился настроить должным образом систему и SSHd, чтобы обеспечить безопасность пребывания малознакомых людей на своем десктопе.

        Наверняка, найдутся ситуации, когда это будет не просто возможно, но и полезно и необходимо. Но так ли все просто и радужно на самом деле, как в рекламе? Используется ли реально Git именно для децентрализации, а не только для легкого управления ветками?

        P.S: судя по количеству минусов, которые были получены в карму, на фоне отсутствия конструктивного диалога — интерес и правда «нездоровый». Кто-то воспринял критику Git-а как личное оскорбления что ли?
        • 0
          Вся децентрацизация крутится вокруг обмена патчами:
          — Положите bare-репозиторий на публичный сервер и обменивайтесь информацией через него.
          — Можно работать с системой форков, как это устроено на GitHub — здесь неограниченная связь многие ко многим.
          — Можно коннектиться напрямую через SSH. Это может быть оправдано, когда вас всего двое.
          — Можно обмениваться патчами по почте: git format-patch, git send-email, git apply или git am

          Все зависит от того, как у вас организована работа в команде. Наиболее простой и удобный способ — это выделить один репозиторий для обмена. А уж комбинировать все указанные выше способы вы можете как угодно в соответствии с потребностями.
          • +1
            Наиболее простой и удобный способ — это выделить один репозиторий для обмена.

            Абсолютно с вами согласен. Но по сути у нас это ведь получается эквивалентом централизованной системы разработки. А команды формирования патча, который может быть переслан через e-mail, есть и в SVN — svn diff / svn patch.
            • 0
              В централизованной системе очень велика зависимость от центрального сервера и низка скорость обмена информацией плюс дорогостоящи прыжки по истории (checkout). В распределенной системе достаточно выживания хотя бы одной рабочей копии — и по ней можно восстановить центральный репозиторий с точностью до последнего pull c него.
              • 0
                Т.е. различие заключается в том, что в Git локальные репозитории дублирует всю историю изменений, в SVN же — только текущую ревизию. Поэтому если вдруг не дай Бог что произойдет с центральным сервером, то по Git-у мы восстановим все ревизии, а по SVN — только последнюю.

                Правильно я понял?
                • 0
                  Да. У каждого СВОЙ локальный репозиторий со всей историей.
                  И центральный репозиторий — это не больше чем соглашение, что конкретно именно эта копия будет использоваться для обмена.
                • 0
                  Ключевое различие именно в этом — каждая рабочая копия в распределенной системе контроля версий является полноценным репозиторием.
                  Отсюда и все плюшки — высокая скорость операций, меньшие требования к каналам связи, высокая отказоустойчивость, любая топология сети репозиториев, локальные commit/update/checkout.
                  Минусы тоже есть (они напрямую вытекают из плюсов) — более сложная двухступенчатая система заливки, для поддержки централизации требуются дополнительные технические или организационные меры.
                  Но если минусы легко преодолеваются обучением и практикой, то плюсы остаются навсегда.
                  Я полагаю, в будущем принудительно централизованные системы отомрут — они уже сейчас выдерживают конкуренцию с децентрализованными только за счет легаси.
                  • 0
                    Дык с этого же и начата ветка — рабочая копия НЕ ЯВЛЯЕТСЯ ПОЛНОЦЕННЫМ репозиторием: в неё пушить из другого репозитория нельзя без дополнительного танца с бубном!
                    • 0
                      Хотя, как сказано комментом ниже, простенький демон же в комплекте есть…
        • +1
          Я ниже уже писал, но повторюсь — Вы просто не до конца разобрались.

          SSH вовсе не обязателен. Не хотите SSH — ради бога, используйте родной протокол Git'а, который так и называется — «git». В поставке с Git'ом идет демон, который слушает порт 9418 и отвечает на все запросы одного репозитория к другому. Ровно тот самый p2p, которого Вы хотите.

        • 0
          git — это система контроля версий, а не p2p файлсервер с поддержкой истории (как иногда люди пытаются использовать VCS вообще).

          По вашей логике, нужно было бы в git воткнуть сам ssh/sshd, а также zeroconf какой-нибудь, а потом молиться, что бы этот комплект заработал у всех пользователей, со своими привычками, операционками и аппаратурой.

          P.S. Если есть организационные проблемы, совсем необязательно настраивать sshd на том хосте, на котором работаешь — можно и виртуализацией обойтись.
    • +2
      Интересно, как вы представляете передачу p2p без доступа к фс…
      • +8
        hg serve и передавай по хттп
        • 0
          Гит тоже поддерживает передачу по HTTP :-)
          • +4
            piranha@gto ~/dev/work/core2> git instaweb
            lighttpd not found. Install lighttpd or use --httpd to specify another httpd daemon.
            


            Удобно! ;)
    • 0
      да, полная автономность гита это огромный минус.
      Я так и не понял как удобно огранизовать реплики на друзей и обратно.

      На гит я перешол для локальной разработки, после того как горе админ уничтожил svn репу на сервере, а я узнал что вообще для папки очень сложно поменять svn сервер.
      • +1
        svn switch --relocate newsvnserver
        • 0
          Нет.
          У вас был svn сервер, вы перешли на другой.
          Этот svn — умирает, вы ругаетесь и переключаетесь на старый svn.
          Ну и фигу ловите. «Слишком разные сервера, даж не знаю как быть. Но команду вертаю тебе» (с)SVN

          А все дело в том что физически правки храняться на сервере, а на клиенте их нет.
          И если сдох сервер.
          Все.
      • +2
        Сложно? svn relocate oldurl newurl
        !?!?!?!?!
    • +2
      Пустые папки обычно задаются созданием в них файла .gitkeep
      • +3
        костыль же…
        • –1
          пустые папки сами по себе костыль, если уж так.
          • +7
            Допустим я начинаю веб-приложение. Мне важно, чтобы в команде было единое мнение по поводу того, куда должны класться CSS, JS файлы, файлы картинок, шаблонов, SQL дампов и прочего.

            Для этого я создаю структуру каталогов, в которой создаю пустые папки под js, css, пд картинки, под аплоады, под классы, ресурсы и прочее. Теперь другие разработчики будут следовать данной иерархии и, если надо, изменять или дополнять ее, не создавая при этом анархии. Со временем эти папки наполнятся, а ненужные удалятся, но в начале пути мне необходимо чтобы они были и были при этом пустыми.

            Почему инструмент разработки должен диктовать, что мол «неет, братец, тебе не нужны пустые папки»?
            • –10
              слушай, угомонись уже. гит отслеживает файлы, не папки. нужна папка — добавь пустой файл. нужна папка без файла — пользуйся свн. вот и всё пространство решений.
              к тому же куда все должно складываться решается административно, а не через сорс контроль. никакой свн не запретит мне свалить все картинки в папку для цсс.
              • +3
                Попытка говорить в таком тоне, увы, не делает вам чести.
                • +1
                  о, прощу прощения. я видмо должен был сказать что в ваших речах
                  нездоровое количество визга

                  в позиции «а ну-ка попробуйте переубедите меня, но на каждый ваш аргумент я выдумаю почему мне это не подходит» тоже мало хорошего
            • 0
              Bazaar вроде как хранит пустые каталоги.
            • +1
              Это стандартная ошибка — попытка решить организационную задачу техническими методами.

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

              Именно он и будет определять структуру проекта, а не куча заранее созданных пустых папок, в которых, без руководящего документа, обязательно кто-нибудь запутается и насоздает других папок, или поудаляет лишние.
              • +2
                Отвечу всем сразу, высказавшим мнение о составлении письменной спецификации: административной проблемы в данной ситуации не существует. Команда дружная и не собирается загаживать проект. Все согласны, что структура должна быть.

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

                Зачем плодить документы и бюрократию, когда достаточно создать 5-7 папок?
                • 0
                  «Вы не должны этого хотеть» ©

                  Люди должны именно смотреть спецификацию, и знать, что они делают. Человек, которому понадобится первому создать файл в несуществующей папке, создать эту папку. Всем остальным, кому эта папка не нужна, они не должна мозолить глаза.

                  Нет такой необходимости, понимаете? Зачем создавать сонм пустых папок? Если нет файла — папка не нужна. Если человек хочет создать файл — он должен знать, куда его положить, а не рыться в куче существующих и угадывать, какая подходит. И если в нужном месте еще нет папки — он ее создаст.
                  • +1
                    Тем не менее бывает необходимость создавать именно пустые папки если нужно сохранить определенную структуру каталогов, например возьмем любой php-фрэймворк, у него есть определенная файловая структура, но не во всех папках есть файлы (это может быть папка для кэша или что-то подобное) и тут подобный подход удобен. Вы можете сказать, что есть и другие методы решения такой проблемы, но создание пустой папки тоже имеет право на жизнь.
                    • 0
                      Кстати да, папки под кэш — тоже наглядный пример. Само приложение создать их не может, т.к. прав на создание собственных папок внутри корня сайта у веб сервера никогда не бывает (иначе это была бы брешь в безопасности).
                      • 0
                        Нет. «Пустые» папки для кеша должны иметь файл .gitignore, чтобы игнорировать эти самые файлы кеша. Таким образом эти папки вовсе не пустые.
                        • 0
                          С кэшем вы правы. Согласен.
                    • 0
                      Нет. «Пустые» папки для кеша должны иметь файл .gitignore, чтобы игнорировать эти самые файлы кеша. Таким образом эти папки вовсе не пустые.
                  • +1
                    У вас один стиль, у нас другой. Вы сторонник восходящего проектирования, когда сущности создаются по мере необходимости, я — сторонник нисходящего, когда сначала формируется скелет, который потом обрастает мясом.

                    И то, и другое — хорошие, жизнеспособные подходы, но только один из них поддерживается Git-ом, а другой — нет. Если вы никогда не будете использовать нисходящий подход, то, возможно, вы никогда и не заметите этого ограничения. Но ведь есть и сторонники других подходов, не так ли? А такая штука как система контроля версий должна подразумевать определенную долю универсальности.
                    • 0
                      Вы путаете. Восходящее проектирование или нисходящее — это никак не влияет на то, что организационные задачи должны решаться организационными методами.

                      Создавайте скелет — в спецификации. Потом он будет обрастать мясом, одновременно будут создаваться папки.
                      • 0
                        Полагаю, что организационные задачи очень даже могут решаться техническими методами, но это должно быть именно решение, а не имитация. Т.е. если в определенную папку можно класть только css, а в другие папки css класть нельзя, то техническое решение должно это обеспечивать при любых действиях пользователя, включая человекопонятные сообщения об ошибках.
                        • 0
                          >то техническое решение должно это обеспечивать при любых действиях пользователя, включая человекопонятные сообщения об ошибках.

                          Да, но какое это имеет отношение к пустым папкам?
                        • +1
                          Да, но зачем усложнять?

                          Если, например, в проекте предполагается вынесение статики на отдельный сервер, то логично сосредоточение всех данных в одном месте. Например:

                          static_files
                          ... css
                          ... images
                          ... ... uploads
                          ... js
                          ... ... 3rd_party


                          При этом любому адекватному разработчику будет уже и так понятно, что CSS файл надо положить в static_files/css, а неадекватных мы тут не держим.
                          • 0
                            Давайте заканчивать с пустыми папками. Воспринимайте это как данность. Никто еще не умер от этого.
                            Пустые папки создаются только один раз при разворачивании проекта. А если вы это регулярно делаете, тогда это вопрос организации сборки и деплоя.
                  • 0
                    «рыться в куче существующих» — это тяжкое наследие консоли, которая как правило не показывает в наглядной и обозримой форме дерево каталогов.

                    Одного взгляда на дерево нормально названных каталогов достаточно для того, чтоб понять что куда надо класть.

                    Самодокументированный код, интерфейс, структура — это ХОРОШО.
            • +1
              Возмущение понятно, только вы пре-перфекционист. Даже если вам это сильно нужно. Вы все равно с коммандой договариваетесь голосом, а не созданием папок. Нарисуйте эту структуру на листике, как памятку.

              В обычном кейсе, если папка пустая (напр. logs), то в нее что-то будет писаться. Значит должны быть права на запись. Значит можно включить в скрипт инициализации проекта (напр. phing) выставление нужных прав, а заодно и ее создание.
    • 0
      Это исключительно от того, что не до конца разобрались.

      >в Git-е нельзя создать пустую папку

      И не нужно. Правда-правда. Если пустая папка нужна для того, чтобы туда клались данные, то в этой папке должен быть файл .gitignore, и такая папка будет уже не пустой.

      >А дельше надо передать проект своему напарнику. И тут выяснятся, что сделать этого напрямую мы не можем.

      Можете, конечно. Точно так же, как и с центральным сервером. p2p обмен _ничем_ не отличается от обмена с центральным сервером. Собственно, даже понятия такого — «центральный сервер» — в Git'e нету.
      • 0
        > Если пустая папка нужна для того, чтобы туда клались данные, то в этой папке должен быть файл .gitignore, и такая папка будет уже не пустой.
        После такой рекомендации глупо ругаться на SVN, который «засирает» каждую папку подпапкой .svn — здесь все получается еще хуже и не системно.
        А если кто-то на радостях что-то напишет в этот файл .gitignore? И получится, что в одних папках одни файлы игнорятся, в других — другие. Вобщем место для потенциальной путаницы и гемора.
        • 0
          Runtime данные всегда должны быть заигнорены. Или вам нравится, например, копаться в git status на 3 экрана, где 99% — файлы логов?
          Как говорилось в статье, это git-way. Да, вы можете создать глобальный .gitignore, но так не делается (по крайней мере я в последний раз такое видел только в svn-репозиториях).
        • +1
          Наоборот, все правильно сделано. Не должно в проекте быть пустых папок. Они не нужны.

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

          Если же задача папки хранить некие генерируемые в процессе работы файлы, то они должны быть именно явно выключены из упраления репозиторием, путем создания файла .gitignore. Соответственно, папка опять же будет не пуста.

          >А если кто-то на радостях что-то напишет в этот файл .gitignore?

          Не понял. А если кто-то на радостях что-то напишет в исходнике? Опять же, если кто-то накосячил — на то и система контроля версий, всегда можно откатиться.
          • 0
            По поводу пыстых папок обозначился выше.
    • +1
      простое управление ветками — это не создание/удаление, а в первую очередь мерж. например в svn не мерж, а гавно.
      если хочется без сервера, то вот
    • +4
      > Какое-то последнее время нездоровое количество визга по поводу…

      Ну не знаю, почему я должен читать дальше этого предложения, если у автора на лицо неуважение к чужому мнению?

      С какой вероятностью точка зрения такого человека будет хоть чуть-чуть объективной и взвешенной? Да с нулевой. Ведь для этого надо внимательно слушать и серъезно обдумывать мнения других, а не считать их голоса «визгом».

      • +2
        у автора на лицо неуважение к чужому мнению
        тем не менее, Git'у уделяется гораздо больше внимания, чем он того заслуживает
    • +2
      Ваше приложение не будет работать, если нужной ему папки нет?
      Может оно само ее создаст? Так удобнее!

      Пустые папки и код приложения вообще никак не связанны. Сокеты и пайпы тоже коммитать было бы хорошо…
  • +3
    Спасибо за bisect — знал, что что-то такое есть, но не знал как называется (не было острой необходимости). По теме: буквально пару месяцев как начал пользоваться git-ом и весьма доволен, хотя все-таки думаю еще познакомится с конкурентами =)
  • 0
    Скажите пожалуйста (гугл не помог), есть ли в git аналог hg serve? Или какой-нибудь простой браузер репозитория, запускаемый, например как
    $ gitweb -d /home/repos/myproj -p 1081
    а не
    # rc-service apache start
    • 0
      • +1
        Это не простой браузер репозитория, это простой скрипт, запускающий сложный браузер, требующий apache.
        • 0
          там есть варианты. например, если у вас установлен ruby то устанавливаете --httpd=webrick и всё. Это тоже веб сервер, но он минимален и включён с стандартную библиотеку ruby.
  • 0
    Спасибо — все собирался познакомиться с гитом поближе, теперь точно попробую.
    • +1
      Это не так сложно, как кажется. Мне на первое время вполне хватало трех команд, комитить, переключаться в ветки и сливать ветки. Рекомендую читать Магию Git. Она как сборник рецептов написана. Потом захочется узнать, а как же git устроен изнутри, и уже можно будет углубиться в Pro Git Book
  • +6
    Создать репозитарий в текущей директории — «git init». Все.

    Создание репы не сильно сложная процедура
    svnadmin create там тоже ведь не сложно?

    Всего одна папочка .git и никакой порнографии ввиде .svn в каждой директории.

    Не понимаю проблемы порнографией, если конечно делается svn export

    Интернет не нужен.

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

    Удалить коммит, как будто его и не было

    А как быть, если ошибочно?

    Я на самом деле почитал и не понял для себя преимуществ по сравнению с SVN. Я работаю с двумя программистами над одним проектом, всё лежит на сервере разработки, svn на сервере бэкапится. Вот чем для меня может быть полезнее git? Прочитал, явных преимуществ не нашел, они наверное есть, но если можно, то кратенько поясните их на примере проекта, где есть сервер и нет проблем с интернетом :)
    • –3
      Пока не начнете пользоваться — не поймете.
      • +2
        А для чего тогда статья?
      • +2
        Да пользовался, ничего хорошего не нашел. По мне так всю это возню вокруг git/svn затевают те, кто не пользовался никогда svn на полную мощность. Про другие системы, в том числе чисто блокирующие я вообще молчу.
        Думал как-то написать про тот же svn, но смысл? Когда пишут, что "чудом git-а после svn-а для меня были ветки", то уже доказывать им что-то бесполезно.
        • +1
          те, кто не пользовался никогда svn на полную мощность
          возьмите ноут в поезд и попробуйте svn log через GPRS.
          Когда пишут, что «чудом git-а после svn-а для меня были ветки», то уже доказывать им что-то бесполезно.
          Ветки в hg/git и svn — две разные вещи. В svn это всего лишь соглашение о параметрах svn copy, в hg/git — нормальное полноценное треканье истории без использования костылей вроде svn:mergeinfo или как там его. Впрочем, вы всё равно попробуйте написать про svn — будет интересно.
        • 0
          да-да, подбадривайте себя, использователь свн на полную мощность. в свн-то и веток толком нет, так, версионированные папки. после получасовых мержей или десятиминутных свитчей любому ветки в dvcs покажутся чудом.
    • +1
      Меня вот .svn в каждой папке напрягает. С git-ом — удалил одну папку и никаких следов того, что тут был репозиторий. Хотя это дело вкуса и преимуществом это не назовешь.

      А как быть, если ошибочно?

      Не знаю, что именно имел в виду автор, но после отката последнего коммита и даже после сурового 'rebase -i' (который позволяет переставить, объединить, отредактировать и даже удалить любое количество коммитов) можно без проблем вернутся в исходное состояние. В доках по этому поводу написано, что очень трудно заставить git безвозвратно удалить то, что вы однажды закоммитили.

      Пожалуй самым большим «чудом» git-а после svn-а для меня были ветки. Они с поразительной легкостью позволяют вам работать сразу в нескольких направлениях, не боясь «поломать» master (trunk для SVN). А если идея, реализуемая в отдельной ветке, не оправдала ваши ожидания, то вы удаляете ветку и никто и никогда не узнает, что ваша блестящая идея потерпела фиаско. И главное эта неудача никак не скажется на остальном ходе разработки.

      И даже если нет проблем с интернетом, «локальнось» git-a — вещь приятная. Вы можете у себя в репозитории сделать последовательность коммитов (возможно не за один день), убедится, что все хорошо (если нет — пофиксить все, что надо, отредактировать коммиты при необходимости), и только когда это все обретет презентабельный вид — опубликовать в основном репозитории.

      Пока не было возможности сравнить git с другими DVCS, но по сравнению с SVN-ом он действительно великолепен.
      • 0
        В доках по этому поводу написано, что очень трудно заставить git безвозвратно удалить то, что вы однажды закоммитили.


        Ну это логично, меня поэтому и смутила фаза «как будто его и не было».

        • 0
          Коммит исчезает из истории, но в репозитории он сохраниться (удаляется он при вызове git gc да и то не всегда). Этакая корзина в общем.
      • 0
        Меня вот .svn в каждой папке напрягает.

        Они уже отказываются от этого и переходят но новую систему хранения на базе sqlite
    • +1
      Да из-за скорости хотя бы. SVN __очень__ медленный по сравнению с git — во всех операциях.
      Да просто начните пользоваться, у git много плюсов, для каждого человека они свои )
    • 0
      >Вот чем для меня может быть полезнее git?
      У меня ситуация такая: несколько проектов лежат в репозитории. Проекты имеют общие файлы. В пятницу вечером я закинул файлы на ноутбук и уехал с ним на дачу. В одном из проектов я внес правки в те файлы, которые общие для всех проектов. В случае SVN мне надо добраться до основного репозитория, чтобы эти правки попали во все копии (ну либо ручками внести их в каждый проект).
      В случае же Git, насколько я понимаю, у меня с собой будет еще и локальная копия центрального репозитория и в нее я смогу внести свои правки и из нее обновить все свои проекты.
      • 0
        Да, именно так. У вас с собой полная копия репозитория, ну или как минимум выбранных веток.
    • +1
      Не понимаю проблемы порнографией, если конечно делается svn export

      Меня папки .svn раздражали тем, что fgrep находит ненужное, либо ищет медленно (если настроить чтобы в .svn не заходил).
      Плюс невозможно скопировать папку из другого svn проекта — нужно обязательно удалять все .svn папки
      • 0
        Плюс невозможно скопировать папку из другого svn проекта — нужно обязательно удалять все .svn папки


        svn export html/do/lib ../../for_vasya

        или вы о какой-то другой сложности?
        • +2
          Сложность в том что иногда хочется воспользоваться обычным файловым менеджером (просто F5 или перетащить мышкой), иногда копировать надо через сеть (а программа копирования не вкурсе ни про какие svn export), или отдать папку архиватору (и он тоже не вкурсе что .svn брать не надо). Всё это можно обойти, но лишний шаг всегда раздражает.
          • 0
            А еще разворачивание рабочей копии на сервере.

            Обычно у меня там тоже гит репозиторий,
            >> git pull origin release
            >> service apache2 restart

            В случае необходимости можно воспользоваться .git hooks
            Хорошо работает даже для сервера у которого вообще нет выхода в интернет.

            Приходишь, подключаешь рядом рабочий ноутбук, выдергиваешь за 4 секунды все изменения из проекта размером 50 мб прямо по сети…

            Стоит попробовать.
    • +1
      Создание репы не сильно сложная процедура
      svnadmin create там тоже ведь не сложно?


      Основная фишка в локальности. Допустим: появилась идея, надо набросать протоип. С svn: надо или дёргать админа, или поднимать сервер, или самому лезть на сервер создавать, в общем потом, когда сделаю. С git: git init, git commit, git commit, клас, работает, теперь можно и на центральный сервер закинуть, другим показать.

      Не понимаю проблемы порнографией, если конечно делается svn export

      пояснил

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


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

      А как быть, если ошибочно?

      пояснил

      Я на самом деле почитал и не понял для себя преимуществ по сравнению с SVN. Я работаю с двумя программистами над одним проектом, всё лежит на сервере разработки, svn на сервере бэкапится. Вот чем для меня может быть полезнее git? Прочитал, явных преимуществ не нашел, они наверное есть, но если можно, то кратенько поясните их на примере проекта, где есть сервер и нет проблем с интернетом :)

      • брэнчи — тут нужно немного перестроиться на другой принцип разработки, но если въехать — очень удобно
      • скорость — по крайне мере если репозиторий большой разница заметна
      • доступен всегда — (опять же если перестроиться в правильный режим) с гитом делать коммиты можно всегда, когда доступен компьютер (и делать их удобнее — нет медленных запросов в сеть), поэтому comit log получается существенно более читаемый
  • 0
    Спасибо за прекрасный топик! Только что вышел на достаточно стабильный релиз своей системы в SVN. Теперь коммиты идут намного реже, есть время задуматься о другой системе контроля версий. В из ваших слов git подкупает возможностью объединять коммиты (сто раз недокоммичивал забытые файлы) и возможностью коммитить в интерактивном режиме. Не могу сказать, что я знаю хорошо SVN, потому, быть может, это возможно и в ней.
    • 0
      Более того, можете коммитить сколько угодно у себя локально пока работаете над своей частью проекта. И уже когда всё сделали, можете запушить в «основной» репозиторий уже результат. Т.е. распределённая система контроля версий гораздо более удобна при большом числе разработчиков, каждый из которых занимается своей частью. У каждого есть своя история коммитов.
  • 0
    Спасибо за статью. Cheat-sheet вообще отличный!
  • +4
  • 0
    Насчет локального репозитория — а в чем проблема с SVN его использовать? Если над проектом работаешь один.
    Я лично так один проект веду.
    • 0
      Я тоже так раньше делал. Потом попробовал git с его магией бранчей (когда надоели потуги ветвления в svn) и svn стал прошлым днем. Даже несмотря на отсутствие внятного плагина для git под NetBeans. Теперь в git репозитариях у меня хранятся не только проекты, но и многие другие вещи, вплоть до скриптов администрирования, а кое-где даже /etc.
  • –3
    Если бы я использовал git для своего проекта, то уже недели две как сидел бы и писал его с нуля. От внезапного падения винта не так-то просто застраховаться… А svn выручил. (теперь мирроринг ещё дополнительно поставил)

    Собственно, это для меня самый важный минус git'а.
    • +4
      Это не минус git-а. Что Вам мешает push-ить свой git-репозиторий на какой-нибудь удаленный сервер?
      • –3
        А зачем всё разделять? Куда проще одной командой залить сразу на сервер.
        • +3
          Явно вы ничего не поняли в распределённых системах. На примере mercurial:
          $ hg ci
          и мы закоммитили локально. В случае чего мы можем очень быстро откатиться на старую версию и найти необходимый кусок.
          $ hg push
          и наша информация залита на дефолтовый удалённый сервер. Наши изменения сохранены от падения локального винта. При этом даже сервера не нужно запускать на удалённой машине. Всё может быть залито через ssh доступ, если таковой имеется. Единственное требование — на удалённой машине должен тоже быть установлен mercurial. Естественно, ssh не единственный способ пушить на удалённую машину.
          Если желаете, можете за'push'ить на любой другой сервер, указав при этом путь к нему и способ соединения.
        • 0
          А зачем всё разделять? Куда проще одной командой залить сразу на сервер.

          Логично. Просто вам скорее всего сервер и не нужен. Если вы работаете один и надо только бэкапить, то и бэкаптесь локально. А лучше пушайте на сервер время от времени, при этом и никакого другого бэкапа не нужно — ваш локальный репо и удаленный будут идентичны. Проблема svn в том что репо (который содержит всю историю) только один, и ему отдельный бэкап жизненно важен.

          Другая проблема коммитов сразу на сервер: собираешься коммитить немаленький рефакторинг, а тебе говорит — сначала upнись, upнешься, получишь конфликты и не сможешь закоммитить пока не починишь/протестируешь всё снова. В распределенной же — коммитишь своё без вопросов (автоматически создастся новая ветвь), а уж потом, когда есть желание и время, сливаешь с оригинальной веткой, тестируешь и заливаешь на сервер.
          • +1
            Опять же повторюсь, я это к тому, что топик в основном про преимущества быстрой локальной системы контроля версий.
        • 0
          Уболтали. Попробую. Если интегрируется с svn (на сервере только он есть), то даже попробую внедрить на работе.
          • 0
            GIT-репозиторий легко организуется в рабочей копии SVN, и не мешает её функционировать по-своему.

            Перед update/commit SVN-ом приводите GIT-ом рабочую копию в нужное состояние — и апдейтите, если хочется — делаете в GIT новую ветку по результатам, и комитите в SVN. Потом дальше работаете, локально раскладывая разные правки по разным веткам GIT-а.
    • 0
      ну свн репо же где-то лежал не на локальном винте, видимо? вот туда клон гит-репо и положил бы
    • +2
      Причем здесь git и svn? Урок вашей истории в том, что не надо всё держать на одном винте. Если бы svn сервер стоял локально, он бы тоже исчез. А удалённый git репозиторий остался бы нетронутым.
      • –3
        В топике говорится в основном о преимуществах локальных гит-репозиториев.
        • 0
          А они никуда не делись. Вы всегда работаете в локальном репозитории. Но и понимать, что нельзя держать всё в одном месте, тоже надо. Поэтому бэкапы или пушить в удалённый репозиторий. Пушить можно вручную, по крону, а можно автоматически после каждого коммита, тогда будет как-будто в svn. Выбор за вами.

          И я надеюсь вы понимаете, что вам крупно повезло, что вы потеряли свой винт, а не тот, на котором был svn-сервер. Пользовались бы гитом, было бы не важно какой винт ушёл, а вот с svn…
        • 0
          В mercurial можно просто даже сделать бэкап путём копирования папки .hg и файлов .hg* куда-то ещё прочь от своей машины. Думаю в git аналогично можно. Да и по идее каждый разработчик проекта своеобразный бэкап. Даже если «головной» сервер (именно в кавычках, т.к. его приняли таковым, а не является им как в svn или cvs) потеряется у каждого разработчика всегда есть более или менее свежая версия проекта и общими усилиями можно вполне собрать то, что было до падения сервера.
  • 0
    Недавно начал пользоваться git'ом. Перешел на него с SVN. Очень активно пользуюсь ветками (branches) в своем проекте и пару раз выпадали непонятные ошибки при коммите\мерже, помогал только откат изменений и ввод их заново :( плюс очень не хватало такой фичи как «stash\unstash changes».

    Уже 3 месяца — полет нормальный, куча веток, куча коммитов, куча мержей. В общем доволен как слон! )
  • 0
    Кстати, на гитхабе есть сервис gist.github.com — как раз для публичного/приватного выкладывания одиночных файлов и фрагментов. Кроме всего, он переваривает разметку Markdown в нормально оформленный html. И комментарии можно оставлять.

    Это я к тому, что Ваш cheatsheet и руководство удобнее будет, наверное, туда переложить. (Благо каждый gist — сам себе репозиторий, с версиями и git clone и форками.)
    • 0
      на гитхабе есть и полноценная wiki. вот как раз там, ящитаю, мануалу с cheatsheetами самое место.
      • 0
        А с вики можно работать как с локальным файлом, редактируя её, скажем, в gedit?

        На мой вкус, основная плюшка gist именно в таком подходе.
  • 0
    Очень советую книгу Git Internals от PeepCode
    peepcode.com/products/git-internals-pdf
    по ссылке она продается за 9$, но я думаю, вы с этим справитесь )

    В отличии от других книг по Git, вначале рассказывается как он устроен а затем как им пользоваться.
    • 0
      Еще есть хороший цикл статей по «внутренностям» git'a
      los-t.livejournal.com/tag/git%20guts
      • 0
        О, спасибо, почитаем
  • 0
    А пустые папки можно коммитить в git? Или нельзя, как и в mercurial?
    Мне кажется, это единственный недостаток последней по сравнению с svn. Сам пользуюсь mercurial ввиду хорошей поддержки в windows. У git'а с этим пока проблемы.
    • +1
      Можно в папке создать пустой файл с именем ".gitignore" и она успешно закоммиттится.
      • +1
        почему именно такое имя? наверное, стоило написать, что достаточно вообще любого файла в этом каталоге?
        • 0
          Ну человек же пустую папку хочет создать.
          • 0
            И каким боком здесь файл, из которого git берёт маски для игнорирования? Почему именно .gitignore?
            • +1
              Мы создаем пустой файл с именем empty (естественно можно использовать любое имя). Но если подразумевается, что в папке будет контент, который не должен быть под контролем версий, то логично сразу создать .gitignore и прописать правила.
              • +1
                если подразумевается, что в папке будет контент, который не должен быть под контролем версий
                а, ну тогда да, интересный трюк. Я просто привык все маски прописывать в .*ignore в корне репозитория.
    • +1
      ИМХО, Windows вообще плохо приспособлена для систем контроля версий. Разве что там есть типовые для него TortoiseXXX проекты. Но установка самого клиента/сервера не очень то приятное занятие, но и не очень сложное.
      А Git на сколько я помню детище Линуса, т.е. изначально было ориентировано на пользователей *nix систем. Не удивительно что писатели под Windows особо на неё внимание не обращали.
  • +7
    У статьи есть два существенных недостатка:
    1. Как достоинства Git преподносятся достоинства DVCS в целом.
    2. Альтернативы среди распределенных систем не рассматриваются.
    Например, под Windows git по удобству уступает mercurial, а google-code, которая его поддерживает вряд ли чем-то хуже git-hub.
    • +2
      С пунктом 2 не согласен:
      GoogleCode в 3 раза менее функционален/удобен Bitbucket`а, который в 2 раза менее функциональнее/удобнее Github`а.

      Мне, как пользователю hg, завидно только наличие у git`а такой плюшки, как GitHub.
      • 0
        umputun вон с radio-t прикупил какой-то домен типа hg-hub. У него такая же идея возникла. Ну думаю в его силах реально подобное поднять.
      • +1
        А вот это сравнение (googleCode vs Bitbucket vs Github) хотелось бы увидеть в подробностях. В идеале — отдельной статьей. Про сами системы материала хватает, а про их поддержку в сети все куда лаконичнее.
      • 0
        Если будет не сложно, напишите несколько серьезных отличий Google Code (с Mercurial) от Githab'а в плане функциональности.

        Просто я только Google Code использовал, и интересное какие «плюшки» есть у github (ну кроме, конечно-же, git)

  • +1
    Как то упущены следующие моменты:
    — Ограничение доступа пользователям частью репозитория (в случае огромного проекта)
    — Работа над несколькими проектами с общими компонентами
    — Разграничение прав доступа к частям проекта

    Ну и возможность редактирования истории — настолько страшная вещь, что должна быть немедленно отобрана у всех, кроме одного-двух администраторов центрального репозитория. Об этом тоже ни слова.
    • +1
      > Ну и возможность редактирования истории — настолько страшная вещь, что должна быть немедленно отобрана у всех,

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

      А вот если править историю на общем репозитории, то, гит так устроен, что каждый девелопер вынужденно об этом узнает (перестанет работать push/pull) и легко найдёт правку просто сравнив свою локальную историю с общей.

      Так что всё ок: «закладка» не пролезет, новичёк не испортит историю.
    • 0
      Про ограничение доступа:
      Почитайте эту статью: habrahabr.ru/blogs/Git/75990/
      Там автор использует 2 репозитария: 1 — PROD-репо, с ограниченным доступом и второй — песочница для разработчиков.

      > Работа над несколькими проектами с общими компонентами
      см. git help submodule
      В проект можно подключить другие репозитарии как субмодули. Т.е. каждый компонент выделяете в отдельный репозитарий, и подключаете в любых проектах.
      • 0
        а можно не весь репозиторий подключать а лишь отдельную папку из него, как в свн? а лучше — отдельный файл
        • 0
          нет
          • 0
            как тогда быть в такой ситуации:

            есть несколько проектов использующих модули (модуль = директория). есть библиотека общих модулей.

            на свн-е мы делали так: с помощью svn:externals подключали конкретные модули. всё хорошо, но тормозит по страшному. поэтому сделали подключение всей библиотеки в сторонке, а в проекте модули подключали симлинками. но комитить симлинки — это кривой костыль, который к тому же не работает в винде.

            • 0
              ну, разложите эти библиотеки их по каталогам. по мере развития внешних либ сами спасибо скажете
              • 0
                библиотека постоянно обновляется отдельными людьми. довольно часто. хочется, чтобы можно было просто апнуться, протестировать и выкатить. желательно, чтобы можно было тут же пофиксить багу и запулить в библиотеку
                • 0
                  Git-way: один модуль — один репозиторий. Можно конечно объедить группу репозиториев в суперрепозиторий, но обновляться будет не совсем удобно. Не пробовал.
                  Или положите все в один репозиторий и подключайте ко всем проектам. Я надеюсь ваше приложение позволяет хранить модули, которые не используются.
                  • 0
                    не позволяет, модули вгружаются автоматически
                • 0
                  Разложите библиотеки по отдельным репозиториям.
                  В проекты, в которых они нужны, просто вставьте их как submodule.
                  Должно работать, плюс submodule привязывается не к репозиторию, а к отдельному коммиту. Т.е. возможна такая ситуация:
                   Lib       Project1    Project2
                   v1          |              v1
                   v2 <--------v1             |
                   v3 <-----------------------v2
                   v4
                  

                  Когда вы правите библиотеку, не нужно проверять что сломалось, а что нет во всех проектах, которые использую её. Они привязаны к уже проверенным коммитам. А когда будет время можно любой проект перепривязать на свежую версию и тщательно протестить.
                  • 0
                    Спасибо за «лайфхак» :)
                  • 0
                    это типа как в свн привязываться к конкретной ревизии? не, это не удобно — всё-время нужно править привязку вручную. лучше чтобы можно было зайти в модуль, сказать «дай мне свежую версию» и пойти тестировать. или даже зайти в проект и сказать «подтяни-ка свежие версии зависимостей»
                    • 0
                      Не знаю, как в svn привязывается к ревизии, но в гите всё примерно так, как надо:

                      Заходишь в submodule а там как в обычном репозитории:
                      git fetch; git checkout master|branch|tag|revision или git pull
                      а потом если выйти в родителя, то git diff покажет, что этот сабмодуль перепривязался к новому комиту, а git commit сохранит новую привязку.

                      Сразу для всех что-то делать можно через git submodule foreach.

                      Кроме того, чтобы что-то поправить в библиотеке, не надо отдельно её клонировать, править можно прямо в сабмодуле. Там же можно изменения закоммитить и запушить на сервер. А затем закоммитьи и запушить новую привязку в родителе. (только не наоборот!:)
                      • 0
                        а если наоборот? а то я сейчас поигрался с сабмодулями, так огрёб какие-то странные конфликты и ругань гитхаба. но сейчас уже всё разрулил.

                        ещё интересная фича: можно создать репозиторий внутри репозитория х) тогда можно будет делать так сказать «проектные патчи», то есть изменённые в модуле файлы будут коммититься и в модуле и в проекте.
                        получается так: заходим в модуль, пуллим его, примерживая изменения, тестируем, коммитим проеект. если подредактировали модуль под себя, то для модуля это будут просто локальные изменения, а в проекте их можно и закоммитить.
                        • 0
                          > а если наоборот?

                          При работе с сабмодулями есть несколько «как не надо делать», о которых надо знать. Это один из таких моментов. О других можно почитать здесь: book.git-scm.com/5_submodules.html
  • 0
    уломал, ок :)
  • +6
    Максим, вы пробовали пользоваться другими DVCS? Дело в том, что Git — далеко не лучший представитель этого семейства (и, кажется, именно поэтому 95% статей про Git для неофитов сравнивают его именно с svn, которую (как тот же IE) не пинал только ленивый).
    В Git можно делать с коммитами и историей все что угодно
    за использование — оторвать руки по колени. думать нужно, прежде чем коммититься.
    Да, пару раз я терял коммиты из-за своих неопытных манипуляций
    а я, помнится, через пару часов использования git сломал нафиг и локальный, и remote репозиторий на github.
    Мучался с ребятами 2 недели
    Я смог практически полноценно работать с mercurial через часа полтора (впрочем, я точно не помню, поэтому пусть будет день), имея из доков под рукой 1 (один) cheatsheet и hg help. Справедливости ради отмечу, что до этого я где-то месяца 4 воевал с git (возможно, опыт общения с DVCS повлиял на скорость освоения). Нет, счёт был далеко не в мою пользу.
    • 0
      > вы пробовали пользоваться другими DVCS
      Нет не довелось, а на экперименты у меня нет возможностей. Хотя, раз пошла такая пьянка, подниму небольшой проектик на чем-нибудь еще. Но git меня устраивает дальше некуда.

      > за использование — оторвать руки по колени. думать нужно, прежде чем коммититься.
      Нет, думать нужно прежде чем пушиться. А со своими локальными правками, которых еще никто не видел, я буду делать все, что захочу.

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

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

      > которую не пинал только ленивый
      И буду пинать — до черта людей дальше SVN не видят.

      > где-то месяца 4 воевал с git
      А я не воевал, а радовался во всю. В чем подвох?

      > Git — далеко не лучший представитель этого семейства
      А почему бы не написать свой обзор? Я бы почитал с удовольствием.
      • +3
        > А я не воевал, а радовался во всю. В чем подвох?

        Вы попробовали git после svn, а develop7 после hg. Ни у hg ни у git-а нет таких сильных преимуществ перед друг-другом, как, например, перед svn, но внутренности достаточно разные. И эта разница диктует немного разный workflow.

        Поэтому, обычно получается такая ситуация: программист после svn пробует или git или hg, радуется удивляется новым возможностям и сильно изменяет свой workflow под выбранный DVCS. Он видит, что усилия потраченные на это действие потом окупятся.

        Потом программист пробует конкурирующий DCVS, но там крутых плюсов нет, поэтому нет и особой радости, и workflow меняется через немогу (зачем что-то менять, если выгоды не видно?). Программист пытается делать по старому, и натыкается на проблемы, а плюсы не находит потому, что плюсы проявляются в другом, родном для этой системы, workflow. В итоге программист всегда видит у конкурента больше минусов чем плюсов не зависимо от того, с какой DCVS начал ;)

        Вот так и получается, что одни ищут легкий hg serve, а другие легкие бранчи и плюются на местные аналоги.
        • 0
          Вы попробовали git после svn, а develop7 после hg.
          поправочка — ДО hg.
          • +1
            А затем на hg я и перебрался окончательно. И пересадил коллег. И обучил. И доволен, как слон. И ненавижу Линуса именно за Git.
            • 0
              Ок. :) Тогда моя теория в вашем случае ошиблась :)
      • 0
        Нет, думать нужно прежде чем пушиться.
        А. Ну в принципе ок, согласен. Тем не менее, за 1¾ года пользования DVCS мне понадобилось переписывать историю один раз
        Нет не довелось
        Попробуй :) Например, так или так. Как неоднократно замечали выше, 90% преимуществ Git относится к любой DVCS вообще.
        Подскажи рецепт, любопытно.
        Да фиг знает, на самом деле. Я тогда git только в глаза увидел. Вроде как по шпаргалке работал, ничего криминального — однако сломал. Штатными средствами. Что, на мой взгляд, символизирует.
        Мы еще тогда начали работать через систему форков и пул-реквестов на гитхабе.
        А я помню, кстати :)
        до черта людей дальше SVN не видят.
        ну, в принципе, да. C другой стороны, не стоит говорить об svn так, будто это что-то плохое.
        В чем подвох?
        Ну, я думал, что мне удастся освоить git так же быстро, как svn сотоварищи — мимоходом, параллельно с кодингом. Однако оказалось, что на мои «зачем»/«почему»/«а как лучше» отвечать просто некому. Даже насяльника, который, собссно и пересадил фирму на git, ничего внятного сказать не мог. И да, работать нужно было уже сейчас.
        А почему бы не написать свой обзор?
        Да обозревать собственно нечего. Выбираем cheatsheet из четырёх нижних и работаем. А топик «Git vs Hg» будет очевидно однобок, т.к. я Git использую на 20% в лучшем случае. А если нужно всерьёз работать с репозиторием — есть Hg-Git.
        • 0
          > А топик «Git vs Hg» будет очевидно однобок
          А ты все равно напиши с соответствующим дисклеймером. По крайней мере я смогу оценить его с точки зрения Git и оценить его (git) слабые стороны.
          • +1
            Уговорил :) Напишу.
  • +2
    Давно уже хочу попробовать Git. Скажите, а как он обращается с бинарными файлами? Я работаю с проектами, в которых используется огромное количество графики. Про SVN я знаю, что она умеет работать с дельтами бинарных файлов (CVS, не к ночи будь помянут, для каждого изменения бинарного файла сохранял его полностью). А вот как с этим делом в Git'e?
    • +2
      В Git нету дельт но есть сжатие. Это обусловлено тем что история нелинейна и дельты очень неудобны в таком случае.
    • 0
      У меня есть аналогичный проект, занимает 100М. Git репозитарий со всей историей занимает не на много больше.
      • 0
        Насколько я знаю, git (как и другая DVCS) не работают с дельтами бинарников. Если в репе есть 100МБ бинарник, то любое его изменение будет добавлять 100МБ к размеру репозитория.

        Буду рад если вы опровергнете экспериментом.
        • 0
          Я тоже слышал аналогичные вещи. Надо будет просто поставить эксперимент — взять проект, загнать в Git, сделать несколько коммитов и посмотреть, что получится. Если руки дойдут и сделаю — непременно напишу.
      • 0
        Звучит, конечно, обнадеживающе. 100М, правда, не так уж много. Проект, с которым я работаю сейчас, занимает полностью, я думаю, порядка 10G, и процентов 90 от этого — разнообразная графика.
        • 0
          если она постоянно меняется, то я бы не обнадёживался — будут храниться все версии
          • 0
            Там все по-разному — какие-то картинки изменяются часто, какие-то — почти никогда… В общем, буду ставить опыт :)
            • +1
              ну, не изменившиеся картинки не будут дублироваться, даже если их переместить или переименовать…
  • 0
    Если не сложно, кто-то может рассказать есть ли в GIT возможность форсированного авто-апдейта в какой-то ветке/клоне после пуша в «родительскую»?

    В Mercurial что-то подобное можно сделать с помощью хука, которые после пуша удаленно выполняет hg update у «дочерных» веток.

    Если интересует зачем, то тут очень просто: хотелось бы повторить фичу такой специфической системы контроля версий, как AccuRev — «streams»(потоки)

    Грубо говоря есть:
    RC ══ HotFix ─HFWorkspace1
     ║      ├─────HFWorkspace2
     ║      └─────HFWorkspace3
     ╚════ Development────WS1
                ├─────────WS2
                └─────────WS3

    (двойной линией я пометил те места, где нужен автоматический апдейт при апдейте парента)
    use-case: нашли баг, пофиксили в HFWorkspace1, «пушнули» его в hotfix, проверили, запушили в RC, и после этого хотелось бы, чтоб автоматически Development апдейтнулся с RC.

    Конечно в таком примере можно и в ручную, но если огромный распределенный (георграфически) проект, есть много комманд, есть много уровней иерархии возникает проблема в автоматизации work-flow изменений.

    В AccuRev это реализовано «нативно» под названием «streams» («потоки»), но очень бы хотелось найти хороший аналог в GIT/Mercurial/…

    Спасибо заранее, если кто подскажет.
    • 0
      Выше давали ссылку на git-flow :) Подойдёт?
      • 0
        Честно говоря немного затрудняюсь даже ответить…

        Прочитал Vincent Driessen's branching model — действительно что-то похожее, но про автоматический апдейт child-branch-ей разве что "… so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master."

        Кроме того, там структура хоть и похожая, но мало описана ситуация, когда несколько веток, подобных develop/master. Да и feature-* бранчи как-бы независимы до финального мержа.

        Основная идея «stream»-ов в AccuRev — это то, что построив правильную иерархию flow-а, изменения автоматически расходятся по этим потокам как только они попадают на уровень, выше от того, с которым работаешь.

        Т.е. если ченж, сделанный одной коммандой попадает в hotfix, то при выполнении update из любой ветки (потока), идущего из hotfix на любом уровне вложенности, эти изменения попробуют «влиться» в текущий workspace (и при наличии конфликта будет «deep overlap»).

        Еще примерчик, может более показательный:
          Hotfix═══HotfixRU─────────DevTeam1─≡ developers
             ║           └──────────DevTeam2─≡ developers
             ╠═════HotfixUA─────────DevTeam3─≡ developers
             ║           └──────────DevTeam4─≡ developers
             ╚═════HotfixUSA────────DevTeam5─≡ developers
                      ╠══HotfixUSA1─DevTeam6─≡ developers
                      ║          └──DevTeam7─≡ developers
                      ╚══HotfixUSA2─DevTeam8─≡ developers

        Если команда девелоперов №8, находящаяся в штате2 в США решит что их код готов пойти на хотфикс, они «пушают» в HotfixUSA2 (локально находящийся у них в штате) и сама система протолкнет в глобальный для США HotfixUSA дальше выше, а от туда уже попадет на все Hotfix* не важно где географически находятся копии.

        После этого любой девелопер при update своего workspace с ближайшего Hotfix* получит изменения.

        Возможно я пока слишком мало информации нашел, но как такое реализовать с помощью git-flow я пока не нашел. Если такое можно, то можно ссылочку на какой-то вменяемый мануал/howto.
        • 0
          Я так понимаю, все это у вас отдельные репозитории, а не ветки?
          Тогда я не думаю, что это возможно сделать встроенными средствами. Общаться между репами, это к админам.
          Такое, как вы заметили, легко делается хуками в меркуриале. Только почему вас смущает это решение? Хуки, это не костыли, а вполне полезные приспособления.

          А вообще, странный у вас воркфлов, вот и все )
          • 0
            Ну, я надеялся, кто-то это уже сделал и не надо изобретать велосипед. Пока все что я нашел, это одно предложение из FAQ по меркуриалу. Но работа с хуками довольно сильно усложняется когда
            а) есть возможность недоступности одного из серверов, на которых лежит репозитарий (ветка/клон/stream).
            б) разные ОС на «перевалочных» станциях (типа HotfixUA — Windows, Hotfix — Linux) :)

            А чем же странный? Довольно сложный — да, но обусловлен тем, что есть несколько команд разбросанных географически, распределенная система контроля версий и работа идет над одним проектом одновременно (т.е. все разработчики должны иметь максимально up-to-date состояние системы). Действительно иногда при отслеживании base возникают сложности — те же упомянутые deep overlapы, underlapы и прочие злые «лапы», но пока я не вижу разумной альтернативы.

            Разве что действительно пытаться организовать систему хуков с поддержкой fail-over.

            Просто такой workflow предполагается AccuRev, c которым уже работаем, но в целом заинтересованны в том, чтоб попробовать другую VCS (так, как количество команд растет, а цены у AccuRev довольно кусючие).
  • +1
    Подборка cheat sheet по git devcheatsheet.com/tag/git/
    И еще один zrusin.blogspot.com/2007/09/git-cheat-sheet.html
  • 0
    Если репозитории локальны, то как происходит их синхронизация? Нужен сервер с главным репозиторием?
    • 0
      Можно p2p, можно с сервером. Как вам будет удобнее.
    • 0
      Любой репозиторий может вытянуть все обновления с любого другого.
      • 0
        Даже если этот другой за NAT? В файлообменниках я, сидя за нат, могу качать с тех кто с белым IP, и они с меня также. С меня сможет коллега выкачать репозиторий, если у него есть белый ip, а у меня нет?
        • 0
          «а вдруг у другого компьютер будет выключен?» зачем себе лишние проблемы выдумывать? есть git/hg bundle и еще десяток способов обменяться коммитами. лучше всего, конечно, общий репозиторий
          • 0
            Это не выдуманные проблемы, а реальная ситуация.

            Всё-таки приходим к ттму, что даже в распределенной системе, нужен центральный (мастер) узел?
            • 0
              откуда такой вывод? технически не нужен — каждый репозиторий самодостаточен, организационно — зависит от воркфлоу.
              • 0
                >откуда такой вывод?

                >лучше всего, конечно, общий репозиторий

                :)Технически-то понятно, что не нужен (за исключением особо редких случаев, типа все за нат), но ведь это не 'настоящий' p2p как если бы одна копия основного (не локального) репозитория была бы распределена на всех и в случае если интернет умрет у каждого будет последняя копия
                • +1
                  В отличие от p2p торрентового в репозах не может быть канонической финальной версии файла или проекта, которая гарантированно есть хотя бы у нескольких участников «роя».

                  Значит, все же желателен некий центральный узел обмена. В случае утери узла — все равно можно восстановиться из любого другого репоза, либо считать любой другой репоз центральным. В равнозначности такой гипотетической возможности для любого репоза и заключается распределенность DVCS.

                  Опять же, можно организовать кольцевую или древовидную схему схему обмена изменениями, но это просто-напросто не очень нужно, если верить моему опыту.
                  • 0
                    Спасибо за объяснения, кое что проясняется
        • 0
          Я не понял, о каких таких файлообменниках Вы говорите, если речь идет о скачивании с Вас, сидящего за натом.

          Если Вы за натом, то с Вас, конечно, скачать нельзя. Но это не проблема Git'а. Эта проблема возникнет и обычными файлами, и с торрентами, и с играми. С чем угодно, что требует обращения к Вам через нат.

          Но, даже если Вы за натом, все-равно есть возможность обменяться данными — просто сессию придется инициировать Вам, а не тому, кто хочет получить данные. В гите то же самое — просто Вы будете пушить обновления, а не с Вас будут пуллить.
          • 0
            Ну вот как-то раздаю за натом арч, генту и убунту :) На самом деле многие p2p сети допускают скачивание с человека сидящего за натом или просто с закрытыми портами. Как вы правильно сказали, в таком случае сессию инициирую я, личеры регятся на сервере, а я получаю с него их айпишники и инициирую сессию для своей раздачи (возможно ещё какие механизмы есть, например айпишники личеров мне скидывают другие личеры, но хоть один айпишник я должен получить с сервера, чтобы я мог к нему стукнуться и сообщить о готовности раздавать). Подобного механизма (не я закачиваю, а с меня скачивают, но сессию инициирую я) в гит нет?
            • 0
              Для такого механизма нужен сервер. Но если есть сервер, то все остальное уже не нужно, можно синхронизироваться по серверу.
  • +1
    Ну какие могут быть у Git конкуренты когда есть GitHub?
    Ничего подобного для других распределенных CVS я не видел…
    • +2
      • 0
        Не пользовался, выглядит неплохо, интерфейс напоминает гитхабовский. Но уверен, что количество популярных библиотек, лежащих там в разы меньше, и соответственно количество активных девелоперов также меньше. Про качество кода ничего сказать не могу.
        • 0
          Не совсем понятно, как связан размер хостинга репозитариев с качеством кода проектов, на нем находящихся :)

          Хостинг и хостинг, разве что раньше прочих объявился и стал поэтому образцовым.
          • 0
            Чем больше количество, тем больше вероятность присутствия качественного кода, если конечно распределение примерно одинаковое. Другое дело, что при таком количестве качественный сложнее найти.

            Хостинг хороший и раскрутился раньше других, поэтому популярный и образцовый, да.
            • 0
              Ваша задача, если я правильно понимаю, это разложиться на каком-либо хостинге со своим проектом, а не использовать все чужие либы оттуда :)
              • 0
                Для либ/gem-ов сейчас больше популярен Gemcutter. А собственно разработка своих/чужих, да на Github.
                • 0
                  Да пофиг :)

                  Bitbucket — тот же github для hg. От количества либ качество сервиса не становится хуже, к этому, собственно, и веду.

                  Хотя лично мне для непубличных проектов проще на своем серваке в gitosis докинуть новый репоз и не париться.
                  • 0
                    Моя мысль была в том, что Github очень популярный, тем самым продвигая Git в массы :)
                    • 0
                      Правильная мысль, я бы, наверное, ограничился чтение статей, чтобы иметь представление, если вдруг понадобится, но многие проекты хостятся с некоторых пор на гитхабе, а интегрировать гит с нашими свн не хочется, вот приходится с гит разбираться и, видимо, полностью на него переходить
    • 0
      code.google.com (Mercurial)
  • 0
    Если вам не нравится github, кстати, можно установить себе на сервер gitorious. Немного геморно устанавливать (где-то час в мануалах/консолях), но оно того стоит. система не так популярна и фичер-рич как github, но opensource и доступна для установки на своем сервере. Github говорят теперь тоже можна установить себе на сервер, правда это будет стоить капусты.
    • 0
      Даже как-то собирался написать статью по установке redmine и gitorious на сервере, но заглохло, ибо давно ставил и уже всего не вспомнить.
  • –2
    Простите, а репозитАрий — это что?
    • +1
      Это махровая безграмотность :)
      • 0
        Вообще, если в словарь не заглядывать, то «репозиторий» легко написать как «репозитарий», потому как есть «проверочное слово» — «депозитарий». Ещё интереснее, судя по грамота.ру, с кеш/кэш — в орфографическом словаре «кеш», а в Большом толковом — «кэш». «Хороша русская языка» — как хочешь, так пиши :)
        • 0
          Это просто привычка, это новые слова, произношение еще не устаканилось. ДепозиАрий, в общем-то, тоже следовало бы писать как депозитОрий, просто так уж сложилось, что пишут через А.
          • +1
            Ну единых правил заимствования нет, есть в лучшем случае традиции.

            P.S. По мне так пускай лучше пишут «репозитарий» и «депозиторий», чем «ньюанс» :(
  • +1
    >Это классная платформа, где можно бесплатно разместить и опубликовать свой репозиторий.

    Если не ошибаюсь, то бесплатно можно разместить только открытый код (до 300 Мб общим объёмом на аккаунт), за 7$ в месяц 5 закрытых репозиториев и 600Мб (да ещё трудности с оплатой, только кредиткой). Есть ли публичные бесплатные хостинги, где можно разместить закрытый код?

    Собственно гит «вынуждено» заинтересовал, потому что всё больше проектов, которые использую, хостятся на гитхаб и заниматься интеграцией их в свн не хочется (сейчас просто копирую файлы из локального клона гитхаб, котором сам никогда ничего не изменяю, в каталоги под управлением свн, игнорируя .git*, а дальше они уже свн управляются, но заморочно это, после каждого обновления надо каталоги очищать, копировать, добавлять/удалять в свн), а так бранчи/мержи фактически не используем, у меня свои каталоги, у дизайнера/верстальщика/js-кодера свои, коммитим только то, что пойдёт на боевой сервер (параллельных версий реализаций нет, «триальные» держим локально, показываем друг другу и заказчику сторонними способами — от почты до дев-сервера, если откинуты, то просто удаляются (или копируются куда-нибудь в «заначку»)
    • +2
      > 7$ в месяц 5 закрытых репозиториев и 600Мб (да ещё трудности с оплатой, только кредиткой)
      Я плачу 200 руб в мес и не напрягаюсь. Кредитка? Это разве проблема?
      Можно сделать по-другому: положить репо на публичный сервер и ходить к нему по SSH.

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

        да сутт нн в том как ходитт, а чтод для других будет открыт, далеео немвсем заказчикам это нравится

        команда два челлвека ) может и можно лучше но проблем пока нн испытываем один и ттт же файл два человека не будут редакттррвать из-за распределения обязанностей — я в браузерную часть нн лезу, он в серверную

        пс. сорри за ошибки — с маленькой экранной кавы пишу
    • 0
      Попробуйте unfuddle.com. Там есть возможность бесплатно создавать git-репозитории, но для бесплатного плана есть ряд ограничений
      • 0
        ПСасибо, вроде то, что нужно :)
  • +2
    Кто бы написал про проблемы git? Все у нас почему-то однобоко. Вышла новая технология, пару гиков написало «чуваки, это круто, я теперь бед не знаю!» и понеслось, саксесс стори одни, ну не бывает только плюсы, вот так жизнь устроена!
    • –1
      ну, мне тоже так кажется. вышла svn, пару гиков попробовали, круто говорят, атомарные коммиты какие-то и прочая дребедень и все побежали на нее. чего им на cvs не сиделось? а ведь у svn не только плюсы были
    • +1
      Знаменитейшие из минусов:

      а) некоторая неинтуитивность команд

      б) нельзя пустые директории закидывать

      в) когда-то было мало доков ибо творцам когда-то было некогда

      г) неудобно хранить большие бинарные файлы
      • 0
        вот спасибо
      • 0
        Я бы еще добавил неудобство работы с субмодулями, у которых тоже есть субмодули со своими субмодулями.
    • +1
      Ну, git перемещения файлов не хранит, а угадывает. Вероятность фейла, конечно, маловероятна, и добиваются этого с трудом, но лично мне это как-то очень непривычно. Ну и поэтому неспокойно.
  • 0
    А вот впечатления от использования популярных DVCS уважаемого ребе zabivatorа.
    • 0
      Вот именно, что впечатления. Жду полноценный обзор :)
  • +1
    а Джоел Спольски говорит, что лучшая open-source система контроля версий — это Mercurial :)
    • 0
      ссылка неправильная. Вот конкретно про Mercurial: http://hginit.com
      • 0
        Спасибо, про эту ссылку не знал :)
      • 0
        Говорит-говорит, в предпоследнем абзаце.

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