LINUX.ORG.RU

Вопрос по git

 , ,


1

1

Допустим я вел 3 ветки разработки (b1, b2, b3), и вдруг кто-то замечает, что нужно бы для всех этих 3х веток реализовать один и тот же функционал прежде чем дальше двигаться в разработке, как мне стоит поступить? Создать еще одну ветку с этой фичей и за пару дней реализовать? Тогда каким образом мне стоит слить этот функционал на ветки b1, b2, b3, через rebase? Я представляю как через rebase это сделать, но тогда получается у всех 3х веток один и тот же коммит.
Ну и сразу такой вопрос, в каких случаях лучше использовать rebase, а в каких merge?

★★★

Ну в общем тут есть два варианта. Если фича маленькая (1-2 коммита), можешь реализовать эту фичу в одной из веток и дальше черепикнуть в две остальные эти коммиты. Второй вариант - классический хотфикс. Т.е. мы создаем ветку от одной из веток, пилим фичу (?) и мкержим потом мержим во все ветки. Но, я на 99% уверен, что ты явно делаешь что-то неправильно. Если бы следовал git flow такого бы скорее всего не было.

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

Ага я понял, я что-то много тупил, пытался через rebase одну ветку слить в 2 другие (всего 1 коммит) и ничего не получалось, через merge все норм.
Я вообще до этого все в master сливал, ни одной ветки не было (на своем проекте, не по работе), а сейчас прочитал что это как-то не хорошо так делать, и решил по изучать git. Про git-flow даже и не знал, сейчас буду смотреть что это такое.

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

Интересно, спасибо, а вот если у меня крупный проект, и в программе несколько крупных подпрограмм или библиотек (к примеру у меня в проекте есть самописный ui toolkit на OpenGL) для них лучше отдельный репозиторий заводить, или как-то помимо ветки develop еще вести ветку ui и от нее фичи пойдут именно для гуя.

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

Если планируется использовать этот gui в других проектах, то лучше вынести его в отдельный проект и подключать его в остальные проекты как submodule.

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

Я бы предпочел разные репозитории запилилить. Так же можно использовать submodules(https://git-scm.com/book/ru/v1/Инструменты-Git-Подмодули). В принципе почти то же самое, что и отдельный репозиторий, но в отличии от них позволяет привязать одну часть проекта к определенной версии другой части проекта. Однако это может создавать небольшие трудности, но в общем штука то же полезная.

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

ясно, спасибо большое за советы, буду пробовать.

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

А почему? Мне на работе друг говорит что наоборот rebase лучше, курсы какие-то смотрит по ror, и там сказали что лучше rebase типа он более правильный, т.к. получается линейная история коммитов.
Вот кстати это видео: https://vimeo.com/108918217

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

rebase лучше вообще не использовать нигде.

...пока не поймёшь, что именно он делает. Впрочем, это ко всему гиту относится :)

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

лучше rebase типа он более правильный, т.к. получается линейная история коммитов

Фанатам линейной истории пройти в subversion. Разумеется, не надо плести сети из бранчей сверх меры. Но гит всё-таки про бранчи, а не про линейную историю.

const86 ★★★★★
()

в каких случаях лучше использовать rebase

только если любители CVS запретили merge

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

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

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

Но гит всё-таки про бранчи, а не про линейную историю.

Ну мердж коммит локального мастера и удаленного в общем случае только мешается.

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

Если где-то был использован rebase, теоретически может быть проблема со сложными, нестандартными мержами.

Чо эта?

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

вместо фактической

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

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

нужна ли фактическая история после пуша локальных изменений в общий репозиторий?

Перевёрнутый трассер тебе в кадило, юный падаван. Ты рискуешь оказаться мишенью «git blame», и это ещё не самый страшный жизненый опыт.

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

История становится фактической только после того, как она попала в общий репозиторий, пройдя перед этим через ревью. Все что было раньше - всего лишь черновые патчи

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

История становится фактической только после того, как она попала в общий репозиторий, пройдя перед этим через ревью. Все что было раньше - всего лишь черновые патчи

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

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

Перевёрнутый трассер тебе в кадило, юный падаван. Ты рискуешь оказаться мишенью «git blame», и это ещё не самый страшный жизненый опыт.

Это тебе кадило. Сколько работаю с гитом, проблем ниогда не было. Просто после ребейза надо еще раз все проверить.

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

если работаешь с локальным репо - все норм, но если пуш идет в удаленный, то потом очень большой гимор для людей, которые уже зачекаутили ревизии и сделали в них изменения и пытаются внести в центральный репо, а ты эти ревизии переместил ребейсом. И тут начинается ад.
Советую также почитать https://habrahabr.ru/post/179123/

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

подзатыльников навешать джуниору, тоже мне большой гимор

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

тот, кто гонится за линейной историей

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

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