Понимание.разделы git / config 'remote' и 'branch'

Вот содержимое разделов remote и branch моего файла .git/config.

[remote "origin"]  
    url = https://EvanAad@bitbucket.org/EvanAad/bitbucketstationlocations.git  
    fetch = +refs/heads/*:refs/remotes/origin/*  
[branch "master"]  
    remote = origin  
    merge = refs/heads/master
В чем смысл и назначение содержания этих разделов, в частности подразделов fetch и merge? Как эта информация используется Git для руководства своей работой?
2 2
git-merge git-remote git-config git-fetch

2 ответа:

Называется refspec. Это механизм, который git использует для "разговора" с удаленным сервером и сопоставления локальных ветвей с удаленными ветвями.

Рефспексы

Refspec сопоставляет ветвь в локальном репозитории с ветвью в удаленном репозитории.
Это позволяет управлять удаленными ветвями с помощью локальных команд Git и настраивать некоторые расширенные функции git push и git fetch.

Refspec определяется как [+]<src>:<dst>. Параметр <src> является источником ветвь в локальном репозитории, а параметр <dst> является конечной ветвью в удаленном репозитории.
необязательный знак + предназначен для принудительного выполнения удаленным репозиторием нескоростного обновления.

Refspecs можно использовать с командой git push, чтобы дать другое имя удаленной ветви. Например, следующая команда помещает главную ветвь в исходное удаленное РЕПО, как обычный git push, но использует qa-master в качестве имени для ветви в первоначальное РЕПО. Это полезно для групп контроля качества, которым необходимо переместить свои собственные филиалы в удаленное РЕПО.

git push origin master:refs/heads/qa-master

Добавив несколько строк в конфигурационный файл Git, вы можете использовать refspecs для изменения поведения git fetch.

По умолчанию, git fetch извлекает все ветви в удаленном репозитории. Причиной этого является следующий раздел файла .git/config: 

[remote "origin"]
    url = https://git@github.com:mary/example-repo.git
    fetch = +refs/heads/*:refs/remotes/origin/*

Строка fetch сообщает git fetch, чтобы загрузить все ветви из происхождение РЕПО.
Но некоторые рабочие процессы не нуждаются во всех из них. Например, многие рабочие процессы непрерывной интеграции заботятся только о главной ветви. Чтобы получить только главную ветвь, измените строку выборки следующим образом: 

[remote "origin"]
    url = https://git@github.com:mary/example-repo.git
    fetch = +refs/heads/master:refs/remotes/origin/master

Аналогичным образом можно настроить git push. Например, если вы хотите всегда нажимать главную ветвь на qa-master в исходном удаленном устройстве (как мы делали выше), вы измените конфигурационный файл на: 

[remote "origin"]
    url = https://git@github.com:mary/example-repo.git
    fetch = +refs/heads/master:refs/remotes/origin/master
    push = refs/heads/master:refs/heads/qa-master

Рефспексы дают вам полный контроль над тем, как различные команды Git передают ветви между репозиториями.

Они позволяют вам переименовывать и удалять ветви из вашего локального репозитория, fetch/push в ветви с разными именами и настраивать git push и git fetch для работы только с теми ветвями, которые вы хотите.

6

Запись merge под каждым разделом branch, я думаю, наименее очевидна. Документация Git держит его немного неясным. Давайте сначала займемся остальными.

Настройки в Разделе [remote "..."]

Существует множество возможных настроек. В общем, вам не нужно устанавливать ни один из них с помощью git config напрямую-почти все они имеют команды оболочки, чтобы установить их более "удобным" способом. Это включает в себя оба параметра, которые вы видите здесь. Редко бывает, чтобы захотеть изменить их, любой.

Раздел remote для каждого именованного удаленного устройства, например origin, содержит URL-адрес для git fetch (и, возможно, отдельный push-адрес для git push и других remote.* элементов конфигурации, как описано в документацииgit config ). Он также имеет одну или несколько строк fetch, которые предоставляют аргументы по умолчанию refspec для git fetch из этого удаленного.

То есть, если вы бежите: 

git fetch origin

Git посмотрит вверх remote.origin.url, чтобы увидеть, где подключиться, затем подключиться там, затем получение ссылок на основе всех записей remote.origin.fetch. Значение по умолчанию, которое вы видите здесь: 

+refs/heads/*:refs/remotes/origin/*

Говорит Git скопировать все ветви 1 с пульта дистанционного управления, переименовав их в ветвь удаленного отслеживания с префиксом origin/2 в вашем собственном хранилище, так что: 

git fetch origin

В основном получает все. (Ведущий + говорит, что Git должен делать это независимо от того, является ли обновление ветви удаленного отслеживания операцией быстрой перемотки вперед. То есть это похоже на использование --force, но без необходимости уточнять --force.)

С другой стороны, если вы бежите: 

git fetch origin a:b c:d

Git будетполностью игнорировать все строки fetch =, извлекая только ссылки a и c из удаленного хранилища, записывая их в ссылки b и d в вашем репозитории. (И поскольку это не имеет ни +, ни --force, ни один из них не будет обновляться принудительно-хотя в большинстве случаев это все равно не имеет значения.)

1, 2 a ссылка - это общий термин, который охватывает обе ветви и теги (и многое другое). Названия ветвей, такие как master, являются просто краткими для ссылок, которые начинаются с refs/heads/. Имена ветвей удаленного отслеживания, такие как origin/master, просто коротки для ссылок, которые начинаются с refs/remotes/. Обратите внимание, что часть origin/ происходит от строки fetch =-но для того, чтобы все это работало так, как это предполагается, эта строка должна соответствовать имени пульта дистанционного управления в квадратных скобках.

Параметры под [branch "..."] секция

Существует множество возможных настроек. В общем, вам не нужно устанавливать ни один из них с помощью git config напрямую-почти все они имеют команды оболочки, чтобы установить их более "удобным" способом. Это включает в себя оба параметра, которые вы видите здесь. Не так уж редко возникает желание изменить один или оба из них, используя команду, которую мы увидим через мгновение.

Часть remote довольно ясна сама по себе: это означает, что если вы находитесь на ветке master и запускаете git fetch без давая удаленное имя вообще, Git должен получить от удаленного с именем origin.

Часть merge самая сложная. Он перечисляет имя ветви , как видно на пульте. Обратите внимание, что когда мы запускаем git fetch origin, мы говорим нашему Git вызвать другой Git, найти другой Git master и скопировать его в наш репозиторий, но вызвать его origin/master. И все же ... .. эта строка merge говорит merge = refs/heads/master. Разве там не должно быть написано: merge = refs/remotes/origin/master?

Вероятно, так и должно быть-но эта установка предшествует самой изобретение пультов дистанционного управления в первую очередь. Поэтому он не делает этого; вместо этого он перечисляет полное имя ссылки , как оно появляется на удаленном.

Эта настройка используется, если вы запускаете git merge или git rebase без указания имени ветви для слияния или перебазирования. Git запускает имя через сопоставления, предоставляемые строкой fetch = для удаленного устройства, чтобы выяснить, что оно должно сливаться с origin/master, например.

Эта настройка также используется командой git pull удобство, что эффективно3 то же самое, что бег git fetch, за которым следует бег git merge.

Возможно, вы захотите изменить один или оба из них. Например, если вы создадите новую локальную ветвь feature/tall, она может иметь нет branch.feature/tall.remote и branch.feature/tall.merge настройки у всех.

Поскольку вы только что создали эту ветвь, нет никакой origin/feature/tall. Git в origin еще не имеет feature/tall, поэтому у вас нет его копии.

Затем вы git push origin feature/tall:feature/tall, чтобы ваш Git вызвал origin Git и пусть их Git создастэту ветвь, так что теперь вы делаете есть origin/feature/tall. Возможно, ты захочешь, чтобы твой мерзавец запомнил это.

Вы могли бы выполнить две команды git config, но вместо этого вы можете выполнить одну команду оболочки более высокого уровня: 

git branch --set-upstream-to=origin/feature/tall feature/tall

Это говорит вашему Git установить branch.feature/tall.remote в origin, а branch.feature/tall.merge в refs/heads/feature/tall (это имя на origin).

Вы можете объединить шаги git push и git branch --set-upstream-to с помощью git push -u, что еще лучше, но суть здесь остается: вы используете оболочку, чтобы получить оба значения, установленные одновременно, так как установка только одного значения не так уж и полезна.4

3это намеренно замалчивает множество мелких деталей.

4установка только части remote действительно влияет на будущее git push, но git merge и git rebase не смогут выполнить отображение ветвей удаленного отслеживания без обеих записей.

9