История изменений
Исправление Manhunt, (текущая версия) :
rebase решает обе проблемы.
Давай разберем на примере. Есть некая кодовая база, старшему разработчику Джамшуту поручено разработать фичу «Д», ведущему разработчику Равшану поручено разработать фичу «Р».
Без отдельных бранчей:
1. Вторник, Джамшут коммитит ревизию 2 файла file.cpp
3. Среда, Равшан делает svn up, и получает ревизию 2 файла file.cpp
3. Четверг, Равшан коммитит ревизию 3 файла file.cpp
4. Неделю спустя, Равшан завершил разработку фичи «Р»
5. Полторы недели спустя, Джамшут завершил разработку фичи «Д»
В итоге, Равшан и Джамшут друг другу совсем не мешали, не смотря на то, что правили один и тот же file.cpp. Равшан изначально рассматривал этот файл с Джамшутовскими правками.
С отдельными бранчами:
1. Вторник, Джамшут меняет file.cpp у себя
3. Четверг, Равшан меняет file.cpp у себя
4. Неделю спустя, Равшан завершил разработку фичи «Р», и вливает все 5000 строк изменений в 20 файлах в trunk
5. Полторы недели спустя, Джамшут завершил разработку фичи «Д», хочет влить 7000 строк изменений в 30 файлах в trunk, но обаруживает конфликт в file.cpp
В итоге, Равшан и Джамшут еще три дня судорожно курят file.cpp, пытаясь вспомнить что и зачем они там направили, и как теперь эти правки скрестить, чтобы ничего не сломать.
потенциальная дестабилизация общей кодовой базы
Для этого есть continuous integration
Исправление Manhunt, :
rebase решает обе проблемы.
Давай разберем на примере. Есть некая кодовая база, старшему разработчику Джамшуту поручено разработать фичу «Д», ведущему разработчику Равшану поручено разработать фичу «Р».
Без отдельных бранчей:
1. Вторник, Джамшут коммитит ревизию 2 файла file.cpp
3. Среда, Равшан делает svn up, и получает ревизию 2 файла file.cpp
3. Четверг, Равшан коммитит ревизию 3 файла file.cpp
4. Неделю спустя, Равшан завершил разработку фичи «Р»
5. Полторы недели спустя, Джамшут завершил разработку фичи «Д»
В итоге, Равшан и Джамшут друг другу совсем не мешали, не смотря на то, что правили один и тот же file.cpp. Равшан изначально рассматривал этот файл с Джамшутовскими правками.
С отдельными бранчами:
1. Вторник, Джамшут меняет file.cpp у себя
3. Четверг, Равшан меняет file.cpp у себя
4. Неделю спустя, Равшан завершил разработку фичи «Р», и вливает все 5000 строк кода в 20 файлах в trunk
5. Полторы недели спустя, Джамшут завершил разработку фичи «Д», хочет влить 7000 строк кода в 30 файлах в trunk, но обаруживает конфликт в file.cpp
В итоге, Равшан и Джамшут еще три дня судорожно курят file.cpp, пытаясь вспомнить что и зачем они там направили, и как теперь эти правки скрестить, чтобы ничего не сломать.
потенциальная дестабилизация общей кодовой базы
Для этого есть continuous integration
Исправление Manhunt, :
rebase решает обе проблемы.
Давай разберем на примере. Есть некая кодовая база, старшему разработчику Джамшуту поручено разработать фичу «Д», ведущему разработчику Равшану поручено разработать фичу «Р».
Без отдельных бранчей:
1. Вторник, Джамшут коммитит ревизию 2 файла file.cpp
3. Среда, Равшан делает svn up, и получает ревизию 2 файла file.cpp
3. Четверг, Равшан коммитит ревизию 3 файла file.cpp
4. Неделю спустя, Равшан завершил разработку фичи «Р»
5. Полторы недели спустя, Джамшут завершил разработку фичи «Д»
В итоге, Равшан и Джамшут друг другу совсем не мешали, не смотря на то, что правили один и тот же file.cpp. Равшан изначально рассматривал этот файл с Джамшутовскими правками.
С отдельными бранчами:
1. Вторник, Джамшут меняет file.cpp у себя
3. Четверг, Равшан меняет file.cpp у себя
4. Неделю спустя, Равшан завершил разработку фичи «Р», и вливает все 5000 строк кода в 20 файлах в trunk
5. Полторы недели спустя, Джамшут завершил разработку фичи «Д», хочет влить 7000 строк кода в 30 файлах trunk, но обаруживает конфликт в file.cpp
В итоге, Равшан и Джамшут еще три дня судорожно курят file.cpp, пытаясь вспомнить что и зачем они там направили, и как теперь эти правки скрестить, чтобы ничего не сломать.
потенциальная дестабилизация общей кодовой базы
Для этого есть continuous integration
Исходная версия Manhunt, :
rebase решает обе проблемы.
Давай разберем на примере. Есть некая кодовая база, старшему разработчику Джамшуту поручено разработать фичу «Д», ведущему разработчику Равшану поручено разработать фичу «Р».
Без отдельных бранчей:
1. Вторник, Джамшут коммитит ревизию 2 файла file.cpp
3. Среда, Равшан делает svn up, и получает ревизию 2 файла file.cpp
3. Четверг, Равшан коммитит ревизию 3 файла file.cpp
4. Неделю спустя, Равшан завершил разработку фичи «Р»
5. Полторы недели спустя, Джамшут завершил разработку фичи «Д»
В итоге, Равшан и Джамшут друг другу совсем не мешали, не смотря на то, что правили один и тот же file.cpp. Равшан изначально рассматривал этот файл с Джамшутовскими правками.
С отдельными бранчами:
1. Вторник, Джамшут меняет file.cpp у себя
3. Четверг, Равшан меняет file.cpp у себя
4. Неделю спустя, Равшан завершил разработку фичи «Р», и вливает все 5000 строк кода в trunk
5. Полторы недели спустя, Джамшут завершил разработку фичи «Д», хочет влить 7000 строк кода в trunk, но обаруживает конфликт в file.cpp
В итоге, Равшан и Джамшут еще три дня судорожно курят file.cpp, пытаясь вспомнить что и зачем они там направили, и как теперь эти правки скрестить, чтобы ничего не сломать.
потенциальная дестабилизация общей кодовой базы
Для этого есть continuous integration