Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
Супер!
Конкретно и по делу!
Конкретно и по делу!
я бы порекомендовал вам воспользоваться git-svn.
и последняя команла в списке git, а не svn
и последняя команла в списке git, а не svn
Всё-таки, GIT довольно труден для понимания и освоения НЕпрограммистами. Под Win практически нет дружелюбного инструментария, совмещение файлов требуют танцев с бубном. Ещё и в связке с SSH. :(
а tortoise git — не? о0
tortoise git — вариант, но мне приходится работать с файлами и делать коммит полностью на удалённой стороне. А это только через терминалы.
git можно использовать как svn — т.е. делать постоянно синхронизацию с одним сервером.
Переключать команду на работу с распределенной scm сразу действительно не стоит — так как в основном мы привыкли к клиент-серверным процессам.
git merge — для слияния — довольно продвинутая система и реально упрощает процесс слияния.
ssh поддержка втроенная…
ниже дам комментарий с моими «домашними» настройками
Переключать команду на работу с распределенной scm сразу действительно не стоит — так как в основном мы привыкли к клиент-серверным процессам.
git merge — для слияния — довольно продвинутая система и реально упрощает процесс слияния.
ssh поддержка втроенная…
ниже дам комментарий с моими «домашними» настройками
Гхм… А зачем git непрограммисту? Ну да, под виндой все не так просто, как при наличии нормальной терминалки, но тут я бы мог порекомендовать присмотреться к Mercurial — то же самое функционально, но есть GUI-шки для винды, интеграция с Eclipse и не нужен ssh что бы поднять сервер.
Не так давно мне пришлось выбирать VCS (DVCS). Просмотрел среди прочего и Mercurial, и Bazaar, и Git. Не было у меня цели всё подряд просматривать. Наоборот, хотелось побыстрее начать работать. Но требования были такие — удобный граф ветвлений-слияний (чего не обеспечил SVN) и бранчевание без отдельных репозиториев (это требование появилось по ходу дела, после знакомства с философией Mercurial).
Вот так и дошёл я до Git. Не то чтобы я ярый виндусоид, с линуксом приходилось работать, но мало и редко. Тем не менее Git я боялся пробовать, наслушавшись, как с ним трудно под виндой. Однако информация несколько устарела. И плагины есть (мне тогда как раз для Eclipse был нужен), и bash консоль в комплекте — удобная вещь.
Кстати, для всех упомянутых мной DVCS графы практически одинаковые по внешнему виду. Сильно отличаются от графов с прямоугольниками (которые используются для CVS и SVN), очень компактны и вместе с тем информативны (в сочетании с таблицей, конечно). Для визуалов (людей, для которые особо ценят зрительное восприятие) — очень советую.
Вот так и дошёл я до Git. Не то чтобы я ярый виндусоид, с линуксом приходилось работать, но мало и редко. Тем не менее Git я боялся пробовать, наслушавшись, как с ним трудно под виндой. Однако информация несколько устарела. И плагины есть (мне тогда как раз для Eclipse был нужен), и bash консоль в комплекте — удобная вещь.
Кстати, для всех упомянутых мной DVCS графы практически одинаковые по внешнему виду. Сильно отличаются от графов с прямоугольниками (которые используются для CVS и SVN), очень компактны и вместе с тем информативны (в сочетании с таблицей, конечно). Для визуалов (людей, для которые особо ценят зрительное восприятие) — очень советую.
Советую поставить еще cygwin в системное окружение.
Получаете bash, grep, md5sum, sha1sum и еще много много всего вкусного :)
dir |grep .exe|wc
:)
Получаете bash, grep, md5sum, sha1sum и еще много много всего вкусного :)
dir |grep .exe|wc
:)
бранчевание без отдельных репозиториев
Это что имеется в виду? Мне казалось, что mercurial-овские бранчи вполне сопоставимы с git-овскими по возможностям. Да, «hg up branch_name» не попытается сделать хитрое слияние целевого бранча, с текущими правками, но в остальном все вроде бы так же.
Это что имеется в виду? Мне казалось, что mercurial-овские бранчи вполне сопоставимы с git-овскими по возможностям. Да, «hg up branch_name» не попытается сделать хитрое слияние целевого бранча, с текущими правками, но в остальном все вроде бы так же.
Разумеется, я смотрел поверхностно, за несколько дней знакомства с каждой VCS многого не узнаешь, но Mercurial — первая DVCS, которую я увидел, с ней я побольше повозился. Если кто-то укажет на мою ошибку — спасибо авансом.
У меня возникло впечатление (и читал, конечно, что пишут про неё, т.е. не только у меня), что копировать весь репозиторий при создании бранча — нормальный режим для Mercurial.
Ни Git, ни SVN, ни CVS ничего подобного не делают. Надо бранч — можно создать его в том же самом репозитории. При переключении на бранч не надо лезть в другую папку. Со многими IDE это неудобно — тут проект закрой, там открой заново. Да и зачем мне на одном компе два полноценных почти одинаковых репозитория, один с веткой, другой без?
У меня возникло впечатление (и читал, конечно, что пишут про неё, т.е. не только у меня), что копировать весь репозиторий при создании бранча — нормальный режим для Mercurial.
Ни Git, ни SVN, ни CVS ничего подобного не делают. Надо бранч — можно создать его в том же самом репозитории. При переключении на бранч не надо лезть в другую папку. Со многими IDE это неудобно — тут проект закрой, там открой заново. Да и зачем мне на одном компе два полноценных почти одинаковых репозитория, один с веткой, другой без?
Нет, все не так ужасно :-) Все практически так же как и в git-е:
hg branch aaa
<мы создали бранч aaa>
…
hg commit -m 'aaa feature'
hg update -C default
<мы вернулись в основной бранч>
hg branch aaa
<мы создали бранч aaa>
…
hg commit -m 'aaa feature'
hg update -C default
<мы вернулись в основной бранч>
Ваша правда, получилось и создать бранч в том же репозитории, и merge сделать, разрулив конфликт, и граф ветвления-слияния получить. Даже не знаю, почему с первого раза были проблемы.
Что ж, когда ещё раз встанет выбор между Mercurial и Git — ещё раз подумаю, что больше подходит в данных условиях. Хорошо, когда есть выбор :)
Что ж, когда ещё раз встанет выбор между Mercurial и Git — ещё раз подумаю, что больше подходит в данных условиях. Хорошо, когда есть выбор :)
Очень кстати пост ) как раз планируем на работе начать использовать систему контроля версий ) обратим внимание на вариант из статьи )
не обратил внимания сначала, это под линь инструменты? под винду нет такого?
для win: code.google.com/p/msysgit/
у меня линукс, и пользуюсь только коммандной строкой, к сожалению не смогу дать советов по работе под windows
когда нужно одновременно попробовать две идеи — нужно создавать две рабочии копии и спокойно их обе пилить, примёрживая друг к другу общие изменения, а не переключаться в бешенном темпе между двумя ветками…
как в svn применить два одинаковых изменения в две рабочии копии?
а при чём тут свн? XD
мне не ясно зачем создавать копию сущности? в смысле есть у меня рабочая копия, зачем мне еще одна…
Тем более не ясно, зачем мне рабочая копия для каждой идеи…
В дополнение к коментарю ниже: из жизни
у меня есть проект, который мы делали месяц, и создали некий release candidate
Показали клиенту, и клиент просит добавить функциональность. Я сразу делаю ветку или несколько. В ней делаю изменение, проверяю и показываю. Если все ок, то я сливаю ветку с основной. Созданные ветки не нужны, их не надо шарить с коммандой. Тут как раз гит и помогает.
Гит позволяет мне отдать изменения только те, что я решу отдать
Тем более не ясно, зачем мне рабочая копия для каждой идеи…
В дополнение к коментарю ниже: из жизни
у меня есть проект, который мы делали месяц, и создали некий release candidate
Показали клиенту, и клиент просит добавить функциональность. Я сразу делаю ветку или несколько. В ней делаю изменение, проверяю и показываю. Если все ок, то я сливаю ветку с основной. Созданные ветки не нужны, их не надо шарить с коммандой. Тут как раз гит и помогает.
Гит позволяет мне отдать изменения только те, что я решу отдать
отдельная рабочая копия = отдельный хост для неё. возможность посмотреть оба варианта, сравнить, показать кому-нибудь. можно быстро примёржить изменения из соседней копии, а не жонглировать ветками. возможность параллельной разработки обоих веток в зависимости от меняющегося тз.
и тд и тп. две директории — гораздо удобнее двух веток.
и тд и тп. две директории — гораздо удобнее двух веток.
«и тд и тп. две директории — гораздо удобнее двух веток.»
Вот по этой фразе, мне кажется, и видно что вы не пробовали, или не распробовали git )
Либо для вашей работы действительно достаточно subversion.
Как пользователь и git и subversion (обе системы в настоящий момент) могу сказать вам, что, ИМХО, вы сильно ошибаетесь. Я начинал с subversion, тем не менее, тащусь от git с тех пор как попробовал его. Вот плюсы веток git над несколькими рабочими копиями subversion:
* возможность вести несколько веток разработки, удобно сливая нужные изменения между ними. Отличия даже сложно описать, все просто совсем иначе нежели в subversion
* возможность сливать в общий репозиторий только нужные изменения
* скорость переключения/порождения веток (все локально, в отличие от subversion)
* при переключении не надо переоткрывать редактор кода и т.п. — ветка сменилась, редактор переспросил «перегрузить?» — крайне удобно
* поддержание читабельной истории изменений
* git стимулирует использование веток и мелких коммитов
В общем, если при управлении репозиторием subversion для меня каждая ветка была «болью», то в git это крайне удобная часть рабочего процесса.
Недостаток git для меня в отсутствии столь рафинированного gui для git+linux как пресловутый tortoise для svn+windows. Точнее, не отстутствие, а некоторая проблемность построения его — необходимо использовать несколько утилит для получения схожего функционала. А может, оно уже и есть, но я о нем не знаю )
Вот по этой фразе, мне кажется, и видно что вы не пробовали, или не распробовали git )
Либо для вашей работы действительно достаточно subversion.
Как пользователь и git и subversion (обе системы в настоящий момент) могу сказать вам, что, ИМХО, вы сильно ошибаетесь. Я начинал с subversion, тем не менее, тащусь от git с тех пор как попробовал его. Вот плюсы веток git над несколькими рабочими копиями subversion:
* возможность вести несколько веток разработки, удобно сливая нужные изменения между ними. Отличия даже сложно описать, все просто совсем иначе нежели в subversion
* возможность сливать в общий репозиторий только нужные изменения
* скорость переключения/порождения веток (все локально, в отличие от subversion)
* при переключении не надо переоткрывать редактор кода и т.п. — ветка сменилась, редактор переспросил «перегрузить?» — крайне удобно
* поддержание читабельной истории изменений
* git стимулирует использование веток и мелких коммитов
В общем, если при управлении репозиторием subversion для меня каждая ветка была «болью», то в git это крайне удобная часть рабочего процесса.
Недостаток git для меня в отсутствии столь рафинированного gui для git+linux как пресловутый tortoise для svn+windows. Точнее, не отстутствие, а некоторая проблемность построения его — необходимо использовать несколько утилит для получения схожего функционала. А может, оно уже и есть, но я о нем не знаю )
Между git checkout master<em/> и git merge idea<em/> не мешало бы сделать svn update<em/>. Если необходимо, разрешить конфликты. Ну а после естественно сделать svn commit<em/>. В этом случае ветка мастер действительно будет отражением svn репозитария.
Между git checkout master и git merge idea не мешало бы сделать svn update. Если необходимо, разрешить конфликты. Ну а после естественно сделать svn commit. В этом случае ветка мастер действительно будет отражением svn репозитария.
PS Больше не буду в 2 часа ночи писать комментарии с тегами с мобльного телефона через оперу мини, не сделав при этом предпросмотр.
PS Больше не буду в 2 часа ночи писать комментарии с тегами с мобльного телефона через оперу мини, не сделав при этом предпросмотр.
Несколько слов о домашней настройке:
у меня есть основной комп, ноутбук и есть простейший хостинг за 5$ в месяц.
Доступ по ssh есть к хостингу и обоим компам.
В основном я работаю на десктопе. В день могу сделать 20 коммитов, и с 10к веток. Раз в день или чуть реже я делаю синхронизацию на сервер.
Периодически, делаю синхр с ноутбуком, но: так как git распределенный, я часто работаю на ноуте, без предварительной синхронизации — если работаю над новой функциональностью. Позже, в локальной сети я делаю push изменений на хостинг или на десктоп.
Еще пользуюсь unfuddle — там можно получить бесплатное место под гит репозиторий.
у меня есть основной комп, ноутбук и есть простейший хостинг за 5$ в месяц.
Доступ по ssh есть к хостингу и обоим компам.
В основном я работаю на десктопе. В день могу сделать 20 коммитов, и с 10к веток. Раз в день или чуть реже я делаю синхронизацию на сервер.
Периодически, делаю синхр с ноутбуком, но: так как git распределенный, я часто работаю на ноуте, без предварительной синхронизации — если работаю над новой функциональностью. Позже, в локальной сети я делаю push изменений на хостинг или на десктоп.
Еще пользуюсь unfuddle — там можно получить бесплатное место под гит репозиторий.
Очень правильная заметка.
P.S. Я вот только пока не придумал, как мне объяснить простым пользователям, что им надо где-то выполнить какие-то команды, чтобы всем этим воспользоваться.
P.S. Я вот только пока не придумал, как мне объяснить простым пользователям, что им надо где-то выполнить какие-то команды, чтобы всем этим воспользоваться.
Интересная заметка, как-то в и в голову не пришло совмещать git и svn; тем более когда есть git-svn. Как-то сразу, без лишних размышлений, на новом проекте развернул систему git-репозитариев и стал пользоваться. Новым приходящим программистам придется просто привыкать :)
Вот всем хорош git, но, хоть убей, мне не очень нравится интерфейс программы для управления удаленным репозитарием. Кто знает, какие есть хорошие комплекты упрощающих скриптов?
Вот всем хорош git, но, хоть убей, мне не очень нравится интерфейс программы для управления удаленным репозитарием. Кто знает, какие есть хорошие комплекты упрощающих скриптов?
я наверное извращенец, я использую svn для шелл скриптов и конфигов :) тоесть синькаю новый тазик с образцовым /usr/local/etc/ и при необходимости добавляю скрипты, на одном сервере подправил скрипт, закомитил, на другом сделал апдейт и все путем :)
Хотел бы отметить минус предложенного решения:
статус каталога (иконка на каталоге ) показывается для гит репозитория, если есть измененные файлы отностительно svn то статус будет «зеленая галочка», т.к. файл не изменён относительно гит репозитория
Выбрать чей статус показывать git или svn нет возможности :(
статус каталога (иконка на каталоге ) показывается для гит репозитория, если есть измененные файлы отностительно svn то статус будет «зеленая галочка», т.к. файл не изменён относительно гит репозитория
Выбрать чей статус показывать git или svn нет возможности :(
немного забыл указать в самой статье:
идея не в том что бы постоянно ислопльзовать гит и свн — так как это просто избыточно
скорее дать возможность сдлеать плавный переход с одной системы на другую
идея не в том что бы постоянно ислопльзовать гит и свн — так как это просто избыточно
скорее дать возможность сдлеать плавный переход с одной системы на другую
На работе приходится использовать похожую связку cvs-git, так как заказчик не дает возможности уйти от цвс.
Досадный недостаток — при уходе в гитовый бранч, редактировании там и последующем возвращении в мастер (т.е. мастер остается нетронутым по смыслу), цвс отображает бранчевые файлы как измененные из-за времени модификации. Неудобно, что они светятся при коммите (хоть по доке от цвс в хистори в конце концов и не попадают).
ИМХО, в статье немножко не хватает описания процесса апдейта гита и свн со стороны свн. Процесс создания гит-репозитория есть, почему этого нет?
ЗЫ: «обЕих систем»На работе приходится использовать похожую связку cvs-git, так как заказчик не дает возможности уйти от цвс.
Досадный недостаток — при уходе в гитовый бранч, редактировании там и последующем возвращении в мастер (т.е. мастер остается нетронутым по смыслу), цвс отображает бранчевые файлы как измененные из-за времени модификации. Неудобно, что они светятся при коммите (хоть по доке от цвс в хистори в конце концов и не попадают).
ИМХО, в статье немножко не хватает описания процесса апдейта гита и свн со стороны свн. Процесс создания гит-репозитория есть, почему этого нет?
ЗЫ: «обЕих систем»
Досадный недостаток — при уходе в гитовый бранч, редактировании там и последующем возвращении в мастер (т.е. мастер остается нетронутым по смыслу), цвс отображает бранчевые файлы как измененные из-за времени модификации. Неудобно, что они светятся при коммите (хоть по доке от цвс в хистори в конце концов и не попадают).
ИМХО, в статье немножко не хватает описания процесса апдейта гита и свн со стороны свн. Процесс создания гит-репозитория есть, почему этого нет?
ЗЫ: «обЕих систем»На работе приходится использовать похожую связку cvs-git, так как заказчик не дает возможности уйти от цвс.
Досадный недостаток — при уходе в гитовый бранч, редактировании там и последующем возвращении в мастер (т.е. мастер остается нетронутым по смыслу), цвс отображает бранчевые файлы как измененные из-за времени модификации. Неудобно, что они светятся при коммите (хоть по доке от цвс в хистори в конце концов и не попадают).
ИМХО, в статье немножко не хватает описания процесса апдейта гита и свн со стороны свн. Процесс создания гит-репозитория есть, почему этого нет?
ЗЫ: «обЕих систем»
Почему бы не воротить огород с двумя SCM, а просто использовать симлинки? Из постановки задачи следует, что нужно иметь под рукой две копии одной версии svn чтобы править их независимо и сравнивать время от времени. Делаем
Настала пора переключиться в идею:
ЗЫ: возможно, я не уловил кайфа git'a для такой простой задачи, но она полностью решается симлинками.
cp -R ACME ACME_idea; mv ACME ACME_master; ln -s ACME_master ACME. В ACME у нас теперь мастер-рабочая-копия, в нее смотрят IDE, веб-сервер и другие заинтересованные личности.Настала пора переключиться в идею:
rm ACME; ln -s ACME_idea ACME;. Заинтересованные личности в восторге.ЗЫ: возможно, я не уловил кайфа git'a для такой простой задачи, но она полностью решается симлинками.
а где лежат файлы? где находится репозиторий?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
GIT для пользователей subversion (и др scm)