Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 65
А чем объясним взрывной рост git вначале 2010го?
Не будем забывать, что у львиной доли пользователей popcon не установлен вообще, так что они в эту статистику просто не попадают.
git — хипстерство какое-то в последнее время… Некотоые меня упрашивают перейти и сами не знают почему, агрументируют «все сейчас на него переходят».
попса
В данном случае на моду еще и причасность Линуса Торвальдса к Гиту сыгарала большую роль
У вас случайно нет ссылок на хорошие статьи по этому поводу? Программирование не является моей основной работой, и я только начал разбираться в системах управления версиями. Пока в git больше непонятного, чем понятного.
Спасибо.
Спасибо.
Git Magic: www-cs-students.stanford.edu/~blynn/gitmagic/intl/ru/
А можно тут подробнее? Можете привести пример конфликта, который смог правильно смержить git, но с которым не справляется svn?
Просто постоянно слышу заявления про более простой мерж в git, но ни разу не видел подтверждния. Коллеги, которые активно двигают гит на работе, точно так же временами сидят и руками мержат файлы, произнося при этом нецензурные слова. И временами народ так же материться, выясняя кто в какую ветку пушился и почему в хеде нет его кода. Причем, последней проблемы — потерянные коммиты — на svn не наблюдалось.
Единственный достойный аргумент за git, который я слышал, — " если сервер прикажет долго жить, то у любого разработчика будет копия репозитария и мы без проблем развернемся".
Просто постоянно слышу заявления про более простой мерж в git, но ни разу не видел подтверждния. Коллеги, которые активно двигают гит на работе, точно так же временами сидят и руками мержат файлы, произнося при этом нецензурные слова. И временами народ так же материться, выясняя кто в какую ветку пушился и почему в хеде нет его кода. Причем, последней проблемы — потерянные коммиты — на svn не наблюдалось.
Единственный достойный аргумент за git, который я слышал, — " если сервер прикажет долго жить, то у любого разработчика будет копия репозитария и мы без проблем развернемся".
Проблема не в инструментарии — сами инструменты для слияния не сильно отличаются, Проблема в подходах к использованию. У DVCS более частые коммиты и поэтому слияние происходит проще. В CVCS коммиты большие и редкие из опасения сломать чужой код.
stackoverflow.com/questions/2613525/what-makes-merging-in-dvcs-easy/2613595#2613595
stackoverflow.com/questions/2613525/what-makes-merging-in-dvcs-easy/2613595#2613595
>>Единственный достойный аргумент за git
Простите, но для трёх студентов, вечерами под пиво пишущих убийцу DOOM II, это вполне аргумент, для минимально серьёзной организации — никак нет.
Простите, но для трёх студентов, вечерами под пиво пишущих убийцу DOOM II, это вполне аргумент, для минимально серьёзной организации — никак нет.
За выдергивание цитат из контекста пора вводить расстрелянную статью!
Я писал, что это не единственный достойный аргумент в мире, а единственный достойный аргумент, который мне привелось услышать.
Я писал, что это не единственный достойный аргумент в мире, а единственный достойный аргумент, который мне привелось услышать.
<irony>За неграмотно написанные комментарии пора вводить расстрельную статью!</irony>
Да, я прекрасно понимаю, что это — не единственный аргумент. Но, по моему мнению, это аргумент только для выше озвученного примера про студентов, для всего остального, связанного с бизнесом и деньгами — это НЕ аргумент, а сознательное подкладывание себе граблей.
Плюс — слово «единственный» было написано вами, мной приведено только для того, чтобы не рвать фразу, и вы сами же на неё и дернулись. Если вы ещё раз перечитаете мой комментарий то увидите, что про «единственный» я ничего и не говорю ;)
Да, я прекрасно понимаю, что это — не единственный аргумент. Но, по моему мнению, это аргумент только для выше озвученного примера про студентов, для всего остального, связанного с бизнесом и деньгами — это НЕ аргумент, а сознательное подкладывание себе граблей.
Плюс — слово «единственный» было написано вами, мной приведено только для того, чтобы не рвать фразу, и вы сами же на неё и дернулись. Если вы ещё раз перечитаете мой комментарий то увидите, что про «единственный» я ничего и не говорю ;)
Да, за очепятки тоже нужно бить)) И за веру в автоисправление!
А вообще — я сам к этому аргументу очень иронично отношусь.
А вообще — я сам к этому аргументу очень иронично отношусь.
О, а давайте вместе устроим зондеркоманду! Будем всех расстреливать за опечатки, ошибки и выдернутые из контекста цитаты! А когда мир будет очищен от этих напастей, найдем опечатку и ошибку друг у друга и… =)
Жаль только то, что некоторые не утруждают себя прочитать всю ветку комментариев, но в профиль зайти им не лень.
Жаль только то, что некоторые не утруждают себя прочитать всю ветку комментариев, но в профиль зайти им не лень.
вот вам еще один аргумент: если серевер не доступен (не обязательно «приказал долго жить», а например лежит или сети нет), то простой просмотр лога невозможен в svn. сужу по старыми версиям типа svn-1.4
кста, несовместимости между версиями svn тоже доставляли немало, это собственно было последней каплей для перехода на git.
кста, несовместимости между версиями svn тоже доставляли немало, это собственно было последней каплей для перехода на git.
Я рассматривал применение git (как и svn) внутри команды разработчиков, которая постоянно работает в офисе. Подключения из дома — редкость. В этом случае что смерть сервера с отсутствием бекапа, что его простой — повод хорошо поругаться с админами. Ну или следствие более глобальной бяки в офисной сети/инфраструктуре.
Про то, что git уделывает svn в случае распределенной команды я говорить не буду — тут и так всё ясно.
Про несовместимость версий — а есть ли у git за плечами такая история, что бы говорить, что они не ломают обратную совместимость? Хотя всё равно неплохой аргумент, положу в копилку.
Про то, что git уделывает svn в случае распределенной команды я говорить не буду — тут и так всё ясно.
Про несовместимость версий — а есть ли у git за плечами такая история, что бы говорить, что они не ломают обратную совместимость? Хотя всё равно неплохой аргумент, положу в копилку.
> Я рассматривал применение git (как и svn) внутри команды разработчиков, которая постоянно работает в офисе.
при таких запросах вам по-видимому не нужна распределенная система, потому и аргументов для вас нет.
про историю точно не скажу, номера стабильных версий у git и svn одинаковые, svn разрабатывают 10 лет, гит 6 лет. мне кажется ломка обратной совместимости не есть необходимость при долгом развитии.
при таких запросах вам по-видимому не нужна распределенная система, потому и аргументов для вас нет.
про историю точно не скажу, номера стабильных версий у git и svn одинаковые, svn разрабатывают 10 лет, гит 6 лет. мне кажется ломка обратной совместимости не есть необходимость при долгом развитии.
>> при таких запросах вам по-видимому не нужна распределенная система, потому и аргументов для вас нет.
Но при этом меня окружают люди, которые и при таких запросах (такой ситуации) очень хотят уйти на git. Вот я и ищу аргументы, что бы их понять.
Я не говорю, что ломка обратно совместимости — это необходимость долгого развития. Просто обычно чаще её ломают или в самом начале, когда только обкатывают, в pre-alpha, либо в далёком будущем.
Но при этом меня окружают люди, которые и при таких запросах (такой ситуации) очень хотят уйти на git. Вот я и ищу аргументы, что бы их понять.
Я не говорю, что ломка обратно совместимости — это необходимость долгого развития. Просто обычно чаще её ломают или в самом начале, когда только обкатывают, в pre-alpha, либо в далёком будущем.
Аргумент — постоянные, блин, коммиты. На своём рабочем месте, без боязни сломать чужой код и необходимости мерджиться на каждый чих.
Это относится ко всем DVCS, не только к гиту.
Это относится ко всем DVCS, не только к гиту.
Эм… а почему на SVN нельзя часто коммититься? У меня на сервере никогда не стояло ограничение на число коммитов в день/час/минуту.
И что значит без боязни сломать чужой код? Если я работая по git перепишу функцию с которой работает мой коллега, то сборка такого переписанного кода пройдет лучше, чем если бы я ровно те же изменения внес под svn?
И что значит без боязни сломать чужой код? Если я работая по git перепишу функцию с которой работает мой коллега, то сборка такого переписанного кода пройдет лучше, чем если бы я ровно те же изменения внес под svn?
Вы сидите в одной ветке, делаете коммит, продолжаете работать. Ваш коллега делает коммит, упс, нужно проадейтиться. Ок проадейтился, смерджил, закоммитил. Теперь уже вам нужно перед коммитом обновиться. Конечно вариант, на каждый чих заводить ветку, но если на одну задачу больше пары человек, то начинаются танцы.
В случае распределенных систем, вы работаете в своей песочнице: закончили, проапдейтились, смерджили, запушили.
Даже с DVCS можно иметь «центральный» репозиторий.
В случае распределенных систем, вы работаете в своей песочнице: закончили, проапдейтились, смерджили, запушили.
Даже с DVCS можно иметь «центральный» репозиторий.
Ага, начались танцы с терминологией. Я как-то и для DVCS привык под словом коммит понимать push, т.е. проталкивание кода в «центральный» репозитарий. По сути мы имеем историю локальный изменений, но «выливание» кода в общий котел отложено максимально на потом.
Понятненько. Тут в целом согласен.
А в чем проблема на каждую задачу заводить отдельную ветку? Мы у себя именно так и планируем провести «реформу репозитариев». Т.е. мало того, что окончательно уйти на git, но и еще на каждую задачу в трекере заводить отдельную ветку. Чем это плохо?
Понятненько. Тут в целом согласен.
А в чем проблема на каждую задачу заводить отдельную ветку? Мы у себя именно так и планируем провести «реформу репозитариев». Т.е. мало того, что окончательно уйти на git, но и еще на каждую задачу в трекере заводить отдельную ветку. Чем это плохо?
Ни в чем, идеология абсолютно та же. Нужна фича, открываем ветку и в ней кодим. Когда готово — сливаем изменения в главную ветку. Просто в одной ветке может работать больше одного человека. Спольски развернуто объяснил hginit.com/00.html Главная идея в том, что DVCS поддерживает идеологию CVSC, но не наоборот.
Гит ещё более разухабистый, у него есть т.н. stash и staging area www.ndpsoftware.com/git-cheatsheet.html которых, порой, не хватает в mercurial. Нужна простота и лёгкая кроссплатформенность — Mercurial, нужны фичи, гитхаб — Git.
Гит ещё более разухабистый, у него есть т.н. stash и staging area www.ndpsoftware.com/git-cheatsheet.html которых, порой, не хватает в mercurial. Нужна простота и лёгкая кроссплатформенность — Mercurial, нужны фичи, гитхаб — Git.
с гитом есть свои проблемы
Ой, да ладно. Смержил без единого конфликта, а потом ищешь, кто же так уе… щно смерджил, что потерялись какие-то важные изменения. Спасибо, не надо.
ЗЫ пользую меркурилиал, автомердж использую крайне редко, и все равно проверяю дополнительно все, что он намержил перед комитом.
ЗЫ пользую меркурилиал, автомердж использую крайне редко, и все равно проверяю дополнительно все, что он намержил перед комитом.
Дада. Mercurial — наше всё ;0
Хотели мы начать проект делать с git'ом, но по традиции решили всё таки заюзать svn. А перейти не решились потому, что никто раньше не работал с ним, боялись.
Есть ли хорошие материалы на русском по работе с git'ом? И было бы идеально, если бы кто-нибудь написал (или ткнул меня носом в) статью о том, чем же на практике отличаются git, svn и mercurial.
Есть ли хорошие материалы на русском по работе с git'ом? И было бы идеально, если бы кто-нибудь написал (или ткнул меня носом в) статью о том, чем же на практике отличаются git, svn и mercurial.
Могу посоветовать githowto.com/ и gittutor (стандартная обучалка в git).
На github есть перевод на достаточное количество языков github.com/progit/progit
Русскоязычная версия почти полная
Русскоязычная версия почти полная
Я перешел на git после того как увидел github
за счёт чего у гита такой взрывной рост? Вроде не видно резких падений
не знаю не знаю. сложный этот ваш гит.слишком много движений надо делать чтобы банально пушнуть в репу. в mercurial все в разы! проще. юзаю меркуриал с 2009. пробовал до этого гит, не прижилось.
сравним:
git push -u origin master
и
hg push
git push -u origin master
и
hg push
Эээ. Я всегда делаю «git push». Что мне в гите реально не хватает — это
hg update для того, чтобы на сервере автообновлялся код после коммитаю Обгуглился, но кроме грязного хака решения не нашёл =(
> чтобы на сервере автообновлялся код после коммита
Если честно не понял проблему. Что именно должно автообновлятся?
Если честно не понял проблему. Что именно должно автообновлятся?
У меня есть сервер, на котором развёрнут проект и несколько разработчиков. Я хочу делать git push и чтобы клиенты сразу после этого получали обновлённый код. Для этого в репозитории необходимо сделать post-reseive хук типа «hg update». Вообще я читал совет сделать на сервере 2 репозитория — один просто хранит код, а второй — смотрит на клиентов, но это вообще криво.
длинна команды не играет роли при использовании алиасов
Я твой гит чейнджсет шатал
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Популярность систем управления версиями среди пользователей Debian