LINUX.ORG.RU

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

 ,


1

1

В общем есть задача:

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

В общем пара вопросов:

1)какую систему лучше использовать для такой работы, git или mercurial? 2)допустим некто «А» работает над своей веткой и хочет слить свою и master, но некто «Б» за час до этого уже слил свою ветку с master и получилось, что у «А» устаревшая копия, как в таком случае стоит поступать? может сделать какой-нибудь скрипт, кторый перед merge переключается на главную, делает pull, и сливает ветки? где легче это разрулить в git or mercurial? 3)они работают с Yii2, как там с поддержкой git, просто ли все это настроить без всяких уродливых костылей? 4) кто-нибудь переносил проект с mercurial на git, можете что-то посоветовать?

В общем любые советы, идеи и т.д. принимаются охотно и с радостью :)

Спасибо.

★★★

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

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

I-Love-Microsoft ★★★★★ ()

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

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

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

Mercurial.

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

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

IvanR ★★★ ()
Ответ на: комментарий от I-Love-Microsoft

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

IvanR ★★★ ()

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

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

mashina ★★★★★ ()
Ответ на: комментарий от IvanR

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

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

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

IvanR ★★★ ()
Ответ на: комментарий от IvanR

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

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

tailgunner ★★★★★ ()

есть несколько веб разработчиков, у каждого своя ветка и свой собственный тестовый хост, планируется так, каждый работает со своей веткой на своем хосте и в случае, если готов сделать коммит, то сливает свою с 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.

slovazap ★★★★★ ()
Ответ на: комментарий от IvanR

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

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

Kiborg ★★★ ()
Последнее исправление: Kiborg (всего исправлений: 1)
Ответ на: комментарий от IvanR

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

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

I-Love-Microsoft ★★★★★ ()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)

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

Deleted ()
Ответ на: комментарий от Deleted

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

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

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от anonymous

a-successful-git-branching-model

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

bj ()

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

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

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

littlechris ★★★ ()

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

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

k_andy ★★★ ()

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

waker ★★★★★ ()
Ответ на: комментарий от anonymous

rebase и pull-request.

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

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

bj ()
Ответ на: комментарий от tailgunner

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

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

bj ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.