помогите с настройкой системой контроля версий

На ЛОРе один совет - сделать вдоль.

А по теме, гит в руки и вперед. http://progit.org/book/ru/ хорошая книга.

Советую попробовать ОБЕ. Именно так я и поступил - какая система была проще в изучении необходимого уровня - ту и выбрал. Я выбрал Mercurial + http://tortoisehg.bitbucket.org

Есть такой механизм: http://mercurial.selenic.com/wiki/Subrepository - каждый будет юзать свой кусок репозитория с удобной ему системой версий.

каждый работает со своей веткой на своем хосте и в случае, если готов сделать коммит, то сливает свою с master.

Это звучит очень странно.

какую систему лучше использовать для такой работы, git или mercurial?

Mercurial.

допустим некто «А» работает над своей веткой и хочет слить свою и master, но некто «Б» за час до этого уже слил свою ветку с master и получилось, что у «А» устаревшая копия

Это совершенно штатная ситуация.

может сделать какой-нибудь скрипт, кторый перед merge переключается на главную, делает pull, и сливает ветки?

Нет. Если учитывать все варианты, скрипт получится слишком сложным. «А» должен разрулить ситуацию вручную.

Это звучит очень странно.

вот собственно меня больше всего интересует, как принято организовывать работу, если имеется несколько разработчиков, каким образом их вся работа оказывается в ветке мастер?

мне пришла в голову только такая идея: на сервере ветка мастер, у каждого своя копия мастера и несколько своих веток, где они работают, если нужно сделать коммит, сливают свои наработки с локальной мастер и пушут мастер на сервер.

в общем это не от меня зависит, а от заказчика, хотя ему вроде пофиг, а от себя, с mercurial вообще не знаком, однако что бы не ударить в грязь лицом надо заказчику обрисовать оба варианта :) а там как пойдет :)

OK, тогда главное не подсунуть заказчику git, а то бить потом будет :)

именно это я и собираюсь сделать :)

чем он так плох-то ?

какую систему лучше использовать для такой работы..

Какая больше нравится. git, конечно же, лучше и удобнее.

как принято организовывать работу, если имеется несколько разработчиков, каким образом их вся работа оказывается в ветке мастер?

Имеется общая ветка или репозиторий (ты ее называешь мастер);

• у каждого разработчика есть своя ветка или репозиторий;
• разработчик получает задачу, разбивает ее на этапы и начинает выполнять;
• после того, как он считает задачу выполненной, он публикует набор ченджсетов (пушит в заранее оговоренный репозиторий и/или делает pull request);
• старший группы делает ревью кода и либо допускает его к мержу, либо возвращает его на доработку;
• если код прошел ревью, то он мержится в мастер-ветку (репозиторий) - это может делать старший группы или сам разработчик.

В Mercurial это делается с помощью mq и Kallithea (слегка пропатченной, желательно), в git - ХЗ.

И почитай какую-нибудь мурзилку о DVCS.

я так понимаю, что

у каждого разработчика есть своя ветка или репозиторий;

имеется в виду, что каждый из разработчиков сделал себе git clone? в общем более или менее ясно, что все равно придется завтра импровизировать :) спасибо большое

имеется в виду, что каждый из разработчиков сделал себе git clone?

Например. Но, вообще говоря, схема с pull request и ревью более сложная.

есть несколько веб разработчиков, у каждого своя ветка и свой собственный тестовый хост, планируется так, каждый работает со своей веткой на своем хосте и в случае, если готов сделать коммит, то сливает свою с master

А центральный-то репозиторий есть? В любом случае, не вижу никаких проблем. У разработчика в его локальном репозитории настроены два remote - на тестовый сервер и на основной. Чтобы протестировать пушит нужную ветку на тестовый сервер, когда она готова попасть в основной репозиторий - на него. Также никто не запрещает разработчикам тянуть ветки друга с друга или с чужих тестовых серверов, если в этом будет смысл.

1)какую систему лучше использовать для такой работы, git или mercurial?

Ту, которую знают ваши разработчики. По умолчанию, разумеется, git.

2)допустим некто «А» работает над своей веткой и хочет слить свою и master, но некто «Б» за час до этого уже слил свою ветку с master и получилось, что у «А» устаревшая копия

Как всегда и везде - pull, устранение конфликтов если таковые были, push. Это, вообще-то, основная функция VCS, и делается одинаково легко везде. У git, правда, есть свои плюшки типа rerere и стратегий автоматического слияния, но вам они вряд-ли понадобятся.

3)они работают с Yii2, как там с поддержкой git, просто ли все это настроить без всяких уродливых костылей?

Учитывая что она сама разрабатывается в git, и вообще всё сейчас разрабатывается в и работает с git, не представляю зачем могут понадобиться какие-то костыли.

4) кто-нибудь переносил проект с mercurial на git, можете что-то посоветовать?

Есть масса инструментов, например git-hg и hg-git, но работать с ними не приходилось. Зачем это вообще, когда можно сразу работать в git.

Не изобретай колесо.
http://nvie.com/posts/a-successful-git-branching-model/

спасибо, весьма подробно.

Да гит, в общем-то, не плох. Очень даже хорошая штука, просто есть некоторые особенности.

1. Некоторые команды не схожи с аналогами из svn или Mercurial. Может быть минусом для тех, кто прежде работал с svn.
2. Документация. Это настолько мем, что для нее уже даже генератор сделали. К слову, в основном там вполне вменяемая документация, единственное что местами приходится держать в голове довольно много разных сущностей, и поначалу это сбивает с толку.
3. В гит можно не только выстрелить себе в ногу, при особом умении можно... Впрочем, если я буду тут описывать возможные исходы, этот сайт будет заблокирован роскомнадзором. В mercurial что попало в удаленный репозиторий, останется там навсегда, и чтобы отстрелить себе ногу (удалить файлы из коммита или переписать историю), надо где-то взять порох, выплавить пулю, засыпать порох, утрамбовать, вставить пыж, пулю, прицелиться...
4. Меркуриал хранит историю веток. На хабре была какая-то статья с красивой картинкой, поясняющая суть. Возможно, в гите есть какой-то аналог этого, не знаю.
5. Некоторое время назад было не очень с поддержкой Windows. Наверняка сейчас исправлено, но должен сказать что в Mercurial нормальная работа одновременно из Windows и *nix в одном репозитории возможна только если имена всех файлов записаны в ASCII.

Не слушай, они git-фанбои :) Попробуй ОБЕ системы, сам решишь что проще и лучше.

Обращайся за помощью с вопросами по Mercurial - всё подскажу.

Меркуриал для фанатиков из сообщества питона. Если нужно просто работать, а не трахаться с инструментом — выбирай гит.

Если нужно просто работать, а не трахаться с инструментом — выбирай гит.

Псаки на ЛОРе? Как дела в госдепе? Это ж так с ног на голову...

Меркуриал для фанатиков из сообщества питона. Если нужно просто работать, а не трахаться с инструментом — выбирай гит.

Если надо работать, то это как раз Mercurial. Git до сих пор остается транспортом для патчей и не умеет простых вещей вроде нормального отслеживания истории переименования.

a-successful-git-branching-model

Для небольшой команды разработчиков, которая не смогла осилить git за пределами checkout/commit/push/pull. И это неплохо, пожалуй. Только надо постоянно репу от говна чистить.

1. Mercurial. Git с большего подходит, но с ним секса больше, несмотря на большее кол-во, с позволения сказать, пользователей

2. В обоих будет разумнее всего делать rebase своей ветки перед merge. В обоих это просто, но в mercurial rebase нагляднее. А вообще мне видится крайне полезным code review — когда мержит код не автор, а его коллега.

4. Не переносить. Это оправдано в единственном случае — вам абсолютно необходим octopus merge. Для зеркала на гитхабе есть hg-git. Для подтягивания зависимостей с гитхаба есть subrepositories.

Обе системы подходят одинаково. Выбирать приходится по нетехническим крииериям.

4) Я массово переносил кучу репозиториев с hg на git, но делиться тут особо нечем.

hg это поделка для бедоно-фанатиков. конечно же, используй git.

? В эту схему вполне ложатся и rebase и pull-request.

у каждого своя ветка и свой собственный тестовый хост

Зачем? Можно же сделать гораздо проще и красивее.

А по сабжу бери гит.

и можешь почитать про гитфлоу:

http://nvie.com/posts/a-successful-git-branching-model/

http://nvie.com/posts/a-successful-git-branching-model/

Недо^WХабралюди такие одинаковые.

rebase и pull-request.

Бгг. Разработчитские бранчи в удаленной репе это рак, совершенно не приспособленный для удобной коллективной разработки.

Очень печально, что большинство dvcs-хипстоты не умеет в патчи по мылу.

патчи по мылу.

Вперед, в каменный век, емана!

Вперед, в каменный век, емана!

Да, а некоторые пердуны еще и не умеют в нормальные почтовые клиенты.