VCS: внедрение в работу

[Вурдалак]

Да как вообще можно жить без stash, cherry-pick, rebase, локальных бранчей, etc. Ты застрял где-то в 2006.

 

[MiksIr]

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

 

[fixxxer]

Да как вообще можно жить без stash, cherry-pick, rebase, локальных бранчей, etc. Ты застрял где-то в 2006.

Ну, stash, справедливости ради, довольно банальная вещь и делается шелл-скриптом в одну строку. А вот остальное, да.

 

[MiksIr]

Да как вообще можно жить без stash, cherry-pick, rebase, локальных бранчей, etc. Ты застрял где-то в 2006.

Элементарно. Хотя я забыл, что на этом форуме все как минимум новый Гугл пишут в команде из десятков разработчиков. Уж извините нас убогих, которым эти фичи просто не нужны.

 

[AnrDaemon]

У нас такое разделение:
- дизайн, тут CVS думаю не нужна;
- верстка, CVS возможно нужна, но ...;
- программирование, обычно над проектом работает один программист, но как выше уже сказали CVS нужна.

Мне не совсем ясно, если к примеру с CVS будет работать верстальщик и потом передавать работу программисту, как организовать этот переход? По сути это два разных проекта.

Или я наверно перегибаю и верстку вовсе не надо размещать в CVS?

Есть хорошая книжка. http://svnbook.org/
C примерами и пояснениями.

P.S.
Заколебали со своим гитом.

 

[Вурдалак]

MiksIr, да ты нуб ищо, подрастёшь — поймёшь. Учись, сынок.

AnrDaemon, SVN — говно.

 

[fixxxer]

Элементарно. Хотя я забыл, что на этом форуме все как минимум новый Гугл пишут в команде из десятков разработчиков. Уж извините нас убогих, которым эти фичи просто не нужны.

Это так кажется, что не нужны, пока не начнешь пользоваться.

 

[MiksIr]

Это так кажется, что не нужны, пока не начнешь пользоваться.

А можно реальные примеры.
Берем транк и feature ветки, у каждой ветки один свой разработчик, 1-3 ветки в работе, время жизни ветки - неделя. Удаленных разработчиков нет.
Какие плюсы даст git, какие проблемы он решит.

 

[hell0w0rd]

MiksIr, сервер упал - разработка накрылась.

 

[Вурдалак]

Ну, stash — ноу комментс. Тебя попросили что-то поправить (если вместе с client side в одной ветке работаешь, а он что-то нашёл), ты переключаешься и правишь.
cherry-pick — банально если понимаешь, что какое-то мелкое изменение (типа нового event'а) можно выкатить раньше, чем остальные изменения в бранчах; либо понимаешь, что в соседнем бранче нужно точно такое же изменение. Но это имеет смысл, если делается ряд мелких коммитов, а не один огромный.
rebase — ну, стоит, например, хук на cs. Хук не пропускает твой пуш, ты, я не знаю, использовал underscore вместо camelCase. Чтобы в итоге в history не видеть твой бесполезный commit «fix cs», ты делаешь git commit --amend, то есть частный случай rebase'а, потом пушишь. Объединения нескольких коммитов в один, подтаскивание изменений из master'а без merge commit в history и т.д. На github'е при оформлении PR очень полезная хрень, никому нахрен неинтересны твои мержи, там нужно ребейзить.
Локальные бранчи — ну, хочу запилить proof-of-concept, знать об этом никому необязательно. Могу это делать где угодно, не парясь, что нет доступа к центральной репе.

 

[MiksIr]

MiksIr, сервер упал - разработка накрылась.

Электричество кончилось - разработка накрылась. Пожар - разработка накрылась. Не, не аргумент.
>Ну, stash — ноу комментс. Тебя попросили что-то поправить (если вместе с client side в одной ветке работаешь, а он что-то нашёл), ты переключаешься и правишь.
PhpStorm -> shelve changes

>cherry-pick — банально если понимаешь, что какое-то мелкое изменение (типа нового event'а) можно выкатить раньше, чем остальные изменения в бранчах; либо понимаешь, что в соседнем бранче нужно точно такое же изменение.
Ну выкатить раньше - это врядли, если нужно, то скорее всего задача была слишком глобальна, но в общем ничего не мешает смержить часть коммитов из ветки в транк - самое серьезное, что можно огребсти, это легко решаемый конфликт при последующем сливе ветки в транк.
А вот между ветками - да. Если много разработчиков, много веток. В реальности - у меня такой кейс был один раз за год. Запомнил именно потому, что svn не умеет ветки с одинаковыми изменениями нормально мержить между собой.

> rebase — ну, стоит, например, хук на cs. Хук не пропускает твой пуш, ты, я не знаю, использовал underscore вместо camelCase. Чтобы в итоге в history не видеть твой бесполезный commit «fix cs», ты делаешь git commit --amend, то есть частный случай rebase'а, потом пушишь. Объединения нескольких коммитов в один, подтаскивание изменений из master'а без merge commit в history и т.д. На github'е при оформлении PR очень полезная хрень, никому нахрен неинтересны твои мержи, там нужно ребейзить.
Ну вот сами обозначили основной случай. Ну более чистое history - дело полезное, но не критичное, особо при внутренней разработке, где никого особо не волнуют коммиты внутри ветке - волнует окончательный diff с транком для код-ревью.

>Локальные бранчи — ну, хочу запилить proof-of-concept, знать об этом никому необязательно. Могу это делать где угодно, не парясь, что нет доступа к центральной репе.
Доступа не может не быть, все в офисе.

 

[Активист]

Электричество кончилось - разработка накрылась. Пожар - разработка накрылась. Не, не аргумент.
>Ну, stash — ноу комментс. Тебя попросили что-то поправить (если вместе с client side в одной ветке работаешь, а он что-то нашёл), ты переключаешься и правишь.
PhpStorm -> shelve changes

>cherry-pick — банально если понимаешь, что какое-то мелкое изменение (типа нового event'а) можно выкатить раньше, чем остальные изменения в бранчах; либо понимаешь, что в соседнем бранче нужно точно такое же изменение.
Ну выкатить раньше - это врядли, если нужно, то скорее всего задача была слишком глобальна, но в общем ничего не мешает смержить часть коммитов из ветки в транк - самое серьезное, что можно огребсти, это легко решаемый конфликт при последующем сливе ветки в транк.
А вот между ветками - да. Если много разработчиков, много веток. В реальности - у меня такой кейс был один раз за год. Запомнил именно потому, что svn не умеет ветки с одинаковыми изменениями нормально мержить между собой.

> rebase — ну, стоит, например, хук на cs. Хук не пропускает твой пуш, ты, я не знаю, использовал underscore вместо camelCase. Чтобы в итоге в history не видеть твой бесполезный commit «fix cs», ты делаешь git commit --amend, то есть частный случай rebase'а, потом пушишь. Объединения нескольких коммитов в один, подтаскивание изменений из master'а без merge commit в history и т.д. На github'е при оформлении PR очень полезная хрень, никому нахрен неинтересны твои мержи, там нужно ребейзить.
Ну вот сами обозначили основной случай. Ну более чистое history - дело полезное, но не критичное, особо при внутренней разработке, где никого особо не волнуют коммиты внутри ветке - волнует окончательный diff с транком для код-ревью.

>Локальные бранчи — ну, хочу запилить proof-of-concept, знать об этом никому необязательно. Могу это делать где угодно, не парясь, что нет доступа к центральной репе.
Доступа не может не быть, все в офисе.

http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html