У меня часто есть как минимум 3 удаленных филиала: мастер, постановка и производство. У меня есть 3 локальных филиала, которые отслеживают эти удаленные ветви.
Обновление всех моих местных отделений утомительно:
git fetch --all
git rebase origin/master
git checkout staging
git rebase origin/staging
git checkout production
git rebase origin/production
Мне бы очень хотелось, чтобы я мог просто сделать "git pull-all", но я не смог заставить его работать. Кажется, что он выполняет «fetch --all», затем обновляет (перемотает вперед или объединяет) текущую рабочую ветку, но не другие локальные ветви.
Я все еще застрял, вручную переключаясь на каждую локальную ветку и обновляясь.
Ответы:
Поведение, которое вы описываете, в
pull --all
точности соответствует ожиданиям, но не обязательно полезно. Опция передается в git fetch, который затем выбирает все ссылки со всех пультов, а не только необходимые;pull
затем объединяет (или, в вашем случае, перебазирует) соответствующую отдельную ветку.Если вы хотите проверить другие ветки, вам придется проверить их. И да, для слияния (и перебазировки) абсолютно необходимо рабочее дерево, поэтому они не могут быть выполнены без проверки других ветвей. Вы можете обернуть описанные шаги в скрипт / псевдоним, если хотите, хотя я бы посоветовал объединить команды
&&
так, чтобы в случае сбоя одной из них она не попыталась вспахать.источник
Я использую
sync
субкоманду в ступице автоматизировать этот процесс . Я имеюalias git=hub
в моей.bash_profile
, поэтому команда, которую я печатаю, является:Это обновляет все локальные ветви, которые имеют соответствующую ветку восходящего потока. Со страницы руководства:
Он также обрабатывает сохранение / удаление незафиксированных изменений в текущей ветви.
Раньше я использовал похожий инструмент под названием git-up , но он больше не поддерживается и
git sync
делает почти то же самое.источник
git config --global git-up.rebase.auto false
.Я знаю, что этому вопросу почти 3 года, но я задавал себе тот же вопрос и не нашел никакого готового решения. Итак, я создал собственный сценарий командной оболочки git самостоятельно.
Вот и все,
git-ffwd-update
скрипт делает следующее ...git remote update
за последние оборотыgit remote show
для получения списка локальных веток, которые отслеживают удаленную ветку (например, ветки, которые можно использовать сgit pull
)git rev-list --count <REMOTE_BRANCH>..<LOCAL_BRANCH>
сколько коммитов локальная ветвь находится позади удаленной (и впереди наоборот)git branch -f <LOCAL_BRANCH> -t <REMOTE_BRANCH>
скрипт можно назвать так:
Полный скрипт, должен быть сохранен как
git-ffwd-update
и должен быть наPATH
.источник
git branch
вызове. Я удалил -l, чтобы изменить вызов,git branch -f $LB -t $ARB >/dev/null;
и теперь скрипт работает как надо.Это не так сложно автоматизировать
источник
git rebase origin/$branch
наgit pull
так, чтобы он получал данные из соответствующей ветви отслеживания (предположительно в исходной точке) и выполнял слияние или перебазирование, как определено в конфигурации.fetch
. Отредактировал; дополнительные функции / исправления, какие бы ни были до ОП.pull
(или проверитьbranch.<branch>.rebase
), чтобы случайно не перебазировать ветку, которая настроена на обычное натяжение (слияние).set -e
вместо,|| exit 1
чтобы заставить интерпретатор завершить работу при первой ошибке.Это по-прежнему не является автоматическим, так как я хотел бы, чтобы была опция для - и должна быть некоторая проверка, чтобы убедиться, что это может произойти только для обновлений ускоренной перемотки (именно поэтому ручное выполнение извлечения намного безопаснее !!), но в стороне вы можете сделать следующее:
обновить положение вашего местного отделения без необходимости проверять его.
Примечание: вы потеряете свою текущую позицию ветвления и переместите ее туда, где находится ветвь источника, что означает, что если вам нужно объединить, вы потеряете данные!
источник
git fetch origin other-branch:other-branch
Здесь много ответов, но ни один из них не используется
git-fetch
для непосредственного обновления локальной ссылки, что намного проще, чем проверка веток, и безопаснее, чемgit-update-ref
.Здесь мы используем
git-fetch
для обновления нетоковых веток иgit pull --ff-only
для текущей ветки. Это:и вот оно:
Из справочной страницы для
git-fetch
:Указывая
git fetch <remote> <ref>:<ref>
(без такового+
), мы получаем выборку, которая обновляет локальный ref только тогда, когда он может быть быстро переслан.Примечание : это предполагает, что локальные и удаленные ветви названы одинаково (и что вы хотите отслеживать все ветви), оно должно действительно использовать информацию о том, какие локальные ветви у вас есть и что они настроены для отслеживания.
источник
c*n
шаги (вместо 1), гдеc
некоторое количество повторяющихся команд иn
количество ветвей.git branch -r | grep -v ' -> ' | while read remotebranch
чтобыgit branch -r | grep -v ' -> ' | grep -f <(git branch | cut -c 3- | awk '{print "\\S*/"$0"$"}') | while read remotebranch
ограничить его ветвей у меня уже есть на месте. Также я добавилgit fetch --prune
в начале, чтобы обновить список удаленных веток, прежде чем делать что-либо, что позволяет избежать некоторых предупреждений.Эта проблема не решена (пока), по крайней мере, нелегко / без сценариев: см. Этот пост в списке рассылки git от Junio C Hamano, объясняющий ситуацию и обеспечивающий простое решение.
Основная причина в том, что вам не нужно это:
Призыв к решению был для опции или внешнего сценария, чтобы обрезать локальные ветви, которые теперь следуют за удаленными отслеживающими ветвями, вместо того, чтобы поддерживать их в актуальном состоянии с помощью быстрой пересылки, как запрошенный оригинальный плакат.
Примечание: с git 2.10 такого решения не существует. Обратите внимание, что
git remote prune
подкоманда иgit fetch --prune
касается удаления ветви удаленного отслеживания для ветви, которая больше не существует на удаленной, а не удаления локальной ветви, которая отслеживает ветку удаленного отслеживания (для которой ветвь удаленного отслеживания является восходящей веткой).источник
Здесь есть много приемлемых ответов, но некоторые из них могут быть немного непрозрачными для непосвященных. Вот гораздо более простой пример, который можно легко настроить:
Если вы добавляете
~/bin/git
в свойPATH
(при условии, что файл~/bin/git/git-update-all
), вы можете просто запустить:источник
Добавьте этот скрипт в
.profile
Mac OS X:источник
Вот хороший ответ: Как получить все ветки git
источник
git fetch
иgit pull
, вместо того , чтобы простоgit pull
?origin/
префиксомСкрипт, который я написал для моего GitBash . Выполняется следующее:
git checkout branch
git pull origin
** Я использую это, но не проверил полностью, используйте на свой страх и риск. Смотрите пример этого скрипта в файле .bash_alias здесь .
источник
Если вы работаете в Windows, вы можете использовать PyGitUp, который является клоном
git-up
для Python. Вы можете установить его используя pip сpip install --user git-up
помощью Scoop или используяscoop install git-up
[
источник
Просто выкладываю обновленный ответ.
git-up
больше не поддерживается, и если вы читаете документацию, они упоминают, что функциональность теперь доступна в git .Вы также можете установить это для каждого
git pull
Git 2.9 (спасибо @VonC, пожалуйста, смотрите его ответ здесь )источник
git-up
документации , потому что они не упоминают , чтоgit-up
.git-up
:)Я столкнулся с той же проблемой этого вопроса ...
Задумываясь об этом, я сделал небольшую функцию псевдонима внутри
.bashrc
файла:Работал для меня (:
источник
Если refs /heads / master можно быстро переадресовать на refs / remotes / foo / master , вывод
должен вернуть идентификатор SHA1, на который указывает refs /heads / master . При этом вы можете собрать скрипт, который автоматически обновляет все локальные ветви, к которым не применены отклоняющие коммиты.
Этот небольшой скрипт оболочки (я назвал его git-can-ff ) иллюстрирует, как это можно сделать.
источник
Чтобы завершить ответ Мэтта Коннолли, это более безопасный способ обновления ссылок на локальные ветви, которые можно быстро пересылать без проверки ветви. Он не обновляет ветки, которые нельзя быстро переадресовать (т. Е. Которые разошлись), и не обновляет ветку, которая в настоящий момент извлечена (поскольку тогда рабочая копия должна быть также обновлена).
источник
Немного другой скрипт, который только быстро переходит вперед ветвями, чьи имена совпадают с их ветвью вверх по течению. Он также обновляет текущую ветку, если возможна перемотка вперед.
Убедитесь, что все ветки upstream ваших веток настроены правильно, запустив
git branch -vv
. Установите ветку upstream с помощьюgit branch -u origin/yourbanchname
Скопируйте и вставьте в файл chmod 755:
источник
Следующая однострочная строка ускоряет пересылку всех ветвей, которые имеют ветку восходящего потока, если это возможно, и печатает ошибку в противном случае:
Как это работает?
Он использует пользовательский формат с
git branch
командой. Для каждой ветви с восходящей веткой она печатает строку со следующим шаблоном:Это может быть передано напрямую
sh
(при условии, что имена ветвей правильно сформированы). Опустить| sh
чтобы увидеть, что он делает.Предостережения
Однострочник не будет связываться с вашими пультами. Выпустите
git fetch
илиgit fetch --all
перед запуском.В настоящее время извлеченная ветвь не будет обновлена с сообщением как
Для этого можно прибегнуть к обычному
git pull --ff-only
.кличка
Добавьте следующее к вашему,
.gitconfig
чтобыgit fft
выполнить эту команду:Смотрите также мой
.gitconfig
. Псевдоним - это сокращение от «ускоренного отслеживания (ветки)».источник
hub
soluction propsed по @John для его лучшего выхода.git push
это полностью противоположно тому, что вы ожидаете. В чем секрет?git push
?git push
имеет семантику загрузки - у меня есть некоторые коммиты локально, которые я хочу отправить в апстрим.git pull
имеет семантику загрузки - я хочу получить некоторые восходящие удаленные коммиты в мою локальную ветку. Поскольку мы говорим о загрузке новых коммитов с удаленного на локальный,git pull
это очевидный выбор. Но нет, этот трюк используетgit push
. Как этоgit push
приводит к удалению изменений в моем местном филиале ?!git push
также может использоваться для обновления локальных ветвей, если это обновление с ускоренной передачей.Сценарий от @larsmans, немного улучшен:
Это, после его завершения, оставляет рабочую копию извлеченной из той же ветки которая была до вызова скрипта.
git pull
Версия:источник
Похоже, что многие другие предложили подобные решения, но я подумал, что поделюсь тем, что я придумал, и приглашаю других внести свой вклад. Это решение имеет приятный красочный вывод, изящно обрабатывает ваш текущий рабочий каталог и является быстрым, потому что оно не делает никаких проверок и оставляет ваш рабочий каталог в такте. Кроме того, это всего лишь сценарий оболочки без каких-либо зависимостей, кроме git. (пока тестируется только на OSX)
https://github.com/davestimpert/gitup
Извините, но мне кажется, что я придумала то же имя, что и другой инструмент выше.
источник
Это можно сделать с помощью приведенного ниже сценария ... Сначала он извлечет все ветви и оформит заказ один за другим и обновит сам.
источник
Вы не можете сделать это только одной командой git, но вы можете автоматизировать это с помощью одной строки bash.
Чтобы безопасно обновить все ветки одной строкой, вот что я делаю:
Если он не может перемотать одну ветку вперед или возникнет ошибка, он остановится и оставит вас в этой ветке, чтобы вы могли вернуть управление и объединить вручную.
Если все ветви можно быстро переадресовать, это закончится веткой, в которой вы были в данный момент, и оставит вас там, где вы были до обновления.
Пояснения:
Для лучшей читаемости его можно разбить на несколько строк:
git fetch --all && ...
=> Извлекает все ссылки со всех пультов и продолжает выполнение следующей команды, если ошибки не было.git branch | sed '/*/{$q;h;d};$G' | tr -d '*'
=> Из выводаgit branch
,sed
возьмите строку с a*
и переместите ее в конец (чтобы текущая ветвь была обновлена последней). Затемtr
просто удалите*
.for branch in $(...) ; do git checkout $branch && git merge --ff-only || break ; done
=> Для каждого имени ветви, полученного из предыдущей команды, извлеките эту ветку и попробуйте выполнить слияние с перемоткой вперед. Если это не удается,break
вызывается и команда останавливается здесь.Конечно, вы можете заменить
git merge --ff-only
с ,git rebase
если это то , что вы хотите.Наконец, вы можете поместить его в свой bashrc как псевдоним:
Или, если вы боитесь испортить «и», или вы просто предпочитаете сохранить синтаксическую читабельность в вашем редакторе, вы можете объявить его как функцию:
Бонус:
Для тех, кто хотел бы получить объяснение со
sed '/*/{$q;h;d};$G'
стороны:/*/
=> Поиск строки с*
.{$q
=> Если это в последней строке, выйти (нам не нужно ничего делать, потому что текущая ветвь уже является последней в списке).;h;d}
=> В противном случае сохраните строку в буфере удержания и удалите ее в текущей позиции списка.;$G
=> Когда он достигнет последней строки, добавьте содержимое буфера удержания.источник
&&
установивset -e
в верхней части сценария.Нет, не может. Для быстрой перемотки я просто написал небольшой инструмент для этого. https://github.com/changyuheng/git-fast-forward-all
Преимущества этого инструмента:
hub sync
на данный момент не поддерживает несколько пультов.)источник
git fetch . refspec
..
Говорит извлечь из текущего хранилища , а не из удаленных один.По состоянию на git 2.9:
git pull --rebase --autostash
Смотрите https://git-scm.com/docs/git-rebase
источник
На самом деле, с Git
version 1.8.3.1
, это работает:В мастер ветке вы можете обновить все остальные ветки. @Cascabel
Я не знаю, какую версию сломать / исправить его, в 2.17 (который я использую), он может работать.
источник