Автомобили · Инструкция
git config push.autoSetupRemote: как настроить
git config push.autoSetupRemote: как настроить — параметр избавляет от ручного --set-upstream при первом push новой ветки. Он работает с push.
Короткий ответ
`git config --global push.autoSetupRemote true` заставляет обычный первый push без настроенного upstream вести себя как `--set-upstream` для подходящих `push.default` режимов: simple, upstream и current. Это удобно в центральном workflow с одинаковыми именами локальных и удалённых веток.
Как autoSetupRemote выбирает поведение
Когда у текущей ветки нет upstream и выполняется push без явного refspec, значение `push.autoSetupRemote=true` предполагает `--set-upstream`, если `push.default` равен `simple`, `upstream` или `current`. Документация особенно отмечает пользу для простого централизованного процесса, где ветка `feature-x` на локальной машине ожидается под тем же именем на стандартном remote. Если у вас отдельный upstream для чтения и fork для записи, настройка `remote.pushDefault` может быть важнее.
Совет: Проверьте `git branch -vv` сразу после первого автоматического push.
Как включить и проверить
- Посмотрите текущие значения: `git config --get push.default` и `git config --get remote.pushDefault`.
- Включите глобально `git config --global push.autoSetupRemote true` либо локально без `--global`.
- Создайте тестовую ветку и сделайте обычный `git push` без `-u`, убедившись, что выбран ожидаемый remote.
- Проверьте `git branch -vv`: рядом с веткой должен появиться tracking remote/branch.
- В fork-workflow задайте `remote.pushDefault` или `branch.<name>.pushRemote`, если push должен идти не туда, откуда вы fetch/pull.
Когда автоматический upstream может удивить
В репозитории с несколькими remote команда может настроить tracking не на тот сервер, который вы предполагали, если default push-remote выбран иначе. Также `push.default=matching` не относится к перечисленным режимам действия этой опции. Не включайте настройку вслепую в учебных или необычных mirrored workflow, где локальное и удалённое имя ветки специально различаются. Сначала один раз проверьте фактический destination через обычный push или dry-run.
Предупреждение: В multi-remote репозитории не полагайтесь только на имя `origin` — проверьте pushRemote.
После первого push проверьте
- `git branch -vv` показывает upstream;
- remote соответствует нужному fork/центральному репозиторию;
- имя удалённой ветки ожидаемое;
- `git pull` не начал брать изменения из неожиданного источника.
Почему настройка не создаёт удалённую ветку заранее
`push.autoSetupRemote` срабатывает в момент первого подходящего push, когда текущая ветка ещё не имеет upstream. Она не публикует ветки сама по себе и не меняет remote без команды отправки. Поэтому настройка удобна в персональном workflow с единым `origin`, но в проектах с несколькими remote сначала проверьте `remote.pushDefault`, `branch.*.remote` и принятый командой порядок публикации.
Пример для feature-веток
Команда `git switch -c feature/login` создаёт локальную ветку без upstream. С autoSetupRemote и стандартным `push.default=simple` обычный `git push` создаёт одноимённую удалённую ветку и записывает tracking, поэтому следующий push/pull не требует явного `-u`. В репозитории с origin=fork и upstream=оригинал сначала настройте push destination.
Важно: Опция автоматизирует upstream, но не отменяет правила доступа, branch protection и выбор remote.
Что учитывать
`push.autoSetupRemote` срабатывает в момент первого подходящего push, когда текущая ветка ещё не имеет upstream. Она не публикует ветки сама по себе и не меняет remote без команды отправки. Поэтому настройка удобна в персональном workflow с единым `origin`, но в проектах с несколькими remote сначала проверьте `remote.pushDefault`, `branch.*.remote` и принятый командой порядок публикации.
Источники и проверка
Инструкция составлена редакцией N1RO на 2026-09-23. Перед действием сверьте актуальные условия на официальном сайте сервиса или производителя.