Git как создать ветку в удаленном репозитории

Шпаргалка по командам git
Что делать, когда под руками нет SourceTree

У нас есть задача (issue), которую мы планируем сделать. В центральном репозитории создаём ветку для решения задачи. Например, для задачи с номером 234 создаём ветку features/issue-234.

Примечание: префикс features/ влияет на отображение > веток в таких графических клиентах, как Git Extensions и Sourcetree. Ветки, в чьих именах встреыется символ / выглядят как файлы в каталогах. Так, ветка features/issue-234 выглядит как ветка issue-234 в каталоге features.

Так удобно группировать ветки.

Шаг 2

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

Сначала скачиваем из удалённого репозитория изменения, включая новые ветки

git fetch 

Чтобы убедиться, что удалённая ветка доступна локально, выполняем команду

git branch -a 

Создаём локальную ветку, которая указывает на удалённую ветку

git checkout -b features/issue-234 origin/features/issue-234 

git checkout -t origin/features/issue-234 

Шаг 3

Далее работаем над задачей в локальной ветке, время от времени фиксируя изменения.

Прежде, чем фиксировать, смотрим, что успели сделать.

git status 

• Untracked — git не отслеживает изменения в этих файлах и не хранит их.
• Changes not staged for commit — git отлеживает и хранит эти файлы. Сейчас эти файлы изменены, но git не будет сохранять эти изменения при фиксации.
• Changes to be committed — файлы изменены и git сохранит эти изменения при следующей фиксации.

Помечаем для фиксации файлы file₁..fileₙ.

git add file₁ . fileₙ 

Помечаем для фиксации все файлы в текущем каталоге и его подкаталогах. Помеченными окажутся в том числе все новые файлы.

git add . 

Фиксируем все файлы, помеченные для фиксации. Git попросит ввести комментарий.

git commit 

Команда git commit -a работает также, как git add . и git commit вместе, за тем исключением, что новые файлы не будут зафиксированы.

Команда git commit -m «Комментарий к коммиту» фиксирует изменения с указанным комментарием, не запуская внешний редактор.

Отправляем изменения в центральный репозиторий.

git push 

Откат изменений

Если вы изменили файлы, но ещё не фиксировали изменения, вы можете изменить отдельные файлы:

git checkout -- file₁ . fileₙ 

Либо вы можете отказить изменения во всех файлах в каталоге и его подкаталогах:

git checkout -- . 

Если вы зафиксировали изменения, но ещё не отправили их в удалённый репозиторий, откатите последнюю фиксацию:

git reset --hard 

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

git revert

Если вы случайно добаили к списку отслеживаемых файлов что-то, что не надо отслеживать, например, временные файлы *.tmp или результаты компиляции *.obj, вы можете удалить их из репозитория:

git rm --cached file₁ . fileₙ 

Без флага —cached git удалит файлы и в репозитории, и на диске. Эта же команда используется, если вы обновили .gitignore и хотите удалить из репозитория файлы, которые соответствуют новым правилам .gitignore:

git rm --cached . git add . 

Первая команда удалит из репозитория всех файлы (оставив их на диске), а вторая снова добавит их в репозиторий. При добавлении git проверит файлы на соответствие шаблонам .gitignore.

Удалить с диска новые файлы

git clean -f -d 

Шаг 4

Решив задачу мы должны слить все изменения в основную ветку — master или main. Это делается через pull request в центральном репозитории. Ставим галочку удалить исходную ветку после слияния, чтобы не пришлось удалять эти ветку вручную.

Теперь надо избавиться от локальной ветки, где мы работали. Сначала переключимся на основную ветку.

git checkout master 

«Затягиваем» в неё изменения из центрального репозитория.

git fetch 

После изменения можно слить с текущей веткой:

git merge 

После слияния в истории репозитория остаются «следы» — коммиты сначла расходятся, потом снова сходятся. Можно избавиться от следов, склеив все коммиты в одну ветку:

git rebase 

git fetch git merge 

Git checkout

На этой странице рассматривается команда git checkout , включая примеры использования и пограничные случаи. В Git под термином checkout подразумевают переключение между различными версиями целевого объекта. Команда git checkout работает с тремя различными объектами: файлами, коммитами и ветками. Под переключением также обычно понимают действие, связанное с выполнением команды git checkout . В рамках темы «Отмена изменений» мы рассмотрели, каким образом команду git checkout можно использовать для просмотра старых коммитов. В этом документе основное внимание будет уделено операциям переключения на ветки.

Переключение веток аналогично переключению старых коммитов и файлов, в которых рабочий каталог обновляется в соответствии с выбранной веткой/ревизией; вместе с тем новые изменения сохраняются в истории проекта, то есть это не просто операция чтения.

Переключение веток

Команда git checkout позволяет перемещаться между ветками, созданными командой git branch . При переключении ветки происходит обновление файлов в рабочем каталоге в соответствии с версией, хранящейся в этой ветке, а Git начинает записывать все новые коммиты в этой ветке. Рассматривайте эту команду как способ выбрать направление своей разработки.

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

Иногда команду git checkout можно спутать с командой git clone . Разница между этими двумя командами заключается в том, что при клонировании (clone) выполняется извлечение кода из удаленного репозитория, тогда как при переключении (checkout) происходит переключение между версиями кода, который уже находится в локальной системе.

Связанные материалы

Расширенный журнал Git

СМ. РЕШЕНИЕ

Изучите Git с помощью Bitbucket Cloud

Использование: существующие ветки

Если предположить, что ваш рабочий репозиторий уже содержит существующие ветки, вы можете переключаться между этими ветками с помощью команды git checkout . Чтобы узнать, какие ветки доступны и как называется текущая ветка, выполните команду git branch .

$＞ git branch 
main 
another_branch 
feature_inprogress_branch 
$＞ git checkout feature_inprogress_branch

В вышеприведенном примере показано, как просмотреть список доступных веток с помощью команды git branch и переключиться на конкретную ветку (в данном случае — на ветку feature_inprogress_branch ).

Новые ветки

Команда git checkout часто используется вместе с командой git branch. С помощью команды git branch можно создать новую ветку. Когда вы захотите начать работу над новой функцией, создайте новое ответвление от ветки main с помощью команды git branch new_branch . Затем переключитесь на новую ветку с помощью команды git checkout new_branch . Команда git checkout также принимает аргумент -b , который действует как вспомогательный метод, позволяя создать новую ветку и сразу переключиться на нее. Вы можете работать сразу с несколькими функциями в одном репозитории, переключаясь между ними с помощью git checkout .

git checkout -b ＜new-branch＞

В вышеприведенном примере одновременно создается ветка и сразу же выполняется переключение на нее. Опция -b — это удобный способ сообщить системе Git, чтобы она выполнила команду git branch перед выполнением команды git checkout .

git checkout -b ＜new-branch＞ ＜existing-branch＞

По умолчанию команда git checkout -b создает ветку новая-ветка от текущего указателя HEAD . Команде git checkout можно передать необязательный параметр с указанием ветки. В приведенном выше примере передается ＜ существующая-ветка> , поэтому новая-ветка будет создана от ветки существующая-ветка , а не от текущего указателя HEAD .

Переключение веток

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

git checkout ＜branchname＞

Git отслеживает историю операций переключения в журнале ссылок reflog. Чтобы просмотреть эту историю, выполните команду git reflog .

Переключение на удаленную ветку

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

git fetch --all

В современных версиях Git переключение на удаленную ветку не отличается от переключения на локальную ветку.

git checkout ＜remotebranch＞

В старых версиях Git необходимо создавать новую ветку на основе удаленного репозитория ( remote ).

git checkout -b ＜remotebranch＞ origin/＜remotebranch＞

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

git checkout -b ＜branchname＞
git reset --hard origin/＜branchname＞

Открепленные указатели HEAD

Теперь, когда мы рассмотрели три основных варианта использования команды git checkout на ветках, важно обсудить состояние detached HEAD , или состояние открепленного указателя HEAD. Помните, что HEAD — это указатель на текущий снимок в Git. По сути дела, команда git checkout просто обновляет указатель HEAD , чтобы он ссылался на указанную ветку или коммит. Когда HEAD указывает на ветку, Git молчит, но при попытке переключиться на коммит система переходит в состояние detached HEAD (открепленный указатель HEAD).

Это сообщение предупреждает о том, что вся текущая работа «откреплена» от остальной части вашего проекта. Если вы начнете разрабатывать функцию, находясь в состоянии открепленного указателя HEAD , у вас не будет ветки, которая позволила бы вам вернуться к этой функции. Когда вы неизбежно переключитесь на другую ветку (например, чтобы слить код своей функции), вы уже никак не сможете сослаться на свою функцию:

Всегда ведите разработку на ветке, а не на открепленном указателе HEAD . Это гарантия того, что у вас всегда будет ссылка на ваши новые коммиты. Вместе с тем при просмотре предыдущего коммита состояние указателя HEAD не имеет значения: он может быть как откреплен, так и нет.

Резюме

На этой странице было рассмотрено использование команды git checkout при смене ветки. В общем и целом при использовании команды git checkout на ветках происходит изменение позиции указателя HEAD . С помощью этой команды можно создавать ветки, менять текущую ветку и переключаться на удаленные ветки. Команда git checkout — важный инструмент при стандартной работе в Git. Она представляет собой аналог команды git merge. Команды git checkout и git merge критически важны для реализации рабочих процессов Git.

Создать и отправить ветку в удаленный репозиторий Git.

В этом посте мы обсудим, как создать и отправить ветку в удаленный репозиторий Git.

Идея здесь проста. Сначала вы создаете ветку локально и отправляете ее в удаленный репозиторий. Мы можем сделать это двумя способами:

1. git-касса

Мы можем использовать git-checkout команда с -b возможность создать новую ветку. Он создает новую ветку с указанным именем, а затем проверяет ее.

# Create a branch locally and check it out
git checkout -b

# Push the branch to the remote and set upstream
git push [-u | —set-upstream]

Здесь является удаленной текущей веткой (обычно источником) и это название ветки. —set-upstream (или же -u ) установить восходящую ветвь для данной ветки. Если —set-upstream опция пропущена, git pull и некоторые другие команды не будут выполняться. Вы также можете отправить новую ветку вверх по течению позже с помощью git push -u команда.

2. git-ветка

Другим вариантом является использование git-branch . Следующий код создаст новую ветку с именем , который указывает на текущую ветку HEAD а затем отправить его в удаленный репозиторий.

# Creates a local branch
git branch

# Push the branch to the remote and set upstream
git push [-u | —set-upstream]

Это все о создании и отправке ветки в удаленный репозиторий Git.

Оценить этот пост

Средний рейтинг 5 /5. Подсчет голосов: 23

Голосов пока нет! Будьте первым, кто оценит этот пост.

Сожалеем, что этот пост не оказался для вас полезным!

Расскажите, как мы можем улучшить этот пост?

Спасибо за чтение.

Пожалуйста, используйте наш онлайн-компилятор размещать код в комментариях, используя C, C++, Java, Python, JavaScript, C#, PHP и многие другие популярные языки программирования.

Как мы? Порекомендуйте нас своим друзьям и помогите нам расти. Удачного кодирования 🙂

Подписывайся
0 Комментарии
Встроенные отзывы
Просмотреть все комментарии
Загрузить больше комментариев
Просматривать
Подпишитесь на новые публикации

• Все проблемы
• Практика DSA
• 100 самых популярных задач
• 50 лучших классических задач
• Лучшие алгоритмы

• Компилятор С/С++
• Компилятор Java
• Компилятор Python
• Компилятор JavaScript
• компилятор PHP
• Компилятор C#

• Свяжитесь с нами
• Политика конфиденциальности
• условия обслуживания
• Подпишитесь на новые публикации

Techie Delight © 2023 Все права защищены.

Этот веб-сайт использует файлы cookie. Используя этот сайт, вы соглашаетесь с использованием файлов cookie, нашей политикой, условиями авторского права и другими условиями. Читайте наши Политика конфиденциальности. Понятно

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 .

Рисунок 30. Серверный и локальный репозитории после клонирования

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

Рисунок 31. Локальная и удалённая работа может расходиться

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

Рисунок 32. git fetch обновляет ветки слежения

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

Рисунок 33. Добавление ещё одного сервера в качестве удалённой ветки

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

Рисунок 34. Ветка слежения teamone/master

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

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

Если у вас есть ветка 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 сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.