Как стать автором
Обновить

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

А чем объясним взрывной рост git вначале 2010го?
Сказано ж, переименованием пакета git-core в git
Если я правильно понимаю графики, то на последнем графике суммарное количество. Там взрывной рост git начался чуть ранее, в начале 2009-го.
Как уже сказали GitHub — создан апрель 2008, набирает популярность — вот и одна из причин роста. Но именно взрывного роста я не вижу — в конце 2007 довольно резкий подъём, а потом быстрый рост. Но не взрывной — сказать, что наклон резко увеличился — трудно.
хороший толчек использования гит дал github
Не будем забывать, что у львиной доли пользователей popcon не установлен вообще, так что они в эту статистику просто не попадают.
в убунту, похоже, popcon по умолчанию стоит.
git — хипстерство какое-то в последнее время… Некотоые меня упрашивают перейти и сами не знают почему, агрументируют «все сейчас на него переходят».
попса
В данном случае на моду еще и причасность Линуса Торвальдса к Гиту сыгарала большую роль
Все хипсерство растворяется, когда объединяешь две дико рассинхронизированные ветки кода без единого конфликта, и забываешь svn как страшный сон.
У вас случайно нет ссылок на хорошие статьи по этому поводу? Программирование не является моей основной работой, и я только начал разбираться в системах управления версиями. Пока в git больше непонятного, чем понятного.
Спасибо.
А можно тут подробнее? Можете привести пример конфликта, который смог правильно смержить git, но с которым не справляется svn?
Просто постоянно слышу заявления про более простой мерж в git, но ни разу не видел подтверждния. Коллеги, которые активно двигают гит на работе, точно так же временами сидят и руками мержат файлы, произнося при этом нецензурные слова. И временами народ так же материться, выясняя кто в какую ветку пушился и почему в хеде нет его кода. Причем, последней проблемы — потерянные коммиты — на svn не наблюдалось.

Единственный достойный аргумент за git, который я слышал, — " если сервер прикажет долго жить, то у любого разработчика будет копия репозитария и мы без проблем развернемся".
Проблема не в инструментарии — сами инструменты для слияния не сильно отличаются, Проблема в подходах к использованию. У DVCS более частые коммиты и поэтому слияние происходит проще. В CVCS коммиты большие и редкие из опасения сломать чужой код.

stackoverflow.com/questions/2613525/what-makes-merging-in-dvcs-easy/2613595#2613595
Всё-таки хочется услышать что-то подобное от проповедников git. Ну или реальный пример более качественного мержа.

Считать, что одно техническое средство лучше другого, только потому, что вместе с первым применяются определенные административные меры — ну как-то неправильно, что ли.
Почитайте статьи на хабре:
habrahabr.ru/blogs/development_tools/108443/
habrahabr.ru/blogs/development_tools/108658/

А если по-простому, то mercuarial/git просто хранят больше информации в коммите чем svn, оттого атоматические объединение становится более осмысленным и возникает меньше конфликтов. Просто из опыта, на проекте с svn минимум раз в неделю натыкаешься на мерджи порой отбирающие до получаса-часа времени. Но после перехода на mercurial, на том же проекте, это просто исчезло.
>>Единственный достойный аргумент за git
Простите, но для трёх студентов, вечерами под пиво пишущих убийцу DOOM II, это вполне аргумент, для минимально серьёзной организации — никак нет.
За выдергивание цитат из контекста пора вводить расстрелянную статью!

Я писал, что это не единственный достойный аргумент в мире, а единственный достойный аргумент, который мне привелось услышать.
<irony>За неграмотно написанные комментарии пора вводить расстрельную статью!</irony>

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

Плюс — слово «единственный» было написано вами, мной приведено только для того, чтобы не рвать фразу, и вы сами же на неё и дернулись. Если вы ещё раз перечитаете мой комментарий то увидите, что про «единственный» я ничего и не говорю ;)
Да, за очепятки тоже нужно бить)) И за веру в автоисправление!

А вообще — я сам к этому аргументу очень иронично отношусь.
О, а давайте вместе устроим зондеркоманду! Будем всех расстреливать за опечатки, ошибки и выдернутые из контекста цитаты! А когда мир будет очищен от этих напастей, найдем опечатку и ошибку друг у друга и… =)

Жаль только то, что некоторые не утруждают себя прочитать всю ветку комментариев, но в профиль зайти им не лень.
вот вам еще один аргумент: если серевер не доступен (не обязательно «приказал долго жить», а например лежит или сети нет), то простой просмотр лога невозможен в svn. сужу по старыми версиям типа svn-1.4

кста, несовместимости между версиями svn тоже доставляли немало, это собственно было последней каплей для перехода на git.
Я рассматривал применение git (как и svn) внутри команды разработчиков, которая постоянно работает в офисе. Подключения из дома — редкость. В этом случае что смерть сервера с отсутствием бекапа, что его простой — повод хорошо поругаться с админами. Ну или следствие более глобальной бяки в офисной сети/инфраструктуре.
Про то, что git уделывает svn в случае распределенной команды я говорить не буду — тут и так всё ясно.

Про несовместимость версий — а есть ли у git за плечами такая история, что бы говорить, что они не ломают обратную совместимость? Хотя всё равно неплохой аргумент, положу в копилку.
> Я рассматривал применение git (как и svn) внутри команды разработчиков, которая постоянно работает в офисе.

при таких запросах вам по-видимому не нужна распределенная система, потому и аргументов для вас нет.

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

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

Я не говорю, что ломка обратно совместимости — это необходимость долгого развития. Просто обычно чаще её ломают или в самом начале, когда только обкатывают, в pre-alpha, либо в далёком будущем.
Аргумент — постоянные, блин, коммиты. На своём рабочем месте, без боязни сломать чужой код и необходимости мерджиться на каждый чих.

Это относится ко всем DVCS, не только к гиту.
Эм… а почему на SVN нельзя часто коммититься? У меня на сервере никогда не стояло ограничение на число коммитов в день/час/минуту.
И что значит без боязни сломать чужой код? Если я работая по git перепишу функцию с которой работает мой коллега, то сборка такого переписанного кода пройдет лучше, чем если бы я ровно те же изменения внес под svn?
Вы сидите в одной ветке, делаете коммит, продолжаете работать. Ваш коллега делает коммит, упс, нужно проадейтиться. Ок проадейтился, смерджил, закоммитил. Теперь уже вам нужно перед коммитом обновиться. Конечно вариант, на каждый чих заводить ветку, но если на одну задачу больше пары человек, то начинаются танцы.

В случае распределенных систем, вы работаете в своей песочнице: закончили, проапдейтились, смерджили, запушили.

Даже с DVCS можно иметь «центральный» репозиторий.
Ага, начались танцы с терминологией. Я как-то и для DVCS привык под словом коммит понимать push, т.е. проталкивание кода в «центральный» репозитарий. По сути мы имеем историю локальный изменений, но «выливание» кода в общий котел отложено максимально на потом.
Понятненько. Тут в целом согласен.

А в чем проблема на каждую задачу заводить отдельную ветку? Мы у себя именно так и планируем провести «реформу репозитариев». Т.е. мало того, что окончательно уйти на git, но и еще на каждую задачу в трекере заводить отдельную ветку. Чем это плохо?
Ни в чем, идеология абсолютно та же. Нужна фича, открываем ветку и в ней кодим. Когда готово — сливаем изменения в главную ветку. Просто в одной ветке может работать больше одного человека. Спольски развернуто объяснил hginit.com/00.html Главная идея в том, что DVCS поддерживает идеологию CVSC, но не наоборот.

Гит ещё более разухабистый, у него есть т.н. stash и staging area www.ndpsoftware.com/git-cheatsheet.html которых, порой, не хватает в mercurial. Нужна простота и лёгкая кроссплатформенность — Mercurial, нужны фичи, гитхаб — Git.
В hg есть mq (это к вопросу о stash).
но почему именно git? как будто в природе не существует других dvcs.
Именно git — не знаю, я лично пользуюсь mercurial. А git вроде обладает схожими возможностями.
извините, я почему-то ошибочно подумал, что вы тоже из этих.
с гитом есть свои проблемы
Ой, да ладно. Смержил без единого конфликта, а потом ищешь, кто же так уе… щно смерджил, что потерялись какие-то важные изменения. Спасибо, не надо.
ЗЫ пользую меркурилиал, автомердж использую крайне редко, и все равно проверяю дополнительно все, что он намержил перед комитом.
Дада. Mercurial — наше всё ;0
НЛО прилетело и опубликовало эту надпись здесь
Или даже просто рост инсталляций пакета popcon.
точно! количество исталляций popcon следовало бы нанести тоже
Хотели мы начать проект делать с git'ом, но по традиции решили всё таки заюзать svn. А перейти не решились потому, что никто раньше не работал с ним, боялись.

Есть ли хорошие материалы на русском по работе с git'ом? И было бы идеально, если бы кто-нибудь написал (или ткнул меня носом в) статью о том, чем же на практике отличаются git, svn и mercurial.
Могу посоветовать githowto.com/ и gittutor (стандартная обучалка в git).
На github есть перевод на достаточное количество языков github.com/progit/progit
Русскоязычная версия почти полная
Я перешел на git после того как увидел github
за счёт чего у гита такой взрывной рост? Вроде не видно резких падений
Я думаю, за счет гитхаба.
За счет переименования пакета git-core в git.
Смотри: svn рос, откусывая долю у cvs. Кого объедала git-core, а затем git? На графике не видно проседания у сегодняшнего лидера svn, всего-лишь остановившийся рост (ниша cvs исчерпана).

З.Ы. Я прочитал второй коммент на странице.
не знаю не знаю. сложный этот ваш гит.слишком много движений надо делать чтобы банально пушнуть в репу. в mercurial все в разы! проще. юзаю меркуриал с 2009. пробовал до этого гит, не прижилось.
> слишком много движений надо делать чтобы банально пушнуть в репу
git push

Или в mercuriale это все значительно проще?
git push /path/to/another/repo

Внимание, вопрос: где теперь искать те коммиты, что я пушнул? Знатоки гита обычно мне ничего сказать не могут, мануал тоже как-то отмалчивается. В меркуриале же всё очевидно.
в git reflog, конечно же. очевидно. </irony>
сравним:
git push -u origin master
и
hg push
Эээ. Я всегда делаю «git push». Что мне в гите реально не хватает — это hg update для того, чтобы на сервере автообновлялся код после коммитаю Обгуглился, но кроме грязного хака решения не нашёл =(
> чтобы на сервере автообновлялся код после коммита

Если честно не понял проблему. Что именно должно автообновлятся?
У меня есть сервер, на котором развёрнут проект и несколько разработчиков. Я хочу делать git push и чтобы клиенты сразу после этого получали обновлённый код. Для этого в репозитории необходимо сделать post-reseive хук типа «hg update». Вообще я читал совет сделать на сервере 2 репозитория — один просто хранит код, а второй — смотрит на клиентов, но это вообще криво.
это вы про:
hg pull
hg up?

в гите так нельзя?
Смотрите. У меня есть origin репозиторий, в который я делаю push. Т.е. pull там уже не нужно делать. В гите есть «git checkout HEAD», но работает он криво.
длинна команды не играет роли при использовании алиасов
Дуршлаг без дырок? Сами пробьёте, руки небось не отвалятся.
Я твой гит чейнджсет шатал
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.