Решили перейти на git. Но столкнулись с вопросом, ответы на которые не получилось найти.
Структура наших репозиториев:
главный репозиторий — репозитории разработчиков.
Вопрос, на который мы не можем найти ответ: как вести разработку новых фич так, чтобы в главном репозитории хранился только один коммит с этой фичей?
Для одного разработчика этой фичи все ясно. Он разрабатывает локально, делает кучу коммитов, потом делает squash, объединяя их в один и потом делает push. На сервере мусора нет.
А как поступать в случае, если новую фичу разрабатывает несколько разработчиков?
Здравствуйте, Walker_Tula, Вы писали:
W_T>А как поступать в случае, если новую фичу разрабатывает несколько разработчиков?
Последний разработчик сделает squash.
Здравствуйте, Walker_Tula, Вы писали:
W_T>На сервере мусора нет.
Offtop: в случае нескольких разработчиков это не мусор, а ценное знание, которое через пару лет может очень сильно помочь
W_T>А как поступать в случае, если новую фичу разрабатывает несколько разработчиков?
1. Разработка фичи идёт в отдельной ветке (назовём её dev)
2. После того как разработка закончена, кто-то делает squash всем коммитам и этот один коммит помещается в master
3. Ветка dev удаляется с сервера. (Ахтунг! Переписывание истории, обычно это запрещают делать для опубликованных веток, но если очень хочется то можно)
Offtop: непонятно, зачем терять полезную информацию о промежуточных коммитах. Если всё слить вместе, то некоторые изменения могут казаться загадочными.
Здравствуйте, Константин, Вы писали:
К>2. После того как разработка закончена, кто-то делает squash всем коммитам и этот один коммит помещается в master
Почему не merge? Тут на сайте была неплохая статья по организации работы в Git.
Здравствуйте, Walker_Tula, Вы писали:
W_T>Вопрос, на который мы не можем найти ответ: как вести разработку новых фич так, чтобы в главном репозитории хранился только один коммит с этой фичей?
Вообще-то этого просто нельзя делать.
Фича должна быть или веткой, или группой коммитов, фильтруемой по определённому признаку (например, id тикета в commit message). А каждый коммит сам по себе должен быть максимально простым действием, чтобы было понятно с ходу, что он делает, почему и как.
Делая иначе, Вы заведомо стреляете себе в ногу, обеспечивая невозможность последующего разбирательства, что именно происходило и почему. Поэтому я советовать Вам такого не буду, и другим не рекомендую.
Здравствуйте, Walker_Tula, Вы писали:
W_T>А как поступать в случае, если новую фичу разрабатывает несколько разработчиков?
Как это ни странно, но из-за наличия в гит таких вещей как bisect в дальней перспективе наиболее удобной схемой работы с гит является использование множества мелких коммитов.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, flаt, Вы писали:
F>Здравствуйте, Константин, Вы писали:
К>>2. После того как разработка закончена, кто-то делает squash всем коммитам и этот один коммит помещается в master F>Почему не merge? Тут на сайте была неплохая статья по организации работы в Git.
Я согласен, что merge здесь лучше всего. Но раз хочется выстрелить себе в ногу оставить ровно один коммит, то это тоже возможно.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Walker_Tula, Вы писали:
W_T>>А как поступать в случае, если новую фичу разрабатывает несколько разработчиков?
IT>Как это ни странно, но из-за наличия в гит таких вещей как bisect в дальней перспективе наиболее удобной схемой работы с гит является использование множества мелких коммитов.
Спасибо, не знал о такой фиче. Помню эмулировали ее вручную (на листке бумаги и, конечно же, ошиблись пару раз )
Здравствуйте, Walker_Tula, Вы писали:
W_T>Вопрос, на который мы не можем найти ответ: как вести разработку новых фич так, чтобы в главном репозитории хранился только один коммит с этой фичей?
Здравствуйте, IT, Вы писали:
IT>Как раз эффективность этой фичи определяется исключительно гранулированностью коммитов.
Можно с этим поспорить, ведь "поломавший" комит мы найдем в любом случае.
Гранулярность комитов у нас итак есть. Каждый таск -- это минимум один комит. Каким бы мелким он ни был (как всегда бывают исключения, но мы стараемся).
Я, например, люблю такую штуку: делаешь что-то, у тебя не получается. Откатываешь все изменения и делаешь опять с чистого листа. Вот тут без гранулярности комитов никак.
И еще. Как раз вчера пришел баг -- отличный кандидат для bisect. Так вот, блин, я не нашел "хорошей" ревизии в которой этот баг не проявляется. Оказалось, что эта фича никогда не работала, чтобы ни говорил заказчик
Здравствуйте, Aikin, Вы писали:
IT>>Как раз эффективность этой фичи определяется исключительно гранулированностью коммитов. A>Можно с этим поспорить, ведь "поломавший" комит мы найдем в любом случае.
Найдём. Только потом надо будет разобраться с тем, что именно поломало код в этом коммите.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Walker_Tula, Вы писали:
W_T>Вопрос, на который мы не можем найти ответ: как вести разработку новых фич так, чтобы в главном репозитории хранился только один коммит с этой фичей?
рекомендуемый подход иной: делать отдельную ветку для фичи и вливать её в главную с помощью rebase. тогда коммиты, относящиеся к этой фиче, будут идти в главной ветке последовательно, и при этом все промежуточные коммиты сохранятся. плю.с можно использовать метки для выделения всех коммитов, относящихся к одной фиче, и наоборот — последних коммитов каждой фичи
Здравствуйте, BulatZiganshin, Вы писали:
W_T>>Вопрос, на который мы не можем найти ответ: как вести разработку новых фич так, чтобы в главном репозитории хранился только один коммит с этой фичей? BZ>рекомендуемый подход иной: делать отдельную ветку для фичи и вливать её в главную с помощью rebase. тогда коммиты, относящиеся к этой фиче, будут идти в главной ветке последовательно, и при этом все промежуточные коммиты сохранятся. плю.с можно использовать метки для выделения всех коммитов, относящихся к одной фиче, и наоборот — последних коммитов каждой фичи
Здесь только одно реальное преимущество (хотя и огромное) — своевременная синхронизация с главной веткой, чтобы было проще разрешать конфликты.
Но многим удобнее делать целиком другую ветку, и потом её мержить.
Здравствуйте, netch80, Вы писали:
W_T>>>Вопрос, на который мы не можем найти ответ: как вести разработку новых фич так, чтобы в главном репозитории хранился только один коммит с этой фичей? BZ>>рекомендуемый подход иной: делать отдельную ветку для фичи и вливать её в главную с помощью rebase. тогда коммиты, относящиеся к этой фиче, будут идти в главной ветке последовательно, и при этом все промежуточные коммиты сохранятся. плю.с можно использовать метки для выделения всех коммитов, относящихся к одной фиче, и наоборот — последних коммитов каждой фичи
N>Здесь только одно реальное преимущество (хотя и огромное) — своевременная синхронизация с главной веткой, чтобы было проще разрешать конфликты. N>Но многим удобнее делать целиком другую ветку, и потом её мержить.
Можно ведь периодически мержить изменения в главной ветке на нашу. Проблем с мержем потом никаких.
СУВ, Aikin
P.S. про сам посыл с ребэйзом нифига не понял. ИМХО, ребэйз совсем для другого
Здравствуйте, Aikin, Вы писали:
A>Можно ведь периодически мержить изменения в главной ветке на нашу. Проблем с мержем потом никаких.
Не нужно. git вам не svn. Периодически делать рибейз -- это да.
A>P.S. про сам посыл с ребэйзом нифига не понял. ИМХО, ребэйз совсем для другого
Рибейз ветки на мастер -- это построение ветки от HEAD мастера. Скопипастю из man git-rebase:
Было:
A---B---C topic
/
D---E master
Потом в мастер и в ветку занесли немного коммитов:
A---B---C---H---I topic
/
D---E---F---G master
После рибейза получаем:
A'--B'--C'--H'--I' topic
/
D---E---F---G master
Коммиты F и G естественным образом теперь имеются в topic.
Здравствуйте, rising_edge, Вы писали:
A>>Можно ведь периодически мержить изменения в главной ветке на нашу. Проблем с мержем потом никаких. _>Не нужно. git вам не svn. Периодически делать рибейз -- это да.
Вам не нужно, мне нужно. Я в курсе, что git не svn.
У меня над фичей могут работать больше одного разработчика. Как быть в этом случае?
Здравствуйте, Aikin, Вы писали:
A>>>Можно ведь периодически мержить изменения в главной ветке на нашу. Проблем с мержем потом никаких. _>>Не нужно. git вам не svn. Периодически делать рибейз -- это да. A>Вам не нужно, мне нужно. Я в курсе, что git не svn. A>У меня над фичей могут работать больше одного разработчика. Как быть в этом случае?
При такой политике — каждый из разработчиков, прежде чем сделать попытку отправки в центральный репозиторий, проверяет его обновления и делает локальный rebase, если было изменение.
Кстати, у gerrit есть несколько вариантов настройки, как принимать коммиты в сопровождаемый репозиторий, и один из них — допускать только fast forward. В этом случае, если ревью коммита одобрено, а ветка ушла, кто-то должен нажать rebase в интерфейсе, а если оно не проходит — то выполнить локально с разрешением конфликта и отправить заново.
Но мне жёсткое требование rebase и линейной истории не нравится тем, что разъезжаются даты создания и последней модификации коммита. А обновлять дату создания тоже не всегда хорошо с точки зрения истории.
Умеренный мерж тут обычно безвреден и лучше показывает развитие.
A>Мне больше нравится (вкус и цвет...): A>
A> A---B---M'---C---H---I topic
A> / /
A> D---E---F---G master
A>
A>"Коммиты F и G естественным образом теперь имеются в topic".
Ну обычно, насколько я вижу, где-то так и стараются делать.
Здравствуйте, Aikin, Вы писали:
W_T>>>>Вопрос, на который мы не можем найти ответ: как вести разработку новых фич так, чтобы в главном репозитории хранился только один коммит с этой фичей? BZ>>>рекомендуемый подход иной: делать отдельную ветку для фичи и вливать её в главную с помощью rebase. тогда коммиты, относящиеся к этой фиче, будут идти в главной ветке последовательно, и при этом все промежуточные коммиты сохранятся. плю.с можно использовать метки для выделения всех коммитов, относящихся к одной фиче, и наоборот — последних коммитов каждой фичи N>>Здесь только одно реальное преимущество (хотя и огромное) — своевременная синхронизация с главной веткой, чтобы было проще разрешать конфликты. N>>Но многим удобнее делать целиком другую ветку, и потом её мержить. A>Можно ведь периодически мержить изменения в главной ветке на нашу. Проблем с мержем потом никаких.
Мой вариант этого не отрицает.
A>P.S. про сам посыл с ребэйзом нифига не понял. ИМХО, ребэйз совсем для другого
Да, линеаризация истории не должна являться самоцелью.
Я использую rebase в двух случаях:
1. Редактирование уже сделанных коммитов (но это не rebase по другой ветке, это interactive rebase с редактированием уже сделанного)
2. Перед выкидыванием новых коммитов или сильно переделанных прежних на ревью (через gerrit), убрать совершенно ненужное тут ветвление и актуализировать состояние, чтобы уменьшить потенциальные проблемы с последующим мержем. Вот тут линеаризация как раз полезна, хоть и не обязательна.
Здравствуйте, netch80, Вы писали:
N>При такой политике — каждый из разработчиков, прежде чем сделать попытку отправки в центральный репозиторий, проверяет его обновления и делает локальный rebase, если было изменение.
Как пользоваться ребэйзом я знаю. Но в пределах одной ветки. И этим мы сильно пользуемся.
То что ребэйз можно делать всей ветке я как-то не думал. Сейчас узнал и думаю "а нафига?". Пока ничего толкового не приходит в голову. Может потому, что у нас feature-branches практически не используются. В основном у нас бранчи по версиям.
N>Но мне жёсткое требование rebase и линейной истории не нравится тем, что разъезжаются даты создания и последней модификации коммита. А обновлять дату создания тоже не всегда хорошо с точки зрения истории. N>Умеренный мерж тут обычно безвреден и лучше показывает развитие.
Полностью согласен.
Если нам не помогут, то мы тоже никого не пощадим.
)
