Здравствуйте, Walker_Tula, Вы писали:

W_T>Добрый день!

W_T>Решили перейти на git. Но столкнулись с вопросом, ответы на которые не получилось найти.

W_T>Структура наших репозиториев:
W_T>главный репозиторий — репозитории разработчиков.

W_T>Вопрос, на который мы не можем найти ответ: как вести разработку новых фич так, чтобы в главном репозитории хранился только один коммит с этой фичей?
W_T>Для одного разработчика этой фичи все ясно. Он разрабатывает локально, делает кучу коммитов, потом делает squash, объединяя их в один и потом делает push. На сервере мусора нет.

W_T>А как поступать в случае, если новую фичу разрабатывает несколько разработчиков?


Хочу обрадовать!
существует книга, в которой все более чем доступно описано!)
http://git-scm.com/book/ru

Здравствуйте, Aikin, Вы писали:

N>>При такой политике — каждый из разработчиков, прежде чем сделать попытку отправки в центральный репозиторий, проверяет его обновления и делает локальный rebase, если было изменение.
A>Как пользоваться ребэйзом я знаю. Но в пределах одной ветки. И этим мы сильно пользуемся.
A>То что ребэйз можно делать всей ветке я как-то не думал. Сейчас узнал и думаю "а нафига?". Пока ничего толкового не приходит в голову. Может потому, что у нас feature-branches практически не используются. В основном у нас бранчи по версиям.

У нас тоже. Но когда ты медленно и печально рисуешь реализацию какой-то фичи в своём рабочем репозитории, а времени на это уходит достаточно много (могут быть недели и месяцы), чтобы не заниматься потом длинной нудной работой именно по слиянию, лучше применять изменения апстрима как можно раньше (то есть когда идёт передышка между приступами собственно реализации). А при выборе между вариантами сделать это явными мержами или ребейзом — я предпочитаю rebase, потому что меньше плетений. Лечить конфликты всё равно нужно.

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