Comments 35
UFO just landed and posted this here
ребэйз приводит набор ваших патчей к текущему «мастеру» или тому относительно чего вы ребэйзитесь, плюс попутно можно схлопнуть несколько мелких коммитов в один или выкинуть какие то…
UFO just landed and posted this here
Например, я собираю в Альте couchdb. Я клонирую апстрим. От бранча 0.10.х ответвляю 0.10.x-alt, в котором держу альт-специфичные изменения и в который время от времени мерджу апстримный 0.10.x.
Итого, если я захочу отослать обратно свои правки, я сделаю ребейз, смерджу изменения и запушу.
Итого, если я захочу отослать обратно свои правки, я сделаю ребейз, смерджу изменения и запушу.
UFO just landed and posted this here
«отослать правки без ребейза» я могу только в виде патча.
Либо запушить свой бранч целиком, чтобы с ним парился апстрим, что неправильно и невежливо.
С rebase`ом же я могу сделать git rebase origin/0.10.x, находясь в 0.10.x-alt, после чего переключиться обратно на 0.10.х и смерджить свои изменения — git merge 0.10.x-alt. Т.е. сделать так, чтобы у меня на руках был бранч, опережающий origin ровно на мои правки. Таким образом, мне останется только сделать push.
Либо запушить свой бранч целиком, чтобы с ним парился апстрим, что неправильно и невежливо.
С rebase`ом же я могу сделать git rebase origin/0.10.x, находясь в 0.10.x-alt, после чего переключиться обратно на 0.10.х и смерджить свои изменения — git merge 0.10.x-alt. Т.е. сделать так, чтобы у меня на руках был бранч, опережающий origin ровно на мои правки. Таким образом, мне останется только сделать push.
UFO just landed and posted this here
Отправить бранч целиком означает «мне было лень привести всё в божеский вид, ковыряйтесь сами».
Если Вы не коммитер в этот проект, то бранч целиком у вас никто и не примет и Ваш тоже смотреть не будет.
А если Вы коммитер и написали какую-то новую фичу, то Вам её и вливать в основное дерево. Можно тупо смерджить — в основной истории будут все неудачные, ненужные и промежуточные коммиты вместо единообразной красивой истории, в которой добавление вашей фичи, грубо говоря, представлено один коммитом и в силу такой атомарности отрывание её не представляет труда.
Слишком упрощенно, но доступней я не могу, из меня объясняльщик хреновый, к сожалению.
Если Вы не коммитер в этот проект, то бранч целиком у вас никто и не примет и Ваш тоже смотреть не будет.
А если Вы коммитер и написали какую-то новую фичу, то Вам её и вливать в основное дерево. Можно тупо смерджить — в основной истории будут все неудачные, ненужные и промежуточные коммиты вместо единообразной красивой истории, в которой добавление вашей фичи, грубо говоря, представлено один коммитом и в силу такой атомарности отрывание её не представляет труда.
Слишком упрощенно, но доступней я не могу, из меня объясняльщик хреновый, к сожалению.
git — распределенная система. У каждого свой репозитарий. Здесь не принято отправлять бранч куда-нибудь. Это у вас его могут заpull-ить.
Ага, порассказывайте в апстриме какого-нибудь крупного проекта, что им надо что-то пулить с неизвестных серверов, вместо быстрого изучения приаттаченных патчей.
Обычно format-patch и вперед.
Обычно format-patch и вперед.
Мммм… Большой проект. Да да, припоминаю. Линус Торвальдс постоянно pull-ит из репоизитариев своих помощников.
Вот именно, мерджится с своими офицерами и только с ними, а вовне со всеми подряд. Ваш правки дойдут до них (офицеров) через N-ное количество промежуточных бранчей.
Я, наверное, резковато откаментил — я имел в виду, что первоначально в проект коммиты в 90% случаев попадут в виде патчей, а не кто-то их будет пулить.
Разве что это совсем вменяемый и не самый крупный апстрим.
Я, наверное, резковато откаментил — я имел в виду, что первоначально в проект коммиты в 90% случаев попадут в виде патчей, а не кто-то их будет пулить.
Разве что это совсем вменяемый и не самый крупный апстрим.
Да, я согласен. Своим первым комментарием я ставил целью объяснить, что подход ivanych-а является подходом централизованныз систем контроля версий, когда используется единый главный репозиторий, в который все «толкают» свой код. Он всего лишь перенес эти подходы на git, не понимая, как мне кажется, саму идею распределенности.
UFO just landed and posted this here
Ваша модель работает, это я прекрасно понимаю. Наверное я погорячился, назвав ее неправильной, ведь git не задает никаких ограничений в использовании и даже советов не дает по тому, как использовать. Просто такую нестандартную модель я еще не встречал.
Идеальной по моему мнению является модель, когда «релизный» репозиторий находится у главного архитектора\менеджера и он постепенно берет патчи\пуллит изменения от разработчиков. А сами разработчики, при необходимости, берут что-то у своих коллег или с этого «релизного» репозитория. Примерно такая модель в Linux-е.
Идеальной по моему мнению является модель, когда «релизный» репозиторий находится у главного архитектора\менеджера и он постепенно берет патчи\пуллит изменения от разработчиков. А сами разработчики, при необходимости, берут что-то у своих коллег или с этого «релизного» репозитория. Примерно такая модель в Linux-е.
Если говорить про самый базовый случай, то делая rebase вы берете на себя и свой бранч вопрос разруливания конфликтов и облегчаете жизнь мейнтейнерам master'а(к примеру) — во время git merge yoursuperbranch все конфликты уже разрешены.
А если говорить про git rebase -i это уже совершенно новая ипостась — там можно склеивать коммиты, убирать их, изменять их последовательность, редактировать коммитмесседжи и много чего еще. Для собственных фича-бранчей — превосходный набор функционала.
А если говорить про git rebase -i это уже совершенно новая ипостась — там можно склеивать коммиты, убирать их, изменять их последовательность, редактировать коммитмесседжи и много чего еще. Для собственных фича-бранчей — превосходный набор функционала.
сейчас как раз пишу о том как мы этим пользуемся в проекте, выложу как закочу.
если коротко — получается более красивая история в гите.
если коротко — получается более красивая история в гите.
Еще пример — если вам приходится синхронизироваться с svn репозиторием. Svn не понимает веток git поэтому там мерджи выглядят как один большой коммит. Делая rebase можно сохранить всю историю коммитов из сливаемой ветки.
в не подскажете алгоритм, как «схлопнуть» несколько произвольных коммитов в текущей ветке в один?
Пример:
Допустим у нас есть коммутативное множество коммитов A | B | C| D | E
Каким способом можно из него получить эквивалентное множество вида B | (A+C+D) | E или A | (B+C) | D | E или хотя бы A | B | (C+D+E).
Пример:
Допустим у нас есть коммутативное множество коммитов A | B | C| D | E
Каким способом можно из него получить эквивалентное множество вида B | (A+C+D) | E или A | (B+C) | D | E или хотя бы A | B | (C+D+E).
Это позволяет иметь прямую историю, в одноу ветку «мастер».
Например, вы ветвитесь где-нибудь. В это время происходят коммиты и в мастер, в вашу ветку. Можно слить ветки в одну — но это усложняет историю.
А можно наложить коммиты вашей ветки поверх коммитов мастера. Получит прямая история.
Например, вы ветвитесь где-нибудь. В это время происходят коммиты и в мастер, в вашу ветку. Можно слить ветки в одну — но это усложняет историю.
А можно наложить коммиты вашей ветки поверх коммитов мастера. Получит прямая история.
ну вобщем да, выше сказано
если не понятно, то вот пример:
1. забираем текущее дерево
2. создаём ветку experimental и что-то там правим
3. в это время в апстрим что-то закоммитили
4. чтобы всё гладко смерджилось, обновляем свой мастер, через rebase «освежаем» проделанную работу и тогда уже мерджим свои наработки в master.
если не понятно, то вот пример:
1. забираем текущее дерево
2. создаём ветку experimental и что-то там правим
3. в это время в апстрим что-то закоммитили
4. чтобы всё гладко смерджилось, обновляем свой мастер, через rebase «освежаем» проделанную работу и тогда уже мерджим свои наработки в master.
Спасибо! Хочу свичнуться на git полностью, поэтому сразу в закладки!
Не понимаю одной вещи: как мне применить все коммиты из одной ветки в другую кроме одного или двух? Если делать git rebase -i branch master и удалить записи о ненужных коммитах, то они соответственно удаляться из branch и из master, а мне нужно чтобы в branch эти два коммита остались. Остается cherry-pick — но если по одному коммиты перечислять — это как-то медленно.
хм
rebase и есть средство подчистить историю перед мерджем, т.ч. коммиты логично удаляются.
Если не хочется терять эти коммиты, то, наверное, да, только черри-пикать.
Как вариант, git merge --no-commit, но я сомневаюсь, что это будет быстрее-легче, чем cherry-pick.
Может отбранчевать ветку, сделать в ней rebase с удалением неугодных коммитов и после этого окончательно смерджить с мастером? С одной стороны, это действительно проще всего, с другой — расхождение между branch и master будет только увеличиваться.
rebase и есть средство подчистить историю перед мерджем, т.ч. коммиты логично удаляются.
Если не хочется терять эти коммиты, то, наверное, да, только черри-пикать.
Как вариант, git merge --no-commit, но я сомневаюсь, что это будет быстрее-легче, чем cherry-pick.
Может отбранчевать ветку, сделать в ней rebase с удалением неугодных коммитов и после этого окончательно смерджить с мастером? С одной стороны, это действительно проще всего, с другой — расхождение между branch и master будет только увеличиваться.
Спасибо. Про filter-branch не знал… про rerere знал, но ни разу не пользовался.
Sign up to leave a comment.
ХХ полезных советов для пользователей Git среднего уровня. Часть 2