Почему 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 <команда>». Рекомендую не лениться и регулярно читать хелп для каждой новой команды, а потом еще читать и перечитывать. Так я узнал большинство возможностей, тонкостей и нюансов.
    Ну и пишите, если что не понятно. Мне очень трудно понять, какие очевидные для меня вещи, не понятны новичкам. За второй статьей дело не станет.

    Ссылки:
    Метки:
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 265
    • +8
      Зря вы так против gui. Есть команда git gui которая является простенькой надстройкой над консолью. Так вот эта git gui ползена новичкам, если не понятно, как сделать операцию в консоли. Можно не заниматься нудными поисками в гугле, а просто сделать операцию в графическом интерфейсе.
      Вот например, я все ещё не понял какой командой надо помечать файлы в которых я разрешил конфликты при мерже. И ничуть не страдаю от того, что приходится написать git gui и дотянуться до мыши. (Подскажите, если не сложно)
      • 0
        Черт, промахнулся. Ответил ниже.
        • 0
          > И ничуть не страдаю от того, что приходится написать git gui и дотянуться до мыши.
          Не ленитесь учиться. Я себя очень часто заставляю залезать в хелп или гуглить, чтобы понять как что-то работает.
          • +2
            Ещё есть удобный SmartGit.
          • +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'у
                    • +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
                          • +8
                            stash в меркуриале — shelve.
                              • 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
                                                                  Дык с этого же и начата ветка — рабочая копия НЕ ЯВЛЯЕТСЯ ПОЛНОЦЕННЫМ репозиторием: в неё пушить из другого репозитория нельзя без дополнительного танца с бубном!
                                                      • +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
                                                                                  Нет. «Пустые» папки для кеша должны иметь файл .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?

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

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

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

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

                                                                                  Пустые папки и код приложения вообще никак не связанны. Сокеты и пайпы тоже коммитать было бы хорошо…
                                                                              • +3
                                                                                Спасибо за bisect — знал, что что-то такое есть, но не знал как называется (не было острой необходимости). По теме: буквально пару месяцев как начал пользоваться git-ом и весьма доволен, хотя все-таки думаю еще познакомится с конкурентами =)
                                                                                • 0
                                                                                  Скажите пожалуйста (гугл не помог), есть ли в git аналог hg serve? Или какой-нибудь простой браузер репозитория, запускаемый, например как
                                                                                  $ gitweb -d /home/repos/myproj -p 1081
                                                                                  а не
                                                                                  # rc-service apache start
                                                                                    • +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…