Комментарии 35
НЛО прилетело и опубликовало эту надпись здесь
ребэйз приводит набор ваших патчей к текущему «мастеру» или тому относительно чего вы ребэйзитесь, плюс попутно можно схлопнуть несколько мелких коммитов в один или выкинуть какие то…
НЛО прилетело и опубликовало эту надпись здесь
Например, я собираю в Альте couchdb. Я клонирую апстрим. От бранча 0.10.х ответвляю 0.10.x-alt, в котором держу альт-специфичные изменения и в который время от времени мерджу апстримный 0.10.x.
Итого, если я захочу отослать обратно свои правки, я сделаю ребейз, смерджу изменения и запушу.
Итого, если я захочу отослать обратно свои правки, я сделаю ребейз, смерджу изменения и запушу.
НЛО прилетело и опубликовало эту надпись здесь
«отослать правки без ребейза» я могу только в виде патча.
Либо запушить свой бранч целиком, чтобы с ним парился апстрим, что неправильно и невежливо.
С 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.
НЛО прилетело и опубликовало эту надпись здесь
Отправить бранч целиком означает «мне было лень привести всё в божеский вид, ковыряйтесь сами».
Если Вы не коммитер в этот проект, то бранч целиком у вас никто и не примет и Ваш тоже смотреть не будет.
А если Вы коммитер и написали какую-то новую фичу, то Вам её и вливать в основное дерево. Можно тупо смерджить — в основной истории будут все неудачные, ненужные и промежуточные коммиты вместо единообразной красивой истории, в которой добавление вашей фичи, грубо говоря, представлено один коммитом и в силу такой атомарности отрывание её не представляет труда.
Слишком упрощенно, но доступней я не могу, из меня объясняльщик хреновый, к сожалению.
Если Вы не коммитер в этот проект, то бранч целиком у вас никто и не примет и Ваш тоже смотреть не будет.
А если Вы коммитер и написали какую-то новую фичу, то Вам её и вливать в основное дерево. Можно тупо смерджить — в основной истории будут все неудачные, ненужные и промежуточные коммиты вместо единообразной красивой истории, в которой добавление вашей фичи, грубо говоря, представлено один коммитом и в силу такой атомарности отрывание её не представляет труда.
Слишком упрощенно, но доступней я не могу, из меня объясняльщик хреновый, к сожалению.
git — распределенная система. У каждого свой репозитарий. Здесь не принято отправлять бранч куда-нибудь. Это у вас его могут заpull-ить.
Ага, порассказывайте в апстриме какого-нибудь крупного проекта, что им надо что-то пулить с неизвестных серверов, вместо быстрого изучения приаттаченных патчей.
Обычно format-patch и вперед.
Обычно format-patch и вперед.
Мммм… Большой проект. Да да, припоминаю. Линус Торвальдс постоянно pull-ит из репоизитариев своих помощников.
Вот именно, мерджится с своими офицерами и только с ними, а вовне со всеми подряд. Ваш правки дойдут до них (офицеров) через N-ное количество промежуточных бранчей.
Я, наверное, резковато откаментил — я имел в виду, что первоначально в проект коммиты в 90% случаев попадут в виде патчей, а не кто-то их будет пулить.
Разве что это совсем вменяемый и не самый крупный апстрим.
Я, наверное, резковато откаментил — я имел в виду, что первоначально в проект коммиты в 90% случаев попадут в виде патчей, а не кто-то их будет пулить.
Разве что это совсем вменяемый и не самый крупный апстрим.
Да, я согласен. Своим первым комментарием я ставил целью объяснить, что подход ivanych-а является подходом централизованныз систем контроля версий, когда используется единый главный репозиторий, в который все «толкают» свой код. Он всего лишь перенес эти подходы на git, не понимая, как мне кажется, саму идею распределенности.
НЛО прилетело и опубликовало эту надпись здесь
Ваша модель работает, это я прекрасно понимаю. Наверное я погорячился, назвав ее неправильной, ведь 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 знал, но ни разу не пользовался.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ХХ полезных советов для пользователей Git среднего уровня. Часть 2