Как посмотреть удаленные ветки в git

Восстановление удаленной ветви Git с веб-портала

В этой статье описывается, как восстановить удаленную ветвь Git с помощью веб-портала в Azure Repos. Если вам нужно восстановить ветвь Git в собственном репозитории из Visual Studio или из командной строки, отправьте ее из локального репозитория в Azure Repos, чтобы восстановить ее.

Политика хранения для удаленных ветвей отсутствует. Удаленную ветвь Git можно восстановить в любое время независимо от того, когда она была удалена.

1. Откройте репозиторий в Интернете и выберите представление Ветви.
2. Выполните поиск точного имени ветви с помощью поля Поиск всех ветвей в правом верхнем углу.
3. Щелкните ссылку Поиск точного соответствия в удаленных ветвях. Если есть удаленная ветвь, соответствующая поиску, вы сможете увидеть, на какую фиксацию она указывала, когда она была удалена, кто ее удалил и когда она была удалена.
4. Чтобы восстановить ветвь, щелкните значок . рядом с именем ветви, а затем в меню выберите Восстановить ветвь . Ветвь будет повторно создана при последней фиксации, на которую она указала. Обратите внимание, что политики и разрешения ветвей не будут восстановлены.

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

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

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

Git для начинающих. Урок 8.
Ветки на сервере

Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

Просмотр веток на сервере

• git branch выводит список локальных веток
• git branch -r (remote) — список веток на сервере
• git branch -a (all) — список всех веток, локальных и удаленных

Удаленные ветки начинаются с remotes/origin/

 $ git branch master * news $ git branch -a master * news remotes/origin/master remotes/origin/news remotes/origin/students 

Как отслеживать новые ветки на сервере

Если мы в проекте не одни, то в нем будут постоянно появляться новые ветки. Но как их увидеть?

Допустим, у нас в проекте есть только ветка master. В это время кто-то добавил новую ветку news. Просто git branch -a удаленные ветки не покажет

 $ git branch -a * master remotes/origin/master 

Чтобы их увидеть, сначала нужно выполнить команду git fetch, которая сходит на сервер и проверит, что там есть нового

 $ git fetch remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Compressing objects: 100% (3/3), done. remote: Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), done. From github.com:Webdevkin/site-git * [new branch] news -> origin/news 

Мы видим, что появилась новая ветка news, и команда git branch -a это подтверждает

 $ git branch -a * master remotes/origin/master remotes/origin/news 

Обратите внимание, ветка news появилась только в списке удаленных, но не локальных. То есть команда git fetch не создает локальные ветки, она просто подтягивает информацию о них. Чтобы переключиться на новую ветку, нужно выполнить git checkout

 $ git checkout news Branch news set up to track remote branch news from origin. Switched to a new branch 'news' 

Вот теперь мы переключились на новую ветку

 $ git branch -a master * news remotes/origin/master remotes/origin/news 

Как удалить ветку с сервера

Выполняем пуш ветки, только с флагом —delete

 $ git push origin --delete news To git@github.com:Webdevkin/site-git.git - [deleted] news 

Как работать с удаленными ветками в PhpStorm

Точно так же, как и с локальными, только в списке Remote Branches. Чтобы увидеть новые ветки, тоже нужно выполнить команду fetch. Правый клик — Git — Repository — Fetch. А уже потом можно переключаться на эту ветку: Remote Branches — branch_name — Checkout as.

Что могу посоветовать

• регулярно просматривайте github — так вы будете лучше понимать, чем занимаются ваши коллеги
• не забывайте делать git fetch перед переключением на удаленную ветку
• обсудите с коллегами правила именования веток и соблюдайте их

Я не в первый раз упоминаю про именование коммитов и веток. Если вы работаете один, то как называть — ваше дело. Но если работаете в команде, то несоблюдение каких-то правил могут привести примерно к этому

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

На этом все. В следующем уроке мы поговорим о слиянии или мерджах веток.

Спасибо за внимание и до встречи!

Все уроки курса

• Вводный урок
• 1. Установка и базовая настройка git
• 2. Создание и клонирование репозитория git
• 3. Делаем первые изменения, git status и git diff
• 4. Коммиты и история коммитов, git commit, git log и git show
• 5. Подробнее об истории коммитов. Путешествие по истории
• 6. Работа с сервером, git push и git pull
• 7. Ветки — главная фишка git, git branch и git checkout
• 8. Работа с ветками на сервере, git fetch
• 9. Слияния или мерджи веток, git merge
• 10. Конфликты и их разрешение
• Платная часть курса. Презентация
• * 11. Работа с gitignore и git exclude
• * 12. Буфер обмена git, git stash
• * 13. Копирование коммитов, git cherry-pick
• * 14. Отмена и редактирование последнего коммита
• * 15. Отмена произвольного коммита, git revert
• 16. Склеивание коммитов, git rebase —interactive и git reflog
• * 17. Зачем склеивать коммиты. Плюсы и минусы сквоша
• * 18. Работа с git rebase. Отличия от merge
• * 19. Что такое git push —force и как с ним работать
• * 20. Ищем баги с помощью git, git bisect
• * 21. Как и зачем работать с тегами git
• * 22. Процессы: github flow и git flow
• * 23. Псевдонимы в git
• 24. Мердж-реквесты
• * 25. Форки

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 , так что вам будет с чего начать.

Примечание

«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 . Назовите этот удалённый сервер teamone – это имя будет сокращением вместо полного URL.

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

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

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

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

$ git push origin serverfix Counting objects: 24, done. Delta compression using up to 8 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done. Total 24 (delta 2), reused 0 (delta 0) To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfix

Это в некотором роде сокращение. 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 .

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

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

$ git fetch origin remote: Counting objects: 7, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix

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

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

$ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

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

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

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

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

$ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

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

$ git checkout serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

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

$ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf'

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

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

$ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin.

Примечание

Сокращение upstream

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

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

$ git branch -vv iss53 7e424c3 [origin/iss53: ahead 2] Add forgotten brackets master 1ae2a45 [origin/master] Deploy index fix * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it testing 5ea463a Try something new

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

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

$ git fetch --all; git branch -vv

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

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

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

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

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

$ git push origin --delete serverfix To https://github.com/schacon/simplegit - [deleted] serverfix

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

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

это ссылки на состояние веток в ваших удалённых репозиториях.

Это локальные ветки, которые нельзя перемещать. Они двигаются автоматически всякий раз, когда вы осуществляете связь по сети. Удалённые ветки действуют как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.

Они выглядят как /. Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, проверьте ветку origin/master . Если вы с партнёром работали над одной проблемой, и он выложил ветку feature/53 , у вас может быть своя локальная ветка feature/53 . Но та ветка на сервере будет указывать на коммит в origin/feature/53 . Всё это, возможно, сбивает с толку, поэтому давайте рассмотрим пример.

Скажем, у вас в сети есть свой Git-сервер. Если вы с него что-то склонируете ( Клонировать репозиторий Git ), Git автоматически назовёт его origin , заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка master , и назовёт его локально origin/master .

Git также сделает вам вашу собственную локальную ветку master , которая будет начинаться там же, где и ветка master в origin , так что вам будет с чем работать.

Примечание: origin это не специальное название. Подобно тому, как название ветки master не имеет какого-либо специального значения в Git’е, название origin это тоже просто название. Исходная ветка репозитория называется master по единственной причине, потому, что это название широко используется. Также и origin , это название по умолчанию для удалённой ветки после клонирования. Если вы хотите назвать удалённый репозиторий narnia , вы можете это сделать в диалоге клонирования, и ваша удалённая ветка по умолчанию будет называться narnia/master .

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

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

Для синхронизации вашей работы выполняется команда Групповая разработка > > Получить из origin . Эта команда ищет, какому репозиторию соответствует origin , извлекает оттуда все данные, которых у вас ещё нет, обновляет ваш локальный репозиторий, и сдвигает указатель origin/master на новую позицию.

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

Теперь можете выполнить Групповая разработка > > Удаленный репозиторий > > Получить из. > teamone , чтобы извлечь всё, что есть на сервере, и нет у вас. Так как в данный момент на этом сервере есть только часть данных, которые есть на сервере origin , Git не получает никаких данных, но выставляет удалённую ветку с именем teamone/master , которая указывает на тот же коммит, что и ветка master на сервере teamone .