git rebase на удаленные обновления - PullRequest
Новая
       62

git rebase на удаленные обновления

22 голосов
/ 27 мая 2010

Я работаю с небольшой командой, которая использует git для управления исходным кодом. Недавно мы делали ветки тем, чтобы отслеживать функции, затем сливать их в master локально, а затем отправлять в центральный git-репозиторий на удаленном сервере. Это прекрасно работает, когда в master не было внесено никаких изменений: я создаю свою ветку тем, фиксирую ее, объединяю в master, затем нажимаю. Hooray.

Однако, если кто-то подтолкнул к источнику раньше, чем я, мои коммиты не будут перенесены вперед. Таким образом, происходит слияние. Это также происходит, когда ветвь темы должна сливаться с мастером локально, чтобы мои изменения работали с кодом на данный момент. Таким образом, мы получаем коммиты слияния повсюду и git log, конкурирующие с браслетом дружбы.

Итак, перебазировка - очевидный выбор. То, что я хотел бы, чтобы:

  • создание веток тем, содержащих несколько коммитов
  • Оформить заказ мастером и вытащить (перемотка вперед, потому что я не совершил мастеринг)
  • перебазировать ветки тем на новую голову мастера
  • Перебазировать темы против мастера (поэтому темы начинаются с заголовка мастера), перенося мастера в мою тему

Мой способ сделать это в настоящее время указан ниже: 

git checkout master
git rebase master topic_1
git rebase topic_1 topic_2
git checkout master
git rebase topic_2
git branch -d topic_1 topic_2

Есть ли более быстрый способ сделать это?

Ответы [ 4 ]

35 голосов
/ 17 декабря 2010

Знаете ли вы о git pull --rebase? Он восстанавливает, а не объединяет, когда вы тянете, и предотвращает загрязнение вашей истории коммитами слияния.

Вы также можете установить его как поведение по умолчанию для ветви с параметрами конфигурации branch.<name>.rebase и branch.autosetuprebase.

11 голосов
/ 18 декабря 2010

Я обнаружил, что со временем мое любимое решение: 

git checkout topic
# make [n] commits
git rebase -i HEAD~[n] #clean up time
git checkout master
git pull --rebase
git checkout topic
git rebase master
git checkout master
git merge topic
git push origin
2 голосов
/ 11 ноября 2013

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

git checkout topic_1
git rebase refs/remotes/origin/master

Что избавляет от необходимости тянуть (по крайней мере, до EOL вашей ветви функций). Наш процесс использует GitHub pull-запросы, поэтому мне никогда не нужно делать это локально.

2 голосов
/ 27 мая 2010

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

Мы сокращаем нашу работу в билетах Jira, которые не занимают много времени, обычно 1-2 дня. Каждый разработчик создает ветку за тикет и работает над этой веткой. Когда он готов поделиться, он отправляется на центральный сервер.

Центральный сервер контролируется CI-сервером hudson, который извлекает изменения, объединяет все обновленные ветви, перестраивает программное обеспечение, запускает тесты и помещает все в центральный главный репозиторий git.

Оттуда мы возвращаем его в наши хранилища. Мы регулярно (т. Е. Каждые пару дней) объединяем наши рабочие ветви с центральным мастером, чтобы держать их «близко».

Поскольку никто не работает на 'объединяющей' машине, и никто, кроме CI-сервера, не касается мастера, у нас очень редко возникают проблемы слияния (примерно в 1-2% коммитов). И они быстро решаются на сервере сборки путем очистки рабочей области. Мы обнаружили, что могли бы избежать большинства из них, сохранив короткие ветви и объединившись с удаленным мастером перед нажатием.

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

...