Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 265
Зря вы так против gui. Есть команда git gui которая является простенькой надстройкой над консолью. Так вот эта git gui ползена новичкам, если не понятно, как сделать операцию в консоли. Можно не заниматься нудными поисками в гугле, а просто сделать операцию в графическом интерфейсе.
Вот например, я все ещё не понял какой командой надо помечать файлы в которых я разрешил конфликты при мерже. И ничуть не страдаю от того, что приходится написать git gui и дотянуться до мыши. (Подскажите, если не сложно)
Вот например, я все ещё не понял какой командой надо помечать файлы в которых я разрешил конфликты при мерже. И ничуть не страдаю от того, что приходится написать git gui и дотянуться до мыши. (Подскажите, если не сложно)
Черт, промахнулся. Ответил ниже.
> И ничуть не страдаю от того, что приходится написать git gui и дотянуться до мыши.
Не ленитесь учиться. Я себя очень часто заставляю залезать в хелп или гуглить, чтобы понять как что-то работает.
Не ленитесь учиться. Я себя очень часто заставляю залезать в хелп или гуглить, чтобы понять как что-то работает.
Ещё есть удобный SmartGit.
Виндузятники используют TortoiseGIT и нахваливают.
git-gui и gitk убоги.
Для Linux есть gitg, для OS X — GitX. Они замечательно комбинируют в себе возможности этих двух утилит.
Для Linux есть gitg, для OS X — GitX. Они замечательно комбинируют в себе возможности этих двух утилит.
> какой командой надо помечать файлы в которых я разрешил конфликты
git add path/to/file
git add path/to/file
Хорошая статья, давно хотел узнать чем же хорош Git.
Теперь кто нибудь напишите чем хорош Mercurial)
Теперь кто нибудь напишите чем хорош Mercurial)
бОльшая часть описанных здесь фич применима и к Mercurial'у
Там только «гитхаб» плюс по отношению к хг. Стейджинг — это недо-mq, cheap local branching — это вообще три раз порванный баян.
Вот правильный ответ gitvsmercurial.com/
Топик скорее не «Почему Git?», а «Почему распределенный VCS?», все плюсы есть и у конкурентов (например в mercurial).
Не все. Например, нет stash.
ну, у каждого есть свои плюсы и минусы. Например, rerere, но зато есть hg serve и т.д.
stash разве не заменяет банальным diff?
как-то так:
hg diff > stash.patch
hg revert
...work
hg commit
...work
hg commit
patch stash.patch
как-то так:
hg diff > stash.patch
hg revert
...work
hg commit
...work
hg commit
patch stash.patch
stash в меркуриале — shelve.
Уже два :) Вот бы ещё кто показал расширение, позволяющее в changeset, не отправленный в удалённую репу, добавить изменения как в darcs amend-record. Тогда остальные DVCS (для моих требований) будут совсем не нужны.
hg rollback для начала. А вообще — mq такое может, например так:
1) импортировать как патч mq можно только голову или коммит, у которого дети — уже патчи
2) -e — редактировать сообщение, можно опустить, естественно
Вообще стоит просто почитать hg help mq. Я как-то давно уже хочу написать руководство по mq, но руки никак не доходят. %)
Attic, кстати, это нечто среднее между mq и shelve. С помощью mq тоже можно эмулировать stash.
hg qimport -r . hg qrefresh -e hg qfinish .
1) импортировать как патч mq можно только голову или коммит, у которого дети — уже патчи
2) -e — редактировать сообщение, можно опустить, естественно
Вообще стоит просто почитать hg help mq. Я как-то давно уже хочу написать руководство по mq, но руки никак не доходят. %)
Attic, кстати, это нечто среднее между mq и shelve. С помощью mq тоже можно эмулировать stash.
Да, сначала откатиться hg rollback, а далее надо включить встроенно расширение mercurial.selenic.com/wiki/RecordExtension
Для меня является большим перепоном то, что для того что-бы сделать так как работает git из коробки(т/е так как мне нужно) — нужно доставить пачку плагинов в mq (и это каждому члену комманды — время внедрения нового человека в команду затягиватся) — хотя если работать одному то это наверное даже плюс
«доставить пачку плагинов в mq» звучит странно, учитывая что mq — сам по себе плагин. :)
Да, меня эта тема тоже немного волнует, и у меня есть некоторые мысли по поводу того, что б сделать, чтобы это улучшить.
Да, меня эта тема тоже немного волнует, и у меня есть некоторые мысли по поводу того, что б сделать, чтобы это улучшить.
Здесь есть резон:
В гите есть 150 команд, в меркуриале по умолчанию 10. Цифры примерный!!!
Если хотите функционал пошире — включите необходимое. Большинству не нужно, они не должны путаться, страдать и т.п. от обилия команд.
Кроме того, большинство нужных расширений встроенные, так что вам будет достаточно поделиться с разработчиками куском конфига.
У меня не «из коробки» только 2 расширения.
В гите есть 150 команд, в меркуриале по умолчанию 10. Цифры примерный!!!
Если хотите функционал пошире — включите необходимое. Большинству не нужно, они не должны путаться, страдать и т.п. от обилия команд.
Кроме того, большинство нужных расширений встроенные, так что вам будет достаточно поделиться с разработчиками куском конфига.
У меня не «из коробки» только 2 расширения.
что если я редактировал одну ветку, потом мне срочно потребовалось переключиться в другую ветку, я там наредактировал, а потом мне потребовалось переключиться в третюю?
я про гит спрашивал…
git stash
и? можно сделать 3 стэша и переключаться между ними?
а в качестве имени будет хэш чтоли? или можно как-то задать имя?
git stash save «my stash name»
Почитайте тут 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}
… If you want to apply one of the older stashes, you can specify it by naming it, like this: git stash apply stash@{2}
pragprog.com/titles/tsgit/pragmatic-version-control-using-git — вот эту сейчас читаю. Достаточно понятно изъясняется с примерами по каждой упомянутой команде. Возможно стоит добавить в список. Хотя я других не читал по этой теме, сравнить не с чем.
Какое-то последнее время нездоровое количество визга по поводу Git-а. Был у меня один проект, который надо было делать вдвоем, а сервер поднимать не хотелось. Поставили Git, зачли репозитарий.
Сразу же выяснилось — в Git-е нельзя создать пустую папку. Мелочь, скажете вы? Вроде бы да, но, согласитесь, пустые папки бывают нужны — например, папка для данных приложения, которая будет потом заполняться рантаймом, а так же начальная структура каталогов. Пришлось всюду положить по пустому файлу, что само по себе костыль.
Дальше — больше. Хорошо, начальная структура каталогов, первый проект — все это было сделано, закоммичено, проблем не вызвало. Что дальше? А дельше надо передать проект своему напарнику. И тут выяснятся, что сделать этого напрямую мы не можем. Что надо поднимать либо веб-сервис с WebDav, либо чтобы он имел доступ к моей ФС, либо поднимать git-server. Напрямую p2p два клиента без поднимания костылей подключиться и сделать push не могут. А значит все равно нужен какой-то эталонный центральный сервер.
А если все равно нужен центральный сервер, то в чем прелесть? По сути — только в простом управлении ветками. Причем именно в их создании/удалении, т.к. опции типа редактирования коммитов — это, конечно, клево, но так ли уж сильно нужно?
Сразу же выяснилось — в Git-е нельзя создать пустую папку. Мелочь, скажете вы? Вроде бы да, но, согласитесь, пустые папки бывают нужны — например, папка для данных приложения, которая будет потом заполняться рантаймом, а так же начальная структура каталогов. Пришлось всюду положить по пустому файлу, что само по себе костыль.
Дальше — больше. Хорошо, начальная структура каталогов, первый проект — все это было сделано, закоммичено, проблем не вызвало. Что дальше? А дельше надо передать проект своему напарнику. И тут выяснятся, что сделать этого напрямую мы не можем. Что надо поднимать либо веб-сервис с WebDav, либо чтобы он имел доступ к моей ФС, либо поднимать git-server. Напрямую p2p два клиента без поднимания костылей подключиться и сделать push не могут. А значит все равно нужен какой-то эталонный центральный сервер.
А если все равно нужен центральный сервер, то в чем прелесть? По сути — только в простом управлении ветками. Причем именно в их создании/удалении, т.к. опции типа редактирования коммитов — это, конечно, клево, но так ли уж сильно нужно?
> Напрямую p2p два клиента без поднимания костылей подключиться и сделать push не могут
Могут напрямую через ssh
Могут напрямую через ssh
Вот именно! А еще есть hg bundle. И можно хоть мылу/аське/шаре коммитами кидаться.
Я так понимаю, что речь идет про git+ssh? Честно скажу, Git я собрался использовать после того как посмотрел презентацию Git-а на Google Tech Days, проводимую самим Линусом Торвальдсом (линк). Там был вот такой кадр:
Глядя на нее, я ожидал поддержки p2p соединений на уровне самого Git-а. Например, подключение на удаленный адрес: порт, открываемый коллегой, либо чего-то в этом роде.
А получается, что все эти веселые смайлики сидят исключительно на *nix машинах, на каждом установлен и настроен SSHd, созданы аккаунты для каждого из соседей (!!!), а когда появляется новый член, все, видимо, дружно создают ему по аккаунту, когда уходит — дружно его удаляют. Кроме того, SSH — это ведь как бы не только Git, не так ли? Значит за каждым из компов сидит сисадмин, который не поленился настроить должным образом систему и SSHd, чтобы обеспечить безопасность пребывания малознакомых людей на своем десктопе.
Наверняка, найдутся ситуации, когда это будет не просто возможно, но и полезно и необходимо. Но так ли все просто и радужно на самом деле, как в рекламе? Используется ли реально Git именно для децентрализации, а не только для легкого управления ветками?
P.S: судя по количеству минусов, которые были получены в карму, на фоне отсутствия конструктивного диалога — интерес и правда «нездоровый». Кто-то воспринял критику Git-а как личное оскорбления что ли?
Глядя на нее, я ожидал поддержки p2p соединений на уровне самого Git-а. Например, подключение на удаленный адрес: порт, открываемый коллегой, либо чего-то в этом роде.
А получается, что все эти веселые смайлики сидят исключительно на *nix машинах, на каждом установлен и настроен SSHd, созданы аккаунты для каждого из соседей (!!!), а когда появляется новый член, все, видимо, дружно создают ему по аккаунту, когда уходит — дружно его удаляют. Кроме того, SSH — это ведь как бы не только Git, не так ли? Значит за каждым из компов сидит сисадмин, который не поленился настроить должным образом систему и SSHd, чтобы обеспечить безопасность пребывания малознакомых людей на своем десктопе.
Наверняка, найдутся ситуации, когда это будет не просто возможно, но и полезно и необходимо. Но так ли все просто и радужно на самом деле, как в рекламе? Используется ли реально Git именно для децентрализации, а не только для легкого управления ветками?
P.S: судя по количеству минусов, которые были получены в карму, на фоне отсутствия конструктивного диалога — интерес и правда «нездоровый». Кто-то воспринял критику Git-а как личное оскорбления что ли?
Вся децентрацизация крутится вокруг обмена патчами:
— Положите bare-репозиторий на публичный сервер и обменивайтесь информацией через него.
— Можно работать с системой форков, как это устроено на GitHub — здесь неограниченная связь многие ко многим.
— Можно коннектиться напрямую через SSH. Это может быть оправдано, когда вас всего двое.
— Можно обмениваться патчами по почте: git format-patch, git send-email, git apply или git am
Все зависит от того, как у вас организована работа в команде. Наиболее простой и удобный способ — это выделить один репозиторий для обмена. А уж комбинировать все указанные выше способы вы можете как угодно в соответствии с потребностями.
— Положите bare-репозиторий на публичный сервер и обменивайтесь информацией через него.
— Можно работать с системой форков, как это устроено на GitHub — здесь неограниченная связь многие ко многим.
— Можно коннектиться напрямую через SSH. Это может быть оправдано, когда вас всего двое.
— Можно обмениваться патчами по почте: git format-patch, git send-email, git apply или git am
Все зависит от того, как у вас организована работа в команде. Наиболее простой и удобный способ — это выделить один репозиторий для обмена. А уж комбинировать все указанные выше способы вы можете как угодно в соответствии с потребностями.
Наиболее простой и удобный способ — это выделить один репозиторий для обмена.
Абсолютно с вами согласен. Но по сути у нас это ведь получается эквивалентом централизованной системы разработки. А команды формирования патча, который может быть переслан через e-mail, есть и в SVN — svn diff / svn patch.
В централизованной системе очень велика зависимость от центрального сервера и низка скорость обмена информацией плюс дорогостоящи прыжки по истории (checkout). В распределенной системе достаточно выживания хотя бы одной рабочей копии — и по ней можно восстановить центральный репозиторий с точностью до последнего pull c него.
Т.е. различие заключается в том, что в Git локальные репозитории дублирует всю историю изменений, в SVN же — только текущую ревизию. Поэтому если вдруг не дай Бог что произойдет с центральным сервером, то по Git-у мы восстановим все ревизии, а по SVN — только последнюю.
Правильно я понял?
Правильно я понял?
Да. У каждого СВОЙ локальный репозиторий со всей историей.
И центральный репозиторий — это не больше чем соглашение, что конкретно именно эта копия будет использоваться для обмена.
И центральный репозиторий — это не больше чем соглашение, что конкретно именно эта копия будет использоваться для обмена.
Ключевое различие именно в этом — каждая рабочая копия в распределенной системе контроля версий является полноценным репозиторием.
Отсюда и все плюшки — высокая скорость операций, меньшие требования к каналам связи, высокая отказоустойчивость, любая топология сети репозиториев, локальные commit/update/checkout.
Минусы тоже есть (они напрямую вытекают из плюсов) — более сложная двухступенчатая система заливки, для поддержки централизации требуются дополнительные технические или организационные меры.
Но если минусы легко преодолеваются обучением и практикой, то плюсы остаются навсегда.
Я полагаю, в будущем принудительно централизованные системы отомрут — они уже сейчас выдерживают конкуренцию с децентрализованными только за счет легаси.
Отсюда и все плюшки — высокая скорость операций, меньшие требования к каналам связи, высокая отказоустойчивость, любая топология сети репозиториев, локальные commit/update/checkout.
Минусы тоже есть (они напрямую вытекают из плюсов) — более сложная двухступенчатая система заливки, для поддержки централизации требуются дополнительные технические или организационные меры.
Но если минусы легко преодолеваются обучением и практикой, то плюсы остаются навсегда.
Я полагаю, в будущем принудительно централизованные системы отомрут — они уже сейчас выдерживают конкуренцию с децентрализованными только за счет легаси.
Дык с этого же и начата ветка — рабочая копия НЕ ЯВЛЯЕТСЯ ПОЛНОЦЕННЫМ репозиторием: в неё пушить из другого репозитория нельзя без дополнительного танца с бубном!
Хотя, как сказано комментом ниже, простенький демон же в комплекте есть…
git — это система контроля версий, а не p2p файлсервер с поддержкой истории (как иногда люди пытаются использовать VCS вообще).
По вашей логике, нужно было бы в git воткнуть сам ssh/sshd, а также zeroconf какой-нибудь, а потом молиться, что бы этот комплект заработал у всех пользователей, со своими привычками, операционками и аппаратурой.
P.S. Если есть организационные проблемы, совсем необязательно настраивать sshd на том хосте, на котором работаешь — можно и виртуализацией обойтись.
По вашей логике, нужно было бы в git воткнуть сам ssh/sshd, а также zeroconf какой-нибудь, а потом молиться, что бы этот комплект заработал у всех пользователей, со своими привычками, операционками и аппаратурой.
P.S. Если есть организационные проблемы, совсем необязательно настраивать sshd на том хосте, на котором работаешь — можно и виртуализацией обойтись.
Интересно, как вы представляете передачу p2p без доступа к фс…
да, полная автономность гита это огромный минус.
Я так и не понял как удобно огранизовать реплики на друзей и обратно.
На гит я перешол для локальной разработки, после того как горе админ уничтожил svn репу на сервере, а я узнал что вообще для папки очень сложно поменять svn сервер.
Я так и не понял как удобно огранизовать реплики на друзей и обратно.
На гит я перешол для локальной разработки, после того как горе админ уничтожил svn репу на сервере, а я узнал что вообще для папки очень сложно поменять svn сервер.
svn switch --relocate newsvnserver
Нет.
У вас был svn сервер, вы перешли на другой.
Этот svn — умирает, вы ругаетесь и переключаетесь на старый svn.
Ну и фигу ловите. «Слишком разные сервера, даж не знаю как быть. Но команду вертаю тебе» (с)SVN
А все дело в том что физически правки храняться на сервере, а на клиенте их нет.
И если сдох сервер.
Все.
У вас был svn сервер, вы перешли на другой.
Этот svn — умирает, вы ругаетесь и переключаетесь на старый svn.
Ну и фигу ловите. «Слишком разные сервера, даж не знаю как быть. Но команду вертаю тебе» (с)SVN
А все дело в том что физически правки храняться на сервере, а на клиенте их нет.
И если сдох сервер.
Все.
Сложно? svn relocate oldurl newurl
!?!?!?!?!
!?!?!?!?!
Пустые папки обычно задаются созданием в них файла .gitkeep
костыль же…
пустые папки сами по себе костыль, если уж так.
Допустим я начинаю веб-приложение. Мне важно, чтобы в команде было единое мнение по поводу того, куда должны класться CSS, JS файлы, файлы картинок, шаблонов, SQL дампов и прочего.
Для этого я создаю структуру каталогов, в которой создаю пустые папки под js, css, пд картинки, под аплоады, под классы, ресурсы и прочее. Теперь другие разработчики будут следовать данной иерархии и, если надо, изменять или дополнять ее, не создавая при этом анархии. Со временем эти папки наполнятся, а ненужные удалятся, но в начале пути мне необходимо чтобы они были и были при этом пустыми.
Почему инструмент разработки должен диктовать, что мол «неет, братец, тебе не нужны пустые папки»?
Для этого я создаю структуру каталогов, в которой создаю пустые папки под js, css, пд картинки, под аплоады, под классы, ресурсы и прочее. Теперь другие разработчики будут следовать данной иерархии и, если надо, изменять или дополнять ее, не создавая при этом анархии. Со временем эти папки наполнятся, а ненужные удалятся, но в начале пути мне необходимо чтобы они были и были при этом пустыми.
Почему инструмент разработки должен диктовать, что мол «неет, братец, тебе не нужны пустые папки»?
слушай, угомонись уже. гит отслеживает файлы, не папки. нужна папка — добавь пустой файл. нужна папка без файла — пользуйся свн. вот и всё пространство решений.
к тому же куда все должно складываться решается административно, а не через сорс контроль. никакой свн не запретит мне свалить все картинки в папку для цсс.
к тому же куда все должно складываться решается административно, а не через сорс контроль. никакой свн не запретит мне свалить все картинки в папку для цсс.
Отвечу всем сразу, высказавшим мнение о составлении письменной спецификации: административной проблемы в данной ситуации не существует. Команда дружная и не собирается загаживать проект. Все согласны, что структура должна быть.
Просто должен быть кто-то, кто эти папки однажды создаст, чтобы потом, когда людям нужно будет добавить CSS файл, они не лезли в спецификацию, и не вычитывали бы правила именования файлов, а просто положили бы его в уже подготовленную папку.
Зачем плодить документы и бюрократию, когда достаточно создать 5-7 папок?
Просто должен быть кто-то, кто эти папки однажды создаст, чтобы потом, когда людям нужно будет добавить CSS файл, они не лезли в спецификацию, и не вычитывали бы правила именования файлов, а просто положили бы его в уже подготовленную папку.
Зачем плодить документы и бюрократию, когда достаточно создать 5-7 папок?
Тем не менее бывает необходимость создавать именно пустые папки если нужно сохранить определенную структуру каталогов, например возьмем любой php-фрэймворк, у него есть определенная файловая структура, но не во всех папках есть файлы (это может быть папка для кэша или что-то подобное) и тут подобный подход удобен. Вы можете сказать, что есть и другие методы решения такой проблемы, но создание пустой папки тоже имеет право на жизнь.
У вас один стиль, у нас другой. Вы сторонник восходящего проектирования, когда сущности создаются по мере необходимости, я — сторонник нисходящего, когда сначала формируется скелет, который потом обрастает мясом.
И то, и другое — хорошие, жизнеспособные подходы, но только один из них поддерживается Git-ом, а другой — нет. Если вы никогда не будете использовать нисходящий подход, то, возможно, вы никогда и не заметите этого ограничения. Но ведь есть и сторонники других подходов, не так ли? А такая штука как система контроля версий должна подразумевать определенную долю универсальности.
И то, и другое — хорошие, жизнеспособные подходы, но только один из них поддерживается Git-ом, а другой — нет. Если вы никогда не будете использовать нисходящий подход, то, возможно, вы никогда и не заметите этого ограничения. Но ведь есть и сторонники других подходов, не так ли? А такая штука как система контроля версий должна подразумевать определенную долю универсальности.
Полагаю, что организационные задачи очень даже могут решаться техническими методами, но это должно быть именно решение, а не имитация. Т.е. если в определенную папку можно класть только css, а в другие папки css класть нельзя, то техническое решение должно это обеспечивать при любых действиях пользователя, включая человекопонятные сообщения об ошибках.
Да, но зачем усложнять?
Если, например, в проекте предполагается вынесение статики на отдельный сервер, то логично сосредоточение всех данных в одном месте. Например:
При этом любому адекватному разработчику будет уже и так понятно, что CSS файл надо положить в static_files/css, а неадекватных мы тут не держим.
Если, например, в проекте предполагается вынесение статики на отдельный сервер, то логично сосредоточение всех данных в одном месте. Например:
static_files
... css
... images
... ... uploads
... js
... ... 3rd_party
При этом любому адекватному разработчику будет уже и так понятно, что CSS файл надо положить в static_files/css, а неадекватных мы тут не держим.
«рыться в куче существующих» — это тяжкое наследие консоли, которая как правило не показывает в наглядной и обозримой форме дерево каталогов.
Одного взгляда на дерево нормально названных каталогов достаточно для того, чтоб понять что куда надо класть.
Самодокументированный код, интерфейс, структура — это ХОРОШО.
Одного взгляда на дерево нормально названных каталогов достаточно для того, чтоб понять что куда надо класть.
Самодокументированный код, интерфейс, структура — это ХОРОШО.
Возмущение понятно, только вы пре-перфекционист. Даже если вам это сильно нужно. Вы все равно с коммандой договариваетесь голосом, а не созданием папок. Нарисуйте эту структуру на листике, как памятку.
В обычном кейсе, если папка пустая (напр. logs), то в нее что-то будет писаться. Значит должны быть права на запись. Значит можно включить в скрипт инициализации проекта (напр. phing) выставление нужных прав, а заодно и ее создание.
В обычном кейсе, если папка пустая (напр. logs), то в нее что-то будет писаться. Значит должны быть права на запись. Значит можно включить в скрипт инициализации проекта (напр. phing) выставление нужных прав, а заодно и ее создание.
> Если пустая папка нужна для того, чтобы туда клались данные, то в этой папке должен быть файл .gitignore, и такая папка будет уже не пустой.
После такой рекомендации глупо ругаться на SVN, который «засирает» каждую папку подпапкой .svn — здесь все получается еще хуже и не системно.
А если кто-то на радостях что-то напишет в этот файл .gitignore? И получится, что в одних папках одни файлы игнорятся, в других — другие. Вобщем место для потенциальной путаницы и гемора.
После такой рекомендации глупо ругаться на SVN, который «засирает» каждую папку подпапкой .svn — здесь все получается еще хуже и не системно.
А если кто-то на радостях что-то напишет в этот файл .gitignore? И получится, что в одних папках одни файлы игнорятся, в других — другие. Вобщем место для потенциальной путаницы и гемора.
Runtime данные всегда должны быть заигнорены. Или вам нравится, например, копаться в git status на 3 экрана, где 99% — файлы логов?
Как говорилось в статье, это git-way. Да, вы можете создать глобальный .gitignore, но так не делается (по крайней мере я в последний раз такое видел только в svn-репозиториях).
Как говорилось в статье, это git-way. Да, вы можете создать глобальный .gitignore, но так не делается (по крайней мере я в последний раз такое видел только в svn-репозиториях).
По поводу пыстых папок обозначился выше.
простое управление ветками — это не создание/удаление, а в первую очередь мерж. например в svn не мерж, а гавно.
если хочется без сервера, то вот
если хочется без сервера, то вот
> Какое-то последнее время нездоровое количество визга по поводу…
Ну не знаю, почему я должен читать дальше этого предложения, если у автора на лицо неуважение к чужому мнению?
С какой вероятностью точка зрения такого человека будет хоть чуть-чуть объективной и взвешенной? Да с нулевой. Ведь для этого надо внимательно слушать и серъезно обдумывать мнения других, а не считать их голоса «визгом».
Ну не знаю, почему я должен читать дальше этого предложения, если у автора на лицо неуважение к чужому мнению?
С какой вероятностью точка зрения такого человека будет хоть чуть-чуть объективной и взвешенной? Да с нулевой. Ведь для этого надо внимательно слушать и серъезно обдумывать мнения других, а не считать их голоса «визгом».
Ваше приложение не будет работать, если нужной ему папки нет?
Может оно само ее создаст? Так удобнее!
Пустые папки и код приложения вообще никак не связанны. Сокеты и пайпы тоже коммитать было бы хорошо…
Может оно само ее создаст? Так удобнее!
Пустые папки и код приложения вообще никак не связанны. Сокеты и пайпы тоже коммитать было бы хорошо…
habrahabr.ru/blogs/Git/104198/#comment_3250973: это бывает дырой в безопасности
Спасибо за bisect — знал, что что-то такое есть, но не знал как называется (не было острой необходимости). По теме: буквально пару месяцев как начал пользоваться git-ом и весьма доволен, хотя все-таки думаю еще познакомится с конкурентами =)
Скажите пожалуйста (гугл не помог), есть ли в git аналог hg serve? Или какой-нибудь простой браузер репозитория, запускаемый, например как
$ gitweb -d /home/repos/myproj -p 1081
а не
# rc-service apache start
$ gitweb -d /home/repos/myproj -p 1081
а не
# rc-service apache start
Спасибо — все собирался познакомиться с гитом поближе, теперь точно попробую.
Создать репозитарий в текущей директории — «git init». Все.
Создание репы не сильно сложная процедура
svnadmin create там тоже ведь не сложно?
Всего одна папочка .git и никакой порнографии ввиде .svn в каждой директории.
Не понимаю проблемы порнографией, если конечно делается svn export
Интернет не нужен.
Ну как-бы не понимаю опять-же проблемы, если работает больше одного, то интернет нужен. Да и если один, но работает в нескольких местах, то тоже нужен, если конечно не таскать флешку с собой или не использовать сетевые хранилища.
Удалить коммит, как будто его и не было
А как быть, если ошибочно?
Я на самом деле почитал и не понял для себя преимуществ по сравнению с SVN. Я работаю с двумя программистами над одним проектом, всё лежит на сервере разработки, svn на сервере бэкапится. Вот чем для меня может быть полезнее git? Прочитал, явных преимуществ не нашел, они наверное есть, но если можно, то кратенько поясните их на примере проекта, где есть сервер и нет проблем с интернетом :)
Пока не начнете пользоваться — не поймете.
А для чего тогда статья?
Да пользовался, ничего хорошего не нашел. По мне так всю это возню вокруг git/svn затевают те, кто не пользовался никогда svn на полную мощность. Про другие системы, в том числе чисто блокирующие я вообще молчу.
Думал как-то написать про тот же svn, но смысл? Когда пишут, что "чудом git-а после svn-а для меня были ветки", то уже доказывать им что-то бесполезно.
Думал как-то написать про тот же svn, но смысл? Когда пишут, что "чудом git-а после svn-а для меня были ветки", то уже доказывать им что-то бесполезно.
Впрочем, вы всё равно попробуйте написать про svn — будет интересно
Можете почитать тут — koorchik.blogspot.com/2010/06/blog-post.html.
да-да, подбадривайте себя, использователь свн на полную мощность. в свн-то и веток толком нет, так, версионированные папки. после получасовых мержей или десятиминутных свитчей любому ветки в dvcs покажутся чудом.
Меня вот .svn в каждой папке напрягает. С git-ом — удалил одну папку и никаких следов того, что тут был репозиторий. Хотя это дело вкуса и преимуществом это не назовешь.
Не знаю, что именно имел в виду автор, но после отката последнего коммита и даже после сурового 'rebase -i' (который позволяет переставить, объединить, отредактировать и даже удалить любое количество коммитов) можно без проблем вернутся в исходное состояние. В доках по этому поводу написано, что очень трудно заставить git безвозвратно удалить то, что вы однажды закоммитили.
Пожалуй самым большим «чудом» git-а после svn-а для меня были ветки. Они с поразительной легкостью позволяют вам работать сразу в нескольких направлениях, не боясь «поломать» master (trunk для SVN). А если идея, реализуемая в отдельной ветке, не оправдала ваши ожидания, то вы удаляете ветку и никто и никогда не узнает, что ваша блестящая идея потерпела фиаско. И главное эта неудача никак не скажется на остальном ходе разработки.
И даже если нет проблем с интернетом, «локальнось» git-a — вещь приятная. Вы можете у себя в репозитории сделать последовательность коммитов (возможно не за один день), убедится, что все хорошо (если нет — пофиксить все, что надо, отредактировать коммиты при необходимости), и только когда это все обретет презентабельный вид — опубликовать в основном репозитории.
Пока не было возможности сравнить git с другими DVCS, но по сравнению с SVN-ом он действительно великолепен.
А как быть, если ошибочно?
Не знаю, что именно имел в виду автор, но после отката последнего коммита и даже после сурового 'rebase -i' (который позволяет переставить, объединить, отредактировать и даже удалить любое количество коммитов) можно без проблем вернутся в исходное состояние. В доках по этому поводу написано, что очень трудно заставить git безвозвратно удалить то, что вы однажды закоммитили.
Пожалуй самым большим «чудом» git-а после svn-а для меня были ветки. Они с поразительной легкостью позволяют вам работать сразу в нескольких направлениях, не боясь «поломать» master (trunk для SVN). А если идея, реализуемая в отдельной ветке, не оправдала ваши ожидания, то вы удаляете ветку и никто и никогда не узнает, что ваша блестящая идея потерпела фиаско. И главное эта неудача никак не скажется на остальном ходе разработки.
И даже если нет проблем с интернетом, «локальнось» git-a — вещь приятная. Вы можете у себя в репозитории сделать последовательность коммитов (возможно не за один день), убедится, что все хорошо (если нет — пофиксить все, что надо, отредактировать коммиты при необходимости), и только когда это все обретет презентабельный вид — опубликовать в основном репозитории.
Пока не было возможности сравнить git с другими DVCS, но по сравнению с SVN-ом он действительно великолепен.
В доках по этому поводу написано, что очень трудно заставить git безвозвратно удалить то, что вы однажды закоммитили.
Ну это логично, меня поэтому и смутила фаза «как будто его и не было».
Меня вот .svn в каждой папке напрягает.
Они уже отказываются от этого и переходят но новую систему хранения на базе sqlite
Да из-за скорости хотя бы. SVN __очень__ медленный по сравнению с git — во всех операциях.
Да просто начните пользоваться, у git много плюсов, для каждого человека они свои )
Да просто начните пользоваться, у git много плюсов, для каждого человека они свои )
>Вот чем для меня может быть полезнее git?
У меня ситуация такая: несколько проектов лежат в репозитории. Проекты имеют общие файлы. В пятницу вечером я закинул файлы на ноутбук и уехал с ним на дачу. В одном из проектов я внес правки в те файлы, которые общие для всех проектов. В случае SVN мне надо добраться до основного репозитория, чтобы эти правки попали во все копии (ну либо ручками внести их в каждый проект).
В случае же Git, насколько я понимаю, у меня с собой будет еще и локальная копия центрального репозитория и в нее я смогу внести свои правки и из нее обновить все свои проекты.
У меня ситуация такая: несколько проектов лежат в репозитории. Проекты имеют общие файлы. В пятницу вечером я закинул файлы на ноутбук и уехал с ним на дачу. В одном из проектов я внес правки в те файлы, которые общие для всех проектов. В случае SVN мне надо добраться до основного репозитория, чтобы эти правки попали во все копии (ну либо ручками внести их в каждый проект).
В случае же Git, насколько я понимаю, у меня с собой будет еще и локальная копия центрального репозитория и в нее я смогу внести свои правки и из нее обновить все свои проекты.
Не понимаю проблемы порнографией, если конечно делается svn export
Меня папки .svn раздражали тем, что fgrep находит ненужное, либо ищет медленно (если настроить чтобы в .svn не заходил).
Плюс невозможно скопировать папку из другого svn проекта — нужно обязательно удалять все .svn папки
Плюс невозможно скопировать папку из другого svn проекта — нужно обязательно удалять все .svn папки
svn export html/do/lib ../../for_vasya
или вы о какой-то другой сложности?
Сложность в том что иногда хочется воспользоваться обычным файловым менеджером (просто F5 или перетащить мышкой), иногда копировать надо через сеть (а программа копирования не вкурсе ни про какие svn export), или отдать папку архиватору (и он тоже не вкурсе что .svn брать не надо). Всё это можно обойти, но лишний шаг всегда раздражает.
А еще разворачивание рабочей копии на сервере.
Обычно у меня там тоже гит репозиторий,
>> git pull origin release
>> service apache2 restart
В случае необходимости можно воспользоваться .git hooks
Хорошо работает даже для сервера у которого вообще нет выхода в интернет.
Приходишь, подключаешь рядом рабочий ноутбук, выдергиваешь за 4 секунды все изменения из проекта размером 50 мб прямо по сети…
Стоит попробовать.
Обычно у меня там тоже гит репозиторий,
>> git pull origin release
>> service apache2 restart
В случае необходимости можно воспользоваться .git hooks
Хорошо работает даже для сервера у которого вообще нет выхода в интернет.
Приходишь, подключаешь рядом рабочий ноутбук, выдергиваешь за 4 секунды все изменения из проекта размером 50 мб прямо по сети…
Стоит попробовать.
Создание репы не сильно сложная процедура
svnadmin create там тоже ведь не сложно?
Основная фишка в локальности. Допустим: появилась идея, надо набросать протоип. С svn: надо или дёргать админа, или поднимать сервер, или самому лезть на сервер создавать, в общем потом, когда сделаю. С git: git init, git commit, git commit, клас, работает, теперь можно и на центральный сервер закинуть, другим показать.
Не понимаю проблемы порнографией, если конечно делается svn export
пояснил
Ну как-бы не понимаю опять-же проблемы, если работает больше одного, то интернет нужен. Да и если один, но работает в нескольких местах, то тоже нужен, если конечно не таскать флешку с собой или не использовать сетевые хранилища.
Если вы никогда не работаете с ноутбука в местах где нет доступа, если у вас никогда не пропадает интернет, то для вас это действительно бесполезно. Я нет, поэтому мне это возможность очень нужна.
А как быть, если ошибочно?
пояснил
Я на самом деле почитал и не понял для себя преимуществ по сравнению с SVN. Я работаю с двумя программистами над одним проектом, всё лежит на сервере разработки, svn на сервере бэкапится. Вот чем для меня может быть полезнее git? Прочитал, явных преимуществ не нашел, они наверное есть, но если можно, то кратенько поясните их на примере проекта, где есть сервер и нет проблем с интернетом :)
- брэнчи — тут нужно немного перестроиться на другой принцип разработки, но если въехать — очень удобно
- скорость — по крайне мере если репозиторий большой разница заметна
- доступен всегда — (опять же если перестроиться в правильный режим) с гитом делать коммиты можно всегда, когда доступен компьютер (и делать их удобнее — нет медленных запросов в сеть), поэтому comit log получается существенно более читаемый
Спасибо за прекрасный топик! Только что вышел на достаточно стабильный релиз своей системы в SVN. Теперь коммиты идут намного реже, есть время задуматься о другой системе контроля версий. В из ваших слов git подкупает возможностью объединять коммиты (сто раз недокоммичивал забытые файлы) и возможностью коммитить в интерактивном режиме. Не могу сказать, что я знаю хорошо SVN, потому, быть может, это возможно и в ней.
Более того, можете коммитить сколько угодно у себя локально пока работаете над своей частью проекта. И уже когда всё сделали, можете запушить в «основной» репозиторий уже результат. Т.е. распределённая система контроля версий гораздо более удобна при большом числе разработчиков, каждый из которых занимается своей частью. У каждого есть своя история коммитов.
Спасибо за статью. Cheat-sheet вообще отличный!
Насчет локального репозитория — а в чем проблема с SVN его использовать? Если над проектом работаешь один.
Я лично так один проект веду.
Я лично так один проект веду.
Я тоже так раньше делал. Потом попробовал git с его магией бранчей (когда надоели потуги ветвления в svn) и svn стал прошлым днем. Даже несмотря на отсутствие внятного плагина для git под NetBeans. Теперь в git репозитариях у меня хранятся не только проекты, но и многие другие вещи, вплоть до скриптов администрирования, а кое-где даже /etc.
Если бы я использовал git для своего проекта, то уже недели две как сидел бы и писал его с нуля. От внезапного падения винта не так-то просто застраховаться… А svn выручил. (теперь мирроринг ещё дополнительно поставил)
Собственно, это для меня самый важный минус git'а.
Собственно, это для меня самый важный минус git'а.
Это не минус git-а. Что Вам мешает push-ить свой git-репозиторий на какой-нибудь удаленный сервер?
А зачем всё разделять? Куда проще одной командой залить сразу на сервер.
Явно вы ничего не поняли в распределённых системах. На примере mercurial:
$ hg ci
и мы закоммитили локально. В случае чего мы можем очень быстро откатиться на старую версию и найти необходимый кусок.
$ hg push
и наша информация залита на дефолтовый удалённый сервер. Наши изменения сохранены от падения локального винта. При этом даже сервера не нужно запускать на удалённой машине. Всё может быть залито через ssh доступ, если таковой имеется. Единственное требование — на удалённой машине должен тоже быть установлен mercurial. Естественно, ssh не единственный способ пушить на удалённую машину.
Если желаете, можете за'push'ить на любой другой сервер, указав при этом путь к нему и способ соединения.
$ hg ci
и мы закоммитили локально. В случае чего мы можем очень быстро откатиться на старую версию и найти необходимый кусок.
$ hg push
и наша информация залита на дефолтовый удалённый сервер. Наши изменения сохранены от падения локального винта. При этом даже сервера не нужно запускать на удалённой машине. Всё может быть залито через ssh доступ, если таковой имеется. Единственное требование — на удалённой машине должен тоже быть установлен mercurial. Естественно, ssh не единственный способ пушить на удалённую машину.
Если желаете, можете за'push'ить на любой другой сервер, указав при этом путь к нему и способ соединения.
А зачем всё разделять? Куда проще одной командой залить сразу на сервер.
Логично. Просто вам скорее всего сервер и не нужен. Если вы работаете один и надо только бэкапить, то и бэкаптесь локально. А лучше пушайте на сервер время от времени, при этом и никакого другого бэкапа не нужно — ваш локальный репо и удаленный будут идентичны. Проблема svn в том что репо (который содержит всю историю) только один, и ему отдельный бэкап жизненно важен.
Другая проблема коммитов сразу на сервер: собираешься коммитить немаленький рефакторинг, а тебе говорит — сначала upнись, upнешься, получишь конфликты и не сможешь закоммитить пока не починишь/протестируешь всё снова. В распределенной же — коммитишь своё без вопросов (автоматически создастся новая ветвь), а уж потом, когда есть желание и время, сливаешь с оригинальной веткой, тестируешь и заливаешь на сервер.
Уболтали. Попробую. Если интегрируется с svn (на сервере только он есть), то даже попробую внедрить на работе.
GIT-репозиторий легко организуется в рабочей копии SVN, и не мешает её функционировать по-своему.
Перед update/commit SVN-ом приводите GIT-ом рабочую копию в нужное состояние — и апдейтите, если хочется — делаете в GIT новую ветку по результатам, и комитите в SVN. Потом дальше работаете, локально раскладывая разные правки по разным веткам GIT-а.
Перед update/commit SVN-ом приводите GIT-ом рабочую копию в нужное состояние — и апдейтите, если хочется — делаете в GIT новую ветку по результатам, и комитите в SVN. Потом дальше работаете, локально раскладывая разные правки по разным веткам GIT-а.
ну свн репо же где-то лежал не на локальном винте, видимо? вот туда клон гит-репо и положил бы
Причем здесь git и svn? Урок вашей истории в том, что не надо всё держать на одном винте. Если бы svn сервер стоял локально, он бы тоже исчез. А удалённый git репозиторий остался бы нетронутым.
В топике говорится в основном о преимуществах локальных гит-репозиториев.
А они никуда не делись. Вы всегда работаете в локальном репозитории. Но и понимать, что нельзя держать всё в одном месте, тоже надо. Поэтому бэкапы или пушить в удалённый репозиторий. Пушить можно вручную, по крону, а можно автоматически после каждого коммита, тогда будет как-будто в svn. Выбор за вами.
И я надеюсь вы понимаете, что вам крупно повезло, что вы потеряли свой винт, а не тот, на котором был svn-сервер. Пользовались бы гитом, было бы не важно какой винт ушёл, а вот с svn…
И я надеюсь вы понимаете, что вам крупно повезло, что вы потеряли свой винт, а не тот, на котором был svn-сервер. Пользовались бы гитом, было бы не важно какой винт ушёл, а вот с svn…
В mercurial можно просто даже сделать бэкап путём копирования папки .hg и файлов .hg* куда-то ещё прочь от своей машины. Думаю в git аналогично можно. Да и по идее каждый разработчик проекта своеобразный бэкап. Даже если «головной» сервер (именно в кавычках, т.к. его приняли таковым, а не является им как в svn или cvs) потеряется у каждого разработчика всегда есть более или менее свежая версия проекта и общими усилиями можно вполне собрать то, что было до падения сервера.
Недавно начал пользоваться git'ом. Перешел на него с SVN. Очень активно пользуюсь ветками (branches) в своем проекте и пару раз выпадали непонятные ошибки при коммите\мерже, помогал только откат изменений и ввод их заново :( плюс очень не хватало такой фичи как «stash\unstash changes».
Уже 3 месяца — полет нормальный, куча веток, куча коммитов, куча мержей. В общем доволен как слон! )
Уже 3 месяца — полет нормальный, куча веток, куча коммитов, куча мержей. В общем доволен как слон! )
Кстати, на гитхабе есть сервис gist.github.com — как раз для публичного/приватного выкладывания одиночных файлов и фрагментов. Кроме всего, он переваривает разметку Markdown в нормально оформленный html. И комментарии можно оставлять.
Это я к тому, что Ваш cheatsheet и руководство удобнее будет, наверное, туда переложить. (Благо каждый gist — сам себе репозиторий, с версиями и git clone и форками.)
Это я к тому, что Ваш cheatsheet и руководство удобнее будет, наверное, туда переложить. (Благо каждый gist — сам себе репозиторий, с версиями и git clone и форками.)
Очень советую книгу Git Internals от PeepCode
peepcode.com/products/git-internals-pdf
по ссылке она продается за 9$, но я думаю, вы с этим справитесь )
В отличии от других книг по Git, вначале рассказывается как он устроен а затем как им пользоваться.
peepcode.com/products/git-internals-pdf
по ссылке она продается за 9$, но я думаю, вы с этим справитесь )
В отличии от других книг по Git, вначале рассказывается как он устроен а затем как им пользоваться.
Еще есть хороший цикл статей по «внутренностям» git'a
los-t.livejournal.com/tag/git%20guts
los-t.livejournal.com/tag/git%20guts
А пустые папки можно коммитить в git? Или нельзя, как и в mercurial?
Мне кажется, это единственный недостаток последней по сравнению с svn. Сам пользуюсь mercurial ввиду хорошей поддержки в windows. У git'а с этим пока проблемы.
Мне кажется, это единственный недостаток последней по сравнению с svn. Сам пользуюсь mercurial ввиду хорошей поддержки в windows. У git'а с этим пока проблемы.
Можно в папке создать пустой файл с именем ".gitignore" и она успешно закоммиттится.
ИМХО, Windows вообще плохо приспособлена для систем контроля версий. Разве что там есть типовые для него TortoiseXXX проекты. Но установка самого клиента/сервера не очень то приятное занятие, но и не очень сложное.
А Git на сколько я помню детище Линуса, т.е. изначально было ориентировано на пользователей *nix систем. Не удивительно что писатели под Windows особо на неё внимание не обращали.
А Git на сколько я помню детище Линуса, т.е. изначально было ориентировано на пользователей *nix систем. Не удивительно что писатели под Windows особо на неё внимание не обращали.
У статьи есть два существенных недостатка:
1. Как достоинства Git преподносятся достоинства DVCS в целом.
2. Альтернативы среди распределенных систем не рассматриваются.
Например, под Windows git по удобству уступает mercurial, а google-code, которая его поддерживает вряд ли чем-то хуже git-hub.
1. Как достоинства Git преподносятся достоинства DVCS в целом.
2. Альтернативы среди распределенных систем не рассматриваются.
Например, под Windows git по удобству уступает mercurial, а google-code, которая его поддерживает вряд ли чем-то хуже git-hub.
С пунктом 2 не согласен:
GoogleCode в 3 раза менее функционален/удобен Bitbucket`а, который в 2 раза менее функциональнее/удобнее Github`а.
Мне, как пользователю hg, завидно только наличие у git`а такой плюшки, как GitHub.
GoogleCode в 3 раза менее функционален/удобен Bitbucket`а, который в 2 раза менее функциональнее/удобнее Github`а.
Мне, как пользователю hg, завидно только наличие у git`а такой плюшки, как GitHub.
umputun вон с radio-t прикупил какой-то домен типа hg-hub. У него такая же идея возникла. Ну думаю в его силах реально подобное поднять.
А вот это сравнение (googleCode vs Bitbucket vs Github) хотелось бы увидеть в подробностях. В идеале — отдельной статьей. Про сами системы материала хватает, а про их поддержку в сети все куда лаконичнее.
Если будет не сложно, напишите несколько серьезных отличий Google Code (с Mercurial) от Githab'а в плане функциональности.
Просто я только Google Code использовал, и интересное какие «плюшки» есть у github (ну кроме, конечно-же, git)
Просто я только Google Code использовал, и интересное какие «плюшки» есть у github (ну кроме, конечно-же, git)
Как то упущены следующие моменты:
— Ограничение доступа пользователям частью репозитория (в случае огромного проекта)
— Работа над несколькими проектами с общими компонентами
— Разграничение прав доступа к частям проекта
Ну и возможность редактирования истории — настолько страшная вещь, что должна быть немедленно отобрана у всех, кроме одного-двух администраторов центрального репозитория. Об этом тоже ни слова.
— Ограничение доступа пользователям частью репозитория (в случае огромного проекта)
— Работа над несколькими проектами с общими компонентами
— Разграничение прав доступа к частям проекта
Ну и возможность редактирования истории — настолько страшная вещь, что должна быть немедленно отобрана у всех, кроме одного-двух администраторов центрального репозитория. Об этом тоже ни слова.
> Ну и возможность редактирования истории — настолько страшная вещь, что должна быть немедленно отобрана у всех,
Чтобы вы не вводили себя в заблуждение дальше, сразу уточню: легко править локальную историю. Т.е. когда хорошо поработали, а потом решили причесать свои новые коммиты перед пушем на общий сервер.
А вот если править историю на общем репозитории, то, гит так устроен, что каждый девелопер вынужденно об этом узнает (перестанет работать push/pull) и легко найдёт правку просто сравнив свою локальную историю с общей.
Так что всё ок: «закладка» не пролезет, новичёк не испортит историю.
Чтобы вы не вводили себя в заблуждение дальше, сразу уточню: легко править локальную историю. Т.е. когда хорошо поработали, а потом решили причесать свои новые коммиты перед пушем на общий сервер.
А вот если править историю на общем репозитории, то, гит так устроен, что каждый девелопер вынужденно об этом узнает (перестанет работать push/pull) и легко найдёт правку просто сравнив свою локальную историю с общей.
Так что всё ок: «закладка» не пролезет, новичёк не испортит историю.
Про ограничение доступа:
Почитайте эту статью: habrahabr.ru/blogs/Git/75990/
Там автор использует 2 репозитария: 1 — PROD-репо, с ограниченным доступом и второй — песочница для разработчиков.
> Работа над несколькими проектами с общими компонентами
см. git help submodule
В проект можно подключить другие репозитарии как субмодули. Т.е. каждый компонент выделяете в отдельный репозитарий, и подключаете в любых проектах.
Почитайте эту статью: habrahabr.ru/blogs/Git/75990/
Там автор использует 2 репозитария: 1 — PROD-репо, с ограниченным доступом и второй — песочница для разработчиков.
> Работа над несколькими проектами с общими компонентами
см. git help submodule
В проект можно подключить другие репозитарии как субмодули. Т.е. каждый компонент выделяете в отдельный репозитарий, и подключаете в любых проектах.
а можно не весь репозиторий подключать а лишь отдельную папку из него, как в свн? а лучше — отдельный файл
как тогда быть в такой ситуации:
есть несколько проектов использующих модули (модуль = директория). есть библиотека общих модулей.
на свн-е мы делали так: с помощью svn:externals подключали конкретные модули. всё хорошо, но тормозит по страшному. поэтому сделали подключение всей библиотеки в сторонке, а в проекте модули подключали симлинками. но комитить симлинки — это кривой костыль, который к тому же не работает в винде.
есть несколько проектов использующих модули (модуль = директория). есть библиотека общих модулей.
на свн-е мы делали так: с помощью svn:externals подключали конкретные модули. всё хорошо, но тормозит по страшному. поэтому сделали подключение всей библиотеки в сторонке, а в проекте модули подключали симлинками. но комитить симлинки — это кривой костыль, который к тому же не работает в винде.
библиотека постоянно обновляется отдельными людьми. довольно часто. хочется, чтобы можно было просто апнуться, протестировать и выкатить. желательно, чтобы можно было тут же пофиксить багу и запулить в библиотеку
Git-way: один модуль — один репозиторий. Можно конечно объедить группу репозиториев в суперрепозиторий, но обновляться будет не совсем удобно. Не пробовал.
Или положите все в один репозиторий и подключайте ко всем проектам. Я надеюсь ваше приложение позволяет хранить модули, которые не используются.
Или положите все в один репозиторий и подключайте ко всем проектам. Я надеюсь ваше приложение позволяет хранить модули, которые не используются.
Разложите библиотеки по отдельным репозиториям.
В проекты, в которых они нужны, просто вставьте их как submodule.
Должно работать, плюс submodule привязывается не к репозиторию, а к отдельному коммиту. Т.е. возможна такая ситуация:
Когда вы правите библиотеку, не нужно проверять что сломалось, а что нет во всех проектах, которые использую её. Они привязаны к уже проверенным коммитам. А когда будет время можно любой проект перепривязать на свежую версию и тщательно протестить.
В проекты, в которых они нужны, просто вставьте их как submodule.
Должно работать, плюс submodule привязывается не к репозиторию, а к отдельному коммиту. Т.е. возможна такая ситуация:
Lib Project1 Project2 v1 | v1 v2 <--------v1 | v3 <-----------------------v2 v4
Когда вы правите библиотеку, не нужно проверять что сломалось, а что нет во всех проектах, которые использую её. Они привязаны к уже проверенным коммитам. А когда будет время можно любой проект перепривязать на свежую версию и тщательно протестить.
Спасибо за «лайфхак» :)
это типа как в свн привязываться к конкретной ревизии? не, это не удобно — всё-время нужно править привязку вручную. лучше чтобы можно было зайти в модуль, сказать «дай мне свежую версию» и пойти тестировать. или даже зайти в проект и сказать «подтяни-ка свежие версии зависимостей»
Не знаю, как в svn привязывается к ревизии, но в гите всё примерно так, как надо:
Заходишь в submodule а там как в обычном репозитории:
git fetch; git checkout master|branch|tag|revision или git pull
а потом если выйти в родителя, то git diff покажет, что этот сабмодуль перепривязался к новому комиту, а git commit сохранит новую привязку.
Сразу для всех что-то делать можно через git submodule foreach.
Кроме того, чтобы что-то поправить в библиотеке, не надо отдельно её клонировать, править можно прямо в сабмодуле. Там же можно изменения закоммитить и запушить на сервер. А затем закоммитьи и запушить новую привязку в родителе. (только не наоборот!:)
Заходишь в submodule а там как в обычном репозитории:
git fetch; git checkout master|branch|tag|revision или git pull
а потом если выйти в родителя, то git diff покажет, что этот сабмодуль перепривязался к новому комиту, а git commit сохранит новую привязку.
Сразу для всех что-то делать можно через git submodule foreach.
Кроме того, чтобы что-то поправить в библиотеке, не надо отдельно её клонировать, править можно прямо в сабмодуле. Там же можно изменения закоммитить и запушить на сервер. А затем закоммитьи и запушить новую привязку в родителе. (только не наоборот!:)
а если наоборот? а то я сейчас поигрался с сабмодулями, так огрёб какие-то странные конфликты и ругань гитхаба. но сейчас уже всё разрулил.
ещё интересная фича: можно создать репозиторий внутри репозитория х) тогда можно будет делать так сказать «проектные патчи», то есть изменённые в модуле файлы будут коммититься и в модуле и в проекте.
получается так: заходим в модуль, пуллим его, примерживая изменения, тестируем, коммитим проеект. если подредактировали модуль под себя, то для модуля это будут просто локальные изменения, а в проекте их можно и закоммитить.
ещё интересная фича: можно создать репозиторий внутри репозитория х) тогда можно будет делать так сказать «проектные патчи», то есть изменённые в модуле файлы будут коммититься и в модуле и в проекте.
получается так: заходим в модуль, пуллим его, примерживая изменения, тестируем, коммитим проеект. если подредактировали модуль под себя, то для модуля это будут просто локальные изменения, а в проекте их можно и закоммитить.
> а если наоборот?
При работе с сабмодулями есть несколько «как не надо делать», о которых надо знать. Это один из таких моментов. О других можно почитать здесь: book.git-scm.com/5_submodules.html
При работе с сабмодулями есть несколько «как не надо делать», о которых надо знать. Это один из таких моментов. О других можно почитать здесь: book.git-scm.com/5_submodules.html
уломал, ок :)
> вы пробовали пользоваться другими DVCS
Нет не довелось, а на экперименты у меня нет возможностей. Хотя, раз пошла такая пьянка, подниму небольшой проектик на чем-нибудь еще. Но git меня устраивает дальше некуда.
> за использование — оторвать руки по колени. думать нужно, прежде чем коммититься.
Нет, думать нужно прежде чем пушиться. А со своими локальными правками, которых еще никто не видел, я буду делать все, что захочу.
> через пару часов использования git сломал нафиг и локальный
Подскажи рецепт, любопытно.
> Мучался с ребятами 2 недели
Работать полноценно я начал сразу, а вот выработать стратегию командной разработки, мерджа веток. Мы еще тогда начали работать через систему форков и пул-реквестов на гитхабе. Вот пока разобрались со всем и отказались от такого подхода и прошло это время.
> которую не пинал только ленивый
И буду пинать — до черта людей дальше SVN не видят.
> где-то месяца 4 воевал с git
А я не воевал, а радовался во всю. В чем подвох?
> Git — далеко не лучший представитель этого семейства
А почему бы не написать свой обзор? Я бы почитал с удовольствием.
Нет не довелось, а на экперименты у меня нет возможностей. Хотя, раз пошла такая пьянка, подниму небольшой проектик на чем-нибудь еще. Но git меня устраивает дальше некуда.
> за использование — оторвать руки по колени. думать нужно, прежде чем коммититься.
Нет, думать нужно прежде чем пушиться. А со своими локальными правками, которых еще никто не видел, я буду делать все, что захочу.
> через пару часов использования git сломал нафиг и локальный
Подскажи рецепт, любопытно.
> Мучался с ребятами 2 недели
Работать полноценно я начал сразу, а вот выработать стратегию командной разработки, мерджа веток. Мы еще тогда начали работать через систему форков и пул-реквестов на гитхабе. Вот пока разобрались со всем и отказались от такого подхода и прошло это время.
> которую не пинал только ленивый
И буду пинать — до черта людей дальше SVN не видят.
> где-то месяца 4 воевал с git
А я не воевал, а радовался во всю. В чем подвох?
> Git — далеко не лучший представитель этого семейства
А почему бы не написать свой обзор? Я бы почитал с удовольствием.
> А я не воевал, а радовался во всю. В чем подвох?
Вы попробовали git после svn, а develop7 после hg. Ни у hg ни у git-а нет таких сильных преимуществ перед друг-другом, как, например, перед svn, но внутренности достаточно разные. И эта разница диктует немного разный workflow.
Поэтому, обычно получается такая ситуация: программист после svn пробует или git или hg, радуется удивляется новым возможностям и сильно изменяет свой workflow под выбранный DVCS. Он видит, что усилия потраченные на это действие потом окупятся.
Потом программист пробует конкурирующий DCVS, но там крутых плюсов нет, поэтому нет и особой радости, и workflow меняется через немогу (зачем что-то менять, если выгоды не видно?). Программист пытается делать по старому, и натыкается на проблемы, а плюсы не находит потому, что плюсы проявляются в другом, родном для этой системы, workflow. В итоге программист всегда видит у конкурента больше минусов чем плюсов не зависимо от того, с какой DCVS начал ;)
Вот так и получается, что одни ищут легкий hg serve, а другие легкие бранчи и плюются на местные аналоги.
Вы попробовали git после svn, а develop7 после hg. Ни у hg ни у git-а нет таких сильных преимуществ перед друг-другом, как, например, перед svn, но внутренности достаточно разные. И эта разница диктует немного разный workflow.
Поэтому, обычно получается такая ситуация: программист после svn пробует или git или hg, радуется удивляется новым возможностям и сильно изменяет свой workflow под выбранный DVCS. Он видит, что усилия потраченные на это действие потом окупятся.
Потом программист пробует конкурирующий DCVS, но там крутых плюсов нет, поэтому нет и особой радости, и workflow меняется через немогу (зачем что-то менять, если выгоды не видно?). Программист пытается делать по старому, и натыкается на проблемы, а плюсы не находит потому, что плюсы проявляются в другом, родном для этой системы, workflow. В итоге программист всегда видит у конкурента больше минусов чем плюсов не зависимо от того, с какой DCVS начал ;)
Вот так и получается, что одни ищут легкий hg serve, а другие легкие бранчи и плюются на местные аналоги.
Давно уже хочу попробовать Git. Скажите, а как он обращается с бинарными файлами? Я работаю с проектами, в которых используется огромное количество графики. Про SVN я знаю, что она умеет работать с дельтами бинарных файлов (CVS, не к ночи будь помянут, для каждого изменения бинарного файла сохранял его полностью). А вот как с этим делом в Git'e?
В Git нету дельт но есть сжатие. Это обусловлено тем что история нелинейна и дельты очень неудобны в таком случае.
У меня есть аналогичный проект, занимает 100М. Git репозитарий со всей историей занимает не на много больше.
Насколько я знаю, git (как и другая DVCS) не работают с дельтами бинарников. Если в репе есть 100МБ бинарник, то любое его изменение будет добавлять 100МБ к размеру репозитория.
Буду рад если вы опровергнете экспериментом.
Буду рад если вы опровергнете экспериментом.
Звучит, конечно, обнадеживающе. 100М, правда, не так уж много. Проект, с которым я работаю сейчас, занимает полностью, я думаю, порядка 10G, и процентов 90 от этого — разнообразная графика.
Если не сложно, кто-то может рассказать есть ли в GIT возможность форсированного авто-апдейта в какой-то ветке/клоне после пуша в «родительскую»?
В Mercurial что-то подобное можно сделать с помощью хука, которые после пуша удаленно выполняет hg update у «дочерных» веток.
Если интересует зачем, то тут очень просто: хотелось бы повторить фичу такой специфической системы контроля версий, как AccuRev — «streams»(потоки)
Грубо говоря есть:
(двойной линией я пометил те места, где нужен автоматический апдейт при апдейте парента)
use-case: нашли баг, пофиксили в HFWorkspace1, «пушнули» его в hotfix, проверили, запушили в RC, и после этого хотелось бы, чтоб автоматически Development апдейтнулся с RC.
Конечно в таком примере можно и в ручную, но если огромный распределенный (георграфически) проект, есть много комманд, есть много уровней иерархии возникает проблема в автоматизации work-flow изменений.
В AccuRev это реализовано «нативно» под названием «streams» («потоки»), но очень бы хотелось найти хороший аналог в GIT/Mercurial/…
Спасибо заранее, если кто подскажет.
В Mercurial что-то подобное можно сделать с помощью хука, которые после пуша удаленно выполняет hg update у «дочерных» веток.
Если интересует зачем, то тут очень просто: хотелось бы повторить фичу такой специфической системы контроля версий, как AccuRev — «streams»(потоки)
Грубо говоря есть:
RC ══ HotFix ─HFWorkspace1
║ ├─────HFWorkspace2
║ └─────HFWorkspace3
╚════ Development────WS1
├─────────WS2
└─────────WS3
(двойной линией я пометил те места, где нужен автоматический апдейт при апдейте парента)
use-case: нашли баг, пофиксили в HFWorkspace1, «пушнули» его в hotfix, проверили, запушили в RC, и после этого хотелось бы, чтоб автоматически Development апдейтнулся с RC.
Конечно в таком примере можно и в ручную, но если огромный распределенный (георграфически) проект, есть много комманд, есть много уровней иерархии возникает проблема в автоматизации work-flow изменений.
В AccuRev это реализовано «нативно» под названием «streams» («потоки»), но очень бы хотелось найти хороший аналог в GIT/Mercurial/…
Спасибо заранее, если кто подскажет.
Выше давали ссылку на git-flow :) Подойдёт?
Честно говоря немного затрудняюсь даже ответить…
Прочитал Vincent Driessen's branching model — действительно что-то похожее, но про автоматический апдейт child-branch-ей разве что "… so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master."
Кроме того, там структура хоть и похожая, но мало описана ситуация, когда несколько веток, подобных develop/master. Да и feature-* бранчи как-бы независимы до финального мержа.
Основная идея «stream»-ов в AccuRev — это то, что построив правильную иерархию flow-а, изменения автоматически расходятся по этим потокам как только они попадают на уровень, выше от того, с которым работаешь.
Т.е. если ченж, сделанный одной коммандой попадает в hotfix, то при выполнении update из любой ветки (потока), идущего из hotfix на любом уровне вложенности, эти изменения попробуют «влиться» в текущий workspace (и при наличии конфликта будет «deep overlap»).
Еще примерчик, может более показательный:
Если команда девелоперов №8, находящаяся в штате2 в США решит что их код готов пойти на хотфикс, они «пушают» в HotfixUSA2 (локально находящийся у них в штате) и сама система протолкнет в глобальный для США HotfixUSA дальше выше, а от туда уже попадет на все Hotfix* не важно где географически находятся копии.
После этого любой девелопер при update своего workspace с ближайшего Hotfix* получит изменения.
Возможно я пока слишком мало информации нашел, но как такое реализовать с помощью git-flow я пока не нашел. Если такое можно, то можно ссылочку на какой-то вменяемый мануал/howto.
Прочитал Vincent Driessen's branching model — действительно что-то похожее, но про автоматический апдейт child-branch-ей разве что "… so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master."
Кроме того, там структура хоть и похожая, но мало описана ситуация, когда несколько веток, подобных develop/master. Да и feature-* бранчи как-бы независимы до финального мержа.
Основная идея «stream»-ов в AccuRev — это то, что построив правильную иерархию flow-а, изменения автоматически расходятся по этим потокам как только они попадают на уровень, выше от того, с которым работаешь.
Т.е. если ченж, сделанный одной коммандой попадает в hotfix, то при выполнении update из любой ветки (потока), идущего из hotfix на любом уровне вложенности, эти изменения попробуют «влиться» в текущий workspace (и при наличии конфликта будет «deep overlap»).
Еще примерчик, может более показательный:
Hotfix═══HotfixRU─────────DevTeam1─≡ developers
║ └──────────DevTeam2─≡ developers
╠═════HotfixUA─────────DevTeam3─≡ developers
║ └──────────DevTeam4─≡ developers
╚═════HotfixUSA────────DevTeam5─≡ developers
╠══HotfixUSA1─DevTeam6─≡ developers
║ └──DevTeam7─≡ developers
╚══HotfixUSA2─DevTeam8─≡ developers
Если команда девелоперов №8, находящаяся в штате2 в США решит что их код готов пойти на хотфикс, они «пушают» в HotfixUSA2 (локально находящийся у них в штате) и сама система протолкнет в глобальный для США HotfixUSA дальше выше, а от туда уже попадет на все Hotfix* не важно где географически находятся копии.
После этого любой девелопер при update своего workspace с ближайшего Hotfix* получит изменения.
Возможно я пока слишком мало информации нашел, но как такое реализовать с помощью git-flow я пока не нашел. Если такое можно, то можно ссылочку на какой-то вменяемый мануал/howto.
Я так понимаю, все это у вас отдельные репозитории, а не ветки?
Тогда я не думаю, что это возможно сделать встроенными средствами. Общаться между репами, это к админам.
Такое, как вы заметили, легко делается хуками в меркуриале. Только почему вас смущает это решение? Хуки, это не костыли, а вполне полезные приспособления.
А вообще, странный у вас воркфлов, вот и все )
Тогда я не думаю, что это возможно сделать встроенными средствами. Общаться между репами, это к админам.
Такое, как вы заметили, легко делается хуками в меркуриале. Только почему вас смущает это решение? Хуки, это не костыли, а вполне полезные приспособления.
А вообще, странный у вас воркфлов, вот и все )
Ну, я надеялся, кто-то это уже сделал и не надо изобретать велосипед. Пока все что я нашел, это одно предложение из FAQ по меркуриалу. Но работа с хуками довольно сильно усложняется когда
а) есть возможность недоступности одного из серверов, на которых лежит репозитарий (ветка/клон/stream).
б) разные ОС на «перевалочных» станциях (типа HotfixUA — Windows, Hotfix — Linux) :)
А чем же странный? Довольно сложный — да, но обусловлен тем, что есть несколько команд разбросанных географически, распределенная система контроля версий и работа идет над одним проектом одновременно (т.е. все разработчики должны иметь максимально up-to-date состояние системы). Действительно иногда при отслеживании base возникают сложности — те же упомянутые deep overlapы, underlapы и прочие злые «лапы», но пока я не вижу разумной альтернативы.
Разве что действительно пытаться организовать систему хуков с поддержкой fail-over.
Просто такой workflow предполагается AccuRev, c которым уже работаем, но в целом заинтересованны в том, чтоб попробовать другую VCS (так, как количество команд растет, а цены у AccuRev довольно кусючие).
а) есть возможность недоступности одного из серверов, на которых лежит репозитарий (ветка/клон/stream).
б) разные ОС на «перевалочных» станциях (типа HotfixUA — Windows, Hotfix — Linux) :)
А чем же странный? Довольно сложный — да, но обусловлен тем, что есть несколько команд разбросанных географически, распределенная система контроля версий и работа идет над одним проектом одновременно (т.е. все разработчики должны иметь максимально up-to-date состояние системы). Действительно иногда при отслеживании base возникают сложности — те же упомянутые deep overlapы, underlapы и прочие злые «лапы», но пока я не вижу разумной альтернативы.
Разве что действительно пытаться организовать систему хуков с поддержкой fail-over.
Просто такой workflow предполагается AccuRev, c которым уже работаем, но в целом заинтересованны в том, чтоб попробовать другую VCS (так, как количество команд растет, а цены у AccuRev довольно кусючие).
Подборка cheat sheet по git devcheatsheet.com/tag/git/
И еще один zrusin.blogspot.com/2007/09/git-cheat-sheet.html
И еще один zrusin.blogspot.com/2007/09/git-cheat-sheet.html
Если репозитории локальны, то как происходит их синхронизация? Нужен сервер с главным репозиторием?
Можно p2p, можно с сервером. Как вам будет удобнее.
Даже если этот другой за NAT? В файлообменниках я, сидя за нат, могу качать с тех кто с белым IP, и они с меня также. С меня сможет коллега выкачать репозиторий, если у него есть белый ip, а у меня нет?
«а вдруг у другого компьютер будет выключен?» зачем себе лишние проблемы выдумывать? есть git/hg bundle и еще десяток способов обменяться коммитами. лучше всего, конечно, общий репозиторий
Это не выдуманные проблемы, а реальная ситуация.
Всё-таки приходим к ттму, что даже в распределенной системе, нужен центральный (мастер) узел?
Всё-таки приходим к ттму, что даже в распределенной системе, нужен центральный (мастер) узел?
откуда такой вывод? технически не нужен — каждый репозиторий самодостаточен, организационно — зависит от воркфлоу.
>откуда такой вывод?
>лучше всего, конечно, общий репозиторий
:)Технически-то понятно, что не нужен (за исключением особо редких случаев, типа все за нат), но ведь это не 'настоящий' p2p как если бы одна копия основного (не локального) репозитория была бы распределена на всех и в случае если интернет умрет у каждого будет последняя копия
>лучше всего, конечно, общий репозиторий
:)Технически-то понятно, что не нужен (за исключением особо редких случаев, типа все за нат), но ведь это не 'настоящий' p2p как если бы одна копия основного (не локального) репозитория была бы распределена на всех и в случае если интернет умрет у каждого будет последняя копия
В отличие от p2p торрентового в репозах не может быть канонической финальной версии файла или проекта, которая гарантированно есть хотя бы у нескольких участников «роя».
Значит, все же желателен некий центральный узел обмена. В случае утери узла — все равно можно восстановиться из любого другого репоза, либо считать любой другой репоз центральным. В равнозначности такой гипотетической возможности для любого репоза и заключается распределенность DVCS.
Опять же, можно организовать кольцевую или древовидную схему схему обмена изменениями, но это просто-напросто не очень нужно, если верить моему опыту.
Значит, все же желателен некий центральный узел обмена. В случае утери узла — все равно можно восстановиться из любого другого репоза, либо считать любой другой репоз центральным. В равнозначности такой гипотетической возможности для любого репоза и заключается распределенность DVCS.
Опять же, можно организовать кольцевую или древовидную схему схему обмена изменениями, но это просто-напросто не очень нужно, если верить моему опыту.
Ну вот как-то раздаю за натом арч, генту и убунту :) На самом деле многие p2p сети допускают скачивание с человека сидящего за натом или просто с закрытыми портами. Как вы правильно сказали, в таком случае сессию инициирую я, личеры регятся на сервере, а я получаю с него их айпишники и инициирую сессию для своей раздачи (возможно ещё какие механизмы есть, например айпишники личеров мне скидывают другие личеры, но хоть один айпишник я должен получить с сервера, чтобы я мог к нему стукнуться и сообщить о готовности раздавать). Подобного механизма (не я закачиваю, а с меня скачивают, но сессию инициирую я) в гит нет?
Ну какие могут быть у Git конкуренты когда есть GitHub?
Ничего подобного для других распределенных CVS я не видел…
Ничего подобного для других распределенных CVS я не видел…
Не пользовался, выглядит неплохо, интерфейс напоминает гитхабовский. Но уверен, что количество популярных библиотек, лежащих там в разы меньше, и соответственно количество активных девелоперов также меньше. Про качество кода ничего сказать не могу.
Не совсем понятно, как связан размер хостинга репозитариев с качеством кода проектов, на нем находящихся :)
Хостинг и хостинг, разве что раньше прочих объявился и стал поэтому образцовым.
Хостинг и хостинг, разве что раньше прочих объявился и стал поэтому образцовым.
Чем больше количество, тем больше вероятность присутствия качественного кода, если конечно распределение примерно одинаковое. Другое дело, что при таком количестве качественный сложнее найти.
Хостинг хороший и раскрутился раньше других, поэтому популярный и образцовый, да.
Хостинг хороший и раскрутился раньше других, поэтому популярный и образцовый, да.
Ваша задача, если я правильно понимаю, это разложиться на каком-либо хостинге со своим проектом, а не использовать все чужие либы оттуда :)
Для либ/gem-ов сейчас больше популярен Gemcutter. А собственно разработка своих/чужих, да на Github.
Да пофиг :)
Bitbucket — тот же github для hg. От количества либ качество сервиса не становится хуже, к этому, собственно, и веду.
Хотя лично мне для непубличных проектов проще на своем серваке в gitosis докинуть новый репоз и не париться.
Bitbucket — тот же github для hg. От количества либ качество сервиса не становится хуже, к этому, собственно, и веду.
Хотя лично мне для непубличных проектов проще на своем серваке в gitosis докинуть новый репоз и не париться.
code.google.com (Mercurial)
Если вам не нравится github, кстати, можно установить себе на сервер gitorious. Немного геморно устанавливать (где-то час в мануалах/консолях), но оно того стоит. система не так популярна и фичер-рич как github, но opensource и доступна для установки на своем сервере. Github говорят теперь тоже можна установить себе на сервер, правда это будет стоить капусты.
Простите, а репозитАрий — это что?
Это махровая безграмотность :)
Вообще, если в словарь не заглядывать, то «репозиторий» легко написать как «репозитарий», потому как есть «проверочное слово» — «депозитарий». Ещё интереснее, судя по грамота.ру, с кеш/кэш — в орфографическом словаре «кеш», а в Большом толковом — «кэш». «Хороша русская языка» — как хочешь, так пиши :)
>Это классная платформа, где можно бесплатно разместить и опубликовать свой репозиторий.
Если не ошибаюсь, то бесплатно можно разместить только открытый код (до 300 Мб общим объёмом на аккаунт), за 7$ в месяц 5 закрытых репозиториев и 600Мб (да ещё трудности с оплатой, только кредиткой). Есть ли публичные бесплатные хостинги, где можно разместить закрытый код?
Собственно гит «вынуждено» заинтересовал, потому что всё больше проектов, которые использую, хостятся на гитхаб и заниматься интеграцией их в свн не хочется (сейчас просто копирую файлы из локального клона гитхаб, котором сам никогда ничего не изменяю, в каталоги под управлением свн, игнорируя .git*, а дальше они уже свн управляются, но заморочно это, после каждого обновления надо каталоги очищать, копировать, добавлять/удалять в свн), а так бранчи/мержи фактически не используем, у меня свои каталоги, у дизайнера/верстальщика/js-кодера свои, коммитим только то, что пойдёт на боевой сервер (параллельных версий реализаций нет, «триальные» держим локально, показываем друг другу и заказчику сторонними способами — от почты до дев-сервера, если откинуты, то просто удаляются (или копируются куда-нибудь в «заначку»)
Если не ошибаюсь, то бесплатно можно разместить только открытый код (до 300 Мб общим объёмом на аккаунт), за 7$ в месяц 5 закрытых репозиториев и 600Мб (да ещё трудности с оплатой, только кредиткой). Есть ли публичные бесплатные хостинги, где можно разместить закрытый код?
Собственно гит «вынуждено» заинтересовал, потому что всё больше проектов, которые использую, хостятся на гитхаб и заниматься интеграцией их в свн не хочется (сейчас просто копирую файлы из локального клона гитхаб, котором сам никогда ничего не изменяю, в каталоги под управлением свн, игнорируя .git*, а дальше они уже свн управляются, но заморочно это, после каждого обновления надо каталоги очищать, копировать, добавлять/удалять в свн), а так бранчи/мержи фактически не используем, у меня свои каталоги, у дизайнера/верстальщика/js-кодера свои, коммитим только то, что пойдёт на боевой сервер (параллельных версий реализаций нет, «триальные» держим локально, показываем друг другу и заказчику сторонними способами — от почты до дев-сервера, если откинуты, то просто удаляются (или копируются куда-нибудь в «заначку»)
> 7$ в месяц 5 закрытых репозиториев и 600Мб (да ещё трудности с оплатой, только кредиткой)
Я плачу 200 руб в мес и не напрягаюсь. Кредитка? Это разве проблема?
Можно сделать по-другому: положить репо на публичный сервер и ходить к нему по SSH.
И как-то непонятно у вас организована командная работа. Я не могу оценить, но думаю, что можно сделать лучше.
Я плачу 200 руб в мес и не напрягаюсь. Кредитка? Это разве проблема?
Можно сделать по-другому: положить репо на публичный сервер и ходить к нему по SSH.
И как-то непонятно у вас организована командная работа. Я не могу оценить, но думаю, что можно сделать лучше.
Проблема, особенно если платить от юрлица, да и так или в банках толкаться. или на другой конец города ехать. где банкоматы есть принимащие дееьги
да сутт нн в том как ходитт, а чтод для других будет открыт, далеео немвсем заказчикам это нравится
команда два челлвека ) может и можно лучше но проблем пока нн испытываем один и ттт же файл два человека не будут редакттррвать из-за распределения обязанностей — я в браузерную часть нн лезу, он в серверную
пс. сорри за ошибки — с маленькой экранной кавы пишу
да сутт нн в том как ходитт, а чтод для других будет открыт, далеео немвсем заказчикам это нравится
команда два челлвека ) может и можно лучше но проблем пока нн испытываем один и ттт же файл два человека не будут редакттррвать из-за распределения обязанностей — я в браузерную часть нн лезу, он в серверную
пс. сорри за ошибки — с маленькой экранной кавы пишу
Попробуйте unfuddle.com. Там есть возможность бесплатно создавать git-репозитории, но для бесплатного плана есть ряд ограничений
Кто бы написал про проблемы git? Все у нас почему-то однобоко. Вышла новая технология, пару гиков написало «чуваки, это круто, я теперь бед не знаю!» и понеслось, саксесс стори одни, ну не бывает только плюсы, вот так жизнь устроена!
ну, мне тоже так кажется. вышла svn, пару гиков попробовали, круто говорят, атомарные коммиты какие-то и прочая дребедень и все побежали на нее. чего им на cvs не сиделось? а ведь у svn не только плюсы были
Знаменитейшие из минусов:
а) некоторая неинтуитивность команд
б) нельзя пустые директории закидывать
в) когда-то было мало доков ибо творцам когда-то было некогда
г) неудобно хранить большие бинарные файлы
а) некоторая неинтуитивность команд
б) нельзя пустые директории закидывать
в) когда-то было мало доков ибо творцам когда-то было некогда
г) неудобно хранить большие бинарные файлы
а Джоел Спольски говорит, что лучшая open-source система контроля версий — это Mercurial :)
ссылка неправильная. Вот конкретно про Mercurial: http://hginit.com
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему Git