Меню

Git настроить отслеживание удаленной ветки

Отслеживание веток

Получение локальной ветки из удалённой ветки автоматически создаёт то, что называется (или, иногда, ). Отслеживаемые ветки это локальные ветки, которые напрямую связаны с удалённой веткой. Находясь на отслеживаемой ветке, вы можете выполнить Групповая разработка > > Получить и слить , потому что Git уже знает, с какого сервера получить все удалённые ссылки и сделает слияние с соответствующей удалённой веткой.

При клонировании репозитория, как правило, автоматически создаётся ветка master , которая отслеживает origin/master . Однако вы можете настроить отслеживание и других веток, допустим, если вы хотите, чтобы одни ветки отслеживались с другого удалённого репозитория или не хотите отслеживать ветку master . Простой пример, как это сделать, вы увидели только что: Групповая разработка > > Переключить На > origin/serverfix. В том же примере вы узнали, что можно настроить локальную ветку с именем, отличным от имени удалённой ветки.

Если у вас уже есть локальная ветка, и вы хотите настроить ее на удалённую ветку, которую вы только получили, или хотите изменить upstream-ветку, которую вы отслеживаете, вы можете перейти в перспективу Git и в панели Репозитории Git выполнить на этой ветке контекстную команду Настроить ветку. .

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

Если вы хотите посмотреть, какие отслеживаемые ветки у вас установлены, вы можете на одной из локальных веток выполнить Показать в > Свойства , а затем пробежать курсором по локальным веткам. В панели Свойства вы увидите информацию об удалённом репозитории и об отслеживаемой ветке.

Для текущей ветки, на которую вы переключились, в панели Навигатор отображается информация о том, опережает ли она удалённую ветку, отстаёт от неё или равняется ей.

Если локальная ветка равна удалённой, в корне проекта не будет стрелок «вверх» и «вниз».

Если есть стрелка вверх, это значит, что локальная ветка опережает удалённую на указанное количество коммитов. То есть, в данном случае, в локальной ветке есть три коммита, которые не отправлены в удалённый репозиторий.

Если есть стрелка вниз, значит, локальная ветка отстаёт от удалённого хранилища на указанное количество коммитов. То есть в удалённом репозитории есть коммиты, которые мы ещё не слили.

И, наконец, возможна ситуация, когда есть обе стрелки.

В данном случае она означает, что наша ветка master опережает на два коммита и отстает на один. Это значит, что есть один коммит на сервере, который мы еще не слили, и два локальных коммита, которые мы еще не отправили.

Важно отметить, что эти цифры это информация из удалённого хранилища, которая последний раз была получена при выполнении команды Получить из origin (или Получить из. ). 1C:EDT самостоятельно не отслеживает удалённые репозитории, она только говорит вам о том, что в кеше есть локальная информация из удалённых репозиториев. Если вы хотите знать актуальное состояние опережающих и отстающих коммитов, вам необходимо получить изменения ( Получить из origin ).

Источник

2.5 Основы Git — Работа с удалёнными репозиториями

Работа с удалёнными репозиториями

Для того, чтобы внести вклад в какой-либо Git-проект, вам необходимо уметь работать с удалёнными репозиториями. Удалённые репозитории представляют собой версии вашего проекта, сохранённые в интернете или ещё где-то в сети. У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен для чтения или для чтения-записи. Взаимодействие с другими пользователями предполагает управление удалёнными репозиториями, а также отправку и получение данных из них. Управление репозиториями включает в себя как умение добавлять новые, так и умение удалять устаревшие репозитории, а также умение управлять различными удалёнными ветками, объявлять их отслеживаемыми или нет и так далее. В данном разделе мы рассмотрим некоторые из этих навыков.

Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. Слово «удалённый» не означает, что репозиторий обязательно должен быть где-то в сети или Интернет, а значит только — где-то ещё. Работа с таким удалённым репозиторием подразумевает выполнение стандартных операций отправки и получения, как и с любым другим удалённым репозиторием.

Просмотр удалённых репозиториев

Для того, чтобы просмотреть список настроенных удалённых репозиториев, вы можете запустить команду git remote . Она выведет названия доступных удалённых репозиториев. Если вы клонировали репозиторий, то увидите как минимум origin — имя по умолчанию, которое Git даёт серверу, с которого производилось клонирование:

Вы можете также указать ключ -v , чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:

Если у вас больше одного удалённого репозитория, команда выведет их все. Например, для репозитория с несколькими настроенными удалёнными репозиториями в случае совместной работы нескольких пользователей, вывод команды может выглядеть примерно так:

Это означает, что мы можем легко получить изменения от любого из этих пользователей. Возможно, что некоторые из репозиториев доступны для записи и в них можно отправлять свои изменения, хотя вывод команды не даёт никакой информации о правах доступа.

Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; подробнее мы рассмотрим протоколы в разделе Установка Git на сервер главы 4.

Добавление удалённых репозиториев

В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее. Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add :

Теперь вместо указания полного пути вы можете использовать pb . Например, если вы хотите получить изменения, которые есть у Пола, но нету у вас, вы можете выполнить команду git fetch pb :

Читайте также:  Sony cdx gt500ee как настроить время

Ветка master из репозитория Пола сейчас доступна вам под именем pb/master . Вы можете слить её с одной из ваших веток или переключить на неё локальную ветку, чтобы просмотреть содержимое ветки Пола. Более подробно работа с ветками рассмотрена в главе Ветвление в Git.

Получение изменений из удалённого репозитория — Fetch и Pull

Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:

Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта, которые вы можете просмотреть или слить в любой момент.

Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, git fetch origin извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch). Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.

Если ветка настроена на отслеживание удалённой ветки (см. следующий раздел и главу Ветвление в Git чтобы получить больше информации), то вы можете использовать команду git pull чтобы автоматически получить изменения из удалённой ветки и слить их со своей текущей. Этот способ может для вас оказаться более простым или более удобным. К тому же, по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали репозиторий. Название веток может быть другим и зависит от ветки по умолчанию на сервере. Выполнение git pull , как правило, извлекает (fetch) данные с сервера, с которого вы изначально клонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.

Начиная с версии 2.27, команда git pull выдаёт предупреждение, если настройка pull.rebase не установлена. Git будет выводить это предупреждение каждый раз пока настройка не будет установлена.

Если хотите использовать поведение Git по умолчанию (простое смещение вперёд если возможно — иначе создание коммита слияния): git config —global pull.rebase «false»

Если хотите использовать перебазирование при получении изменений: git config —global pull.rebase «true»

Отправка изменений в удаленный репозиторий (Push)

Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удалённый репозиторий. Команда для этого действия простая: git push
. Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:

Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push . Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push , а после него выполнить команду push попытаетесь вы, то ваш push точно будет отклонён. Вам придётся сначала получить изменения и объединить их с вашими и только после этого вам будет позволено выполнить push . Обратитесь к главе Ветвление в Git для более подробного описания, как отправлять изменения на удалённый сервер.

Просмотр удаленного репозитория

Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show . Выполнив эту команду с некоторым именем, например, origin , вы получите следующий результат:

Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что если вы, находясь на ветке master, выполните git pull , ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок.

Это был пример для простой ситуации и вы наверняка встречались с чем-то подобным. Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show :

Данная команда показывает какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push . Она также показывает, каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере, и для нескольких веток показано, какие удалённые ветки будут в них влиты при выполнении git pull .

Удаление и переименование удалённых репозиториев

Для переименования удалённого репозитория можно выполнить git remote rename . Например, если вы хотите переименовать pb в paul , вы можете это сделать при помощи git remote rename :

Стоит упомянуть, что это также изменит имена удалённых веток в вашем репозитории. То, к чему вы обращались как pb/master , теперь стало paul/master .

Если по какой-то причине вы хотите удалить удаленный репозиторий — вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения — вы можете использовать git remote rm :

При удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.

Источник

3.5 Ветвление в Git — Удалённые ветки

Удалённые ветки

Удалённые ссылки — это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее. Полный список удалённых ссылок можно получить с помощью команды git ls-remote или команды git remote show для получения удалённых веток и дополнительной информации. Тем не менее, более распространенным способом является использование веток слежения.

Читайте также:  Нормально ли что девушка не работает

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

Имена веток слежения имеют вид /
. Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, используйте ветку origin/master . Если вы с коллегой работали над одной задачей и он отправил на сервер ветку iss53 , при том что у вас может быть своя локальная ветка iss53 , удалённая ветка будет представлена веткой слежения с именем origin/iss53 .

Возможно, всё это сбивает с толку, поэтому давайте рассмотрим на примере. Скажем, у вас в сети есть свой Git-сервер с адресом git.ourcompany.com . Если вы с него что-то клонируете, команда clone автоматически назовёт его origin , заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка master , и назовёт его локально origin/master . Git также создаст вам локальную ветку master , которая будет начинаться там же, где и ветка master в origin , так что вам будет с чего начать.

Подобно названию ветки «master», «origin» не имеет какого-либо специального значения в Git. В то время как «master» — это название по умолчанию для ветки при выполнении git init только потому, что часто используется, «origin» — это название по умолчанию для удалённого сервера, когда вы запускаете git clone . Если вы выполните git clone -o booyah , то по умолчанию ветка слежения будет иметь вид booyah/master .

Если вы сделаете что-то в своей локальной ветке master , а тем временем кто-то отправит изменения на сервер git.ourcompany.com и обновит там ветку master , то ваши истории продолжатся по-разному. Пока вы не свяжетесь с сервером origin ваш указатель origin/master останется на месте.

Для синхронизации ваших изменений с удаленным сервером выполните команду git fetch (в нашем случае git fetch origin ). Эта команда определяет какому серверу соответствует «origin» (в нашем случае это git.ourcompany.com ), извлекает оттуда данные, которых у вас ещё нет, и обновляет локальную базу данных, сдвигая указатель origin/master на новую позицию.

Чтобы продемонстрировать, как будут выглядеть удалённые ветки в ситуации с несколькими удалёнными серверами, предположим, что у вас есть ещё один внутренний Git-сервер, который используется для разработки только одной из ваших команд разработчиков. Этот сервер находится на git.team1.ourcompany.com . Вы можете добавить его в качестве новой удалённой ссылки для текущего проекта с помощью команды git remote add , как было описано в главе Основы Git. Назовите этот удалённый сервер teamone — это имя будет сокращением вместо полного URL.

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

Отправка изменений

Когда вы хотите поделиться веткой, вам необходимо отправить её на удалённый сервер, где у вас есть права на запись. Ваши локальные ветки автоматически не синхронизируются с удалёнными при отправке — вам нужно явно указать те ветки, которые вы хотите отправить. Таким образом, вы можете использовать свои личные ветки для работы, которую не хотите показывать, а отправлять только те тематические ветки, над которыми вы хотите работать с кем-то совместно.

Если у вас есть ветка serverfix , над которой вы хотите работать с кем-то ещё, вы можете отправить её точно так же, как вы отправляли вашу первую ветку. Выполните команду git push
:

Это в некотором роде сокращение. Git автоматически разворачивает имя ветки serverfix до refs/heads/serverfix:refs/heads/serverfix , что означает «возьми мою локальную ветку serverfix и обнови ей удалённую ветку serverfix ». Мы подробно рассмотрим часть с refs/heads/ в главе Git изнутри, но обычно её можно пропустить. Вы также можете выполнить git push origin serverfix:serverfix — произойдёт то же самое — здесь говорится «возьми мою ветку serverfix и сделай её удалённой веткой serverfix ». Можно использовать этот формат для отправки локальной ветки в удалённую ветку с другим именем. Если вы не хотите, чтобы на удалённом сервере ветка называлась serverfix , то вместо предыдущей команды выполните git push origin serverfix:awesomebranch , которая отправит локальную ветку serverfix в ветку awesomebranch удалённого репозитория.

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

Если вы не хотите вводить свои данные каждый раз при отправке изменений, вы можете настроить «credential cache». Проще всего держать их в памяти несколько минут, это легко настроить с помощью команды git config —global credential.helper cache .

Для получения более подробной информации о различных вариантах кэша учётных данных обратитесь к разделу Хранилище учётных данных.

Читайте также:  Alesis io2 express не работает

В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает serverfix на сервере, как удалённую ветку origin/serverfix :

Необходимо отметить, что при получении данных создаются ветки слежения, вы не получаете автоматически для них локальных редактируемых копий. Другими словами, в нашем случае вы не получите новую ветку serverfix — только указатель origin/serverfix , который вы не можете изменять.

Чтобы слить эти наработки в свою текущую рабочую ветку, выполните git merge origin/serverfix . Если вам нужна локальная ветка serverfix , в которой вы сможете работать, то вы можете создать её на основе ветки слежения:

Это даст вам локальную ветку, в которой можно работать и которая будет начинаться там же, где и origin/serverfix .

Отслеживание веток

Получение локальной ветки из удалённой ветки автоматически создаёт то, что называется «веткой слежения» (а ветка, за которой следит локальная называется «upstream branch»). Ветки слежения — это локальные ветки, которые напрямую связаны с удалённой веткой. Если, находясь на ветке слежения, выполнить git pull , то Git уже будет знать с какого сервера получать данные и какую ветку использовать для слияния.

При клонировании репозитория, как правило, автоматически создаётся ветка master , которая следит за origin/master . Однако, при желании вы можете настроить отслеживание и других веток — следить за ветками на других серверах или отключить слежение за веткой master . Вы только что видели простейший пример, что сделать это можно с помощью команды git checkout -b
/
. Это часто используемая команда, поэтому Git предоставляет сокращённую форму записи в виде флага —track :

В действительности, это настолько распространённая команда, что существует сокращение для этого сокращения. Если вы пытаетесь извлечь ветку, которая не существует, но существует только одна удалённая ветка с точно таким же именем, то Git автоматически создаст ветку слежения:

Чтобы создать локальную ветку с именем, отличным от имени удалённой ветки, просто укажите другое имя:

Теперь ваша локальная ветка sf будет автоматически получать изменения из origin/serverfix .

Если у вас уже есть локальная ветка и вы хотите настроить ее на слежение за удалённой веткой, которую вы только что получили, или хотите изменить используемую upstream-ветку, то воспользуйтесь параметрами -u или —set-upstream-to для команды git branch , чтобы явно установить новое значение.

Если у вас настроена отслеживаемая ветка, вы можете ссылаться на нее с помощью сокращений @ или @ . Итак, если вы находитесь на ветке master и она следит за origin/master , при желании вы можете использовать git merge @ вместо git merge origin/master .

Если вы хотите посмотреть как у вас настроены ветки слежения, воспользуйтесь опцией -vv для команды git branch . Это выведет список локальных веток и дополнительную информацию о том, какая из веток отслеживается, отстаёт, опережает или всё сразу относительно отслеживаемой.

Итак, здесь мы видим, что наша ветка iss53 следит за origin/iss53 и «опережает» её на два изменения — это значит, что у нас есть два локальных коммита, которые не отправлены на сервер. Мы также видим, что наша ветка master отслеживает ветку origin/master и находится в актуальном состоянии. Далее мы можем видеть, что локальная ветка serverfix следит за веткой server-fix-good на сервере teamone , опережает её на три коммита и отстает на один — это значит, что на сервере есть один коммит, который мы ещё не слили, и три локальных коммита, которые ещё не отправлены на сервер. В конце мы видим, что наша ветка testing не отслеживает удаленную ветку.

Важно отметить, что эти цифры описывают состояние на момент последнего получения данных с каждого из серверов. Эта команда не обращается к серверам, а лишь говорит вам о том, какая информация с этих серверов сохранена в локальном кэше. Если вы хотите иметь актуальную информацию об этих числах, вам необходимо получить данные со всех ваших удалённых серверов перед запуском команды. Сделать это можно вот так:

Получение изменений

Команда git fetch получает с сервера все изменения, которых у вас ещё нет, но не будет изменять состояние вашей рабочей копии. Эта команда просто получает данные и позволяет вам самостоятельно сделать слияние. Тем не менее, существует команда git pull , которая в большинстве случаев является командой git fetch , за которой непосредственно следует команда git merge . Если у вас настроена ветка слежения как показано в предыдущем разделе, или она явно установлена, или она была создана автоматически командами clone или checkout , git pull определит сервер и ветку, за которыми следит ваша текущая ветка, получит данные с этого сервера и затем попытается слить удалённую ветку.

Обычно, лучше явно использовать команды fetch и merge , поскольку магия git pull может часто сбивать с толку.

Удаление веток на удалённом сервере

Скажем, вы и ваши соавторы закончили с нововведением и слили его в ветку master на удалённом сервере (или в какую-то другую ветку, где хранится стабильный код). Вы можете удалить ветку на удалённом сервере используя параметр —delete для команды git push . Для удаления ветки serverfix на сервере, выполните следующую команду:

Всё, что делает эта строка — удаляет указатель на сервере. Как правило, Git сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.

Источник

Adblock
detector