Основы git за 5 минут

Введение¶

Git (произн. «гит») — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux. На сегодняшний день поддерживается Джунио Хамано.

Система спроектирована как набор программ, специально разработанных с учётом их использования в скриптах. Это позволяет удобно создавать специализированные системы контроля версий на базе Git или пользовательские интерфейсы. Например, Cogito является именно таким примером фронтенда к репозиториям Git, а StGit использует Git для управления коллекцией патчей.

Git поддерживает быстрое разделение и слияние версий, включает инструменты для визуализации и навигации по нелинейной истории разработки. Как и Darcs, BitKeeper, Mercurial, SVK, Bazaar и Monotone, Git предоставляет каждому разработчику локальную копию всей истории разработки; изменения копируются из одного репозитория в другой.

Удалённый доступ к репозиториям Git обеспечивается git-daemon, gitosis, SSH- или HTTP-сервером. TCP-сервис git-daemon входит в дистрибутив Git и является наряду с SSH наиболее распространённым и надёжным методом доступа. Метод доступа по HTTP, несмотря на ряд ограничений, очень популярен в контролируемых сетях, потому что позволяет использовать существующие конфигурации сетевых фильтров.

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

Вводный урок
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. Форки

* платные уроки

список обновляется…

8 ответов

Лучший ответ

Как говорит Дифур, ваша ситуация мало чем отличается от ситуации в Измените URI (URL) удаленного репозитория Git. Когда вы репозиторий, он добавляется как ваш под именем . Что вам нужно сделать сейчас (поскольку вы больше не используете старый источник), так это изменить URL-адрес :

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

Или, может быть, даже назовите старую :

Затем, когда вы захотите получить изменения из , вы можете:

Поскольку этот источник является образцом репозитория (кажется, своего рода шаблоном для начала), я не думаю, что его нужно хранить или разветвлять вообще — здесь я выберу первую альтернативу.

131

Community
23 Май 2017 в 11:54

GitHub: чужой репозиторий и ваш собственный репозиторий

Я буду называть чужой репозиторий другим репозиторием .

Создайте новый репозиторий на github.com. (это ваш репозиторий )
- Дайте ему то же имя, что и другой репозиторий .
- Не инициализируйте его с помощью README, .gitignore или лицензии.
Клонируйте другой репозиторий на свой локальный компьютер. (если вы еще этого не сделали)

git clone https://github.com/other-account/other-repository.git
Переименуйте текущий локальный репозиторий » origin » в » upstream «.

git remote rename origin upstream
Дайте локальному репозиторию » origin «, который указывает на ваш репозиторий .

git remote add origin https://github.com/your-account/your-repository.git
Переместите локальный репозиторий в ваш репозиторий на github.

Теперь ‘ origin ‘ указывает на ваш репозиторий , а ‘ upstream ‘ указывает на другой репозиторий .

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

Derek Soike
19 Мар 2018 в 16:52

Идея состоит в том, чтобы удалить и повторно инициализировать.

перейдите в свою клонированную папку репо rm -rf .git
повторно инициализируйте его, а затем добавьте свой пульт и сделайте первое нажатие.

MAOXU
14 Дек 2017 в 04:32

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

Тогда вы можете позвонить:

Чтобы заменить установленный по умолчанию пульт «origin», вы можете запустить следующее:

bmorgan21
13 Авг 2013 в 03:50

Я думаю, что «самый вежливый способ» сделать это:

Разветвите исходное репо в своей учетной записи GitHub
Проверьте новую ветку для ваших изменений (на случай, если вы не сделали этого раньше)
Добавьте новый пульт для вашего локального репозитория:
Отправьте свою новую красивую ветку в репозиторий github:

Таким образом, у вас будет репо, разветвленное на исходное, а ваши изменения будут внесены в отдельную ветку. Это будет проще, если вы хотите отправить запрос на перенос в исходное репо.

llekn
3 Апр 2017 в 18:19

Взято из Git перемещает все в новое происхождение

В основном вам нужно связать новое репо с вашей папкой

Community
23 Май 2017 в 12:10

У меня была аналогичная ситуация, но в моем случае мне просто нужно было сделать, как предлагалось, но с https , например:

T J
25 Мар 2016 в 06:12

После клонирования скопируйте файлы из их папки в новую и начните заново с помощью git init,

У меня была аналогичная проблема, и мне пришлось изменить каталог папки, прежде чем я смог внести изменения в свое репо.

Или вы можете удалить текущий источник репозитория с помощью команды git remote remove origin.

F. X. Blankson
16 Авг 2020 в 17:23

Подмодули

Клонирование репозитория с подмодулями

При клонировании репозитория вам необходимо инициализировать и обновить подмодули:

Запуск данной команды эквивалентен запуску команды:

после обычного клонирования репозитория

Обновление подмодулей

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

Для получения состояния последнего коммита всех подмодулей необходимо выполнить
следующую команду:

или использовать аргументы по умолчанию команды git pull:

Эта команда просто обновляет локальную рабочую копию. При запуске команды git status
каталоги подмодулей будут показаны изменёнными. Чтобы обновить репозиторий необходимо
зафиксировать изменения:

Для получения состояние последнего коммита конкретного подмодуля необходимо использовать команду:

Добавление подмодулей

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

После этого необходимо добавить и зафиксировать новый файл .gitmodules. В нём описано
какие подмодули следует клонировать при запуске команды git submodule update

Как сгенерировать ssh-ключ

ssh-ключи сами собой не появляются, но стоит проверить, возможно, они были установлены раньше. Запустим в терминале команды

Если видим файлы id_rsa и id_rsa.pub — отлично, ключи уже есть.

Если этих файлов нет, то нужно сгенерировать ключи утилитой ssh-keygen. В Windows она устанавливается вместе с git, в Linux и MacOS при необходимости установите. В Linux, например, вот так

После этого нужно сгенерировать пару ключей, запустив команду в терминале

Проверяем

Появились файлы id_rsa и id_rsa.pub — значит, ключи успешно сгенерированы.

known_hosts — это файл, в котором ssh прописывает сервера, на которые мы заходим.
При первом подключении к github нужно будет разрешить доступ к github.com (напечатать yes в терминале)

7 ответов

Лучший ответ

(1) Внутри локального репозитория git создайте новый файл sh

(2) Вставьте приведенный ниже контент в файл :

(3) Получить все ветки:

(4) Проверьте результат в локальном репозитории:

Например, я использую репозиторий: https://github.com/donhuvy/spring-boot

Как видите, я получил все ветки на локальный компьютер:

Raktim Biswas
8 Май 2020 в 13:45

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

После клонирования репо запустите

Это покажет вам все удаленные ветки.

Если вы хотите работать с удаленной веткой, вам необходимо создать локальную ветку отслеживания:

Убедитесь, что вы находитесь в нужной ветке, с помощью следующей команды;

Результат будет таким;

Обратите внимание на знак *, обозначающий текущую ветвь. 46

Amit Gupta
29 Окт 2016 в 05:52

Затем после клонирования репо со всеми его ветвями выполните следующие действия.

Amen Ra
11 Фев 2017 в 05:00

Ветви по сути являются указателями на коммиты. Когда вы выполняете (или ), вы получаете все коммиты из удаленного репозитория, а также все его ветки.

Однако по умолчанию не показывает удаленные ветви. Вместо этого он показывает ваши локальные ветки, которые могут иметь или не иметь никакого отношения к ветвям, существующим на удаленном компьютере. Если вы запустите , git сообщит обо всех известных ему ветвях, как локальных, так и удаленных.

Стоит отметить, что теги не работают таким образом, и нет различия между локальным и удаленным тегами.

Xiong Chiamiov
28 Окт 2016 в 20:10

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

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

Теперь вы получаете полную копию исходного репозитория, но поскольку он находится в режиме , у вас нет рабочего дерева. Фактически у вас есть папка , включая все ветки и контент. Это причудливый способ сказать, что у вас не будет прямого доступа к файлам, потому что они спрятаны в системе git (в сжатом виде и т. Д.).

Чтобы сделать это «обычным» репозиторием git, нам нужно сделать это клонирование папки в новую папку, которая будет нашей обычной папкой репо:

Обратите внимание, что не существует единой собственной команды git для загрузки всех удаленных веток, поэтому самый простой способ — убедиться, что все коммиты отправлены в источник, а затем повторно загрузить весь репозиторий заново с помощью этой опции —mirror. 3

togume
21 Авг 2018 в 15:20

Я считаю, что это простое решение для клонирования репозитория git и всех удаленных веток:

Stryker
11 Июн 2019 в 15:48

Что делает ваше репо полностью идентичным.

См. https://help.github.com/en/articles/duplicating- а-репозиторий

feng zhang
1 Апр 2020 в 15:18

Основы работы с удаленным репозиторием¶

git clone — создание копии (удаленного) репозитория

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

Клонируем репозиторий, используя протокол http:

git clone http://user@somehost:port/~user/repository/project.git

Клонируем репозиторий с той же машины в директорию :

git clone /home/username/project myrepo

Клонируем репозиторий, используя безопасный протокол ssh:

git clone ssh://user@somehost:port/~user/repository

У git имеется и собственный протокол:

git clone git://user@somehost:port/~user/repository/project.git/

Импортируем svn репозиторий, используя протокол http:

git svn clone -s http://repo/location

-s

git fetch и git pull — забираем изменения из центрального репозитория

Для синхронизации текущей ветки с репозиторием используются команды git fetch и git pull.

git fetch — забрать изменения удаленной ветки из репозитория по умолчания, основной ветки; той, которая была использована при клонировании репозитория. Изменения обновят удаленную ветку (remote tracking branch), после чего надо будет провести слияние с локальной ветку командой git merge.

git fetch /home/username/project — забрать изменения из определенного репозитория.

Возможно также использовать синонимы для адресов, создаваемые командой :

git remote add username-project /home/username/project

git fetch username-project — забрать изменения по адресу, определяемому синонимом.

Естественно, что после оценки изменений, например, командой , надо создать коммит слияния с основной:

git merge username-project/master

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

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

git pull

Забрать изменения и метки из определенного репозитория:

git pull username-project --tags

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

git push — вносим изменения в удаленный репозиторий

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

Отправить свои изменения в удаленную ветку, созданную при клонировании по умолчанию:

git push

Отправить изменения из ветки master в ветку experimental удаленного репозитория:

git push ssh://yourserver.com/~you/proj.git master:experimental

В удаленном репозитории origin удалить ветку experimental:

git push origin :experimental

В удаленную ветку master репозитория origin (синоним репозитория по умолчанию) ветки локальной ветки master:

git push origin master:master

Отправить метки в удаленную ветку master репозитория origin:

git push origin master --tags

Изменить указатель для удаленной ветки master репозитория origin (master будет такой же как и develop)

git push origin origin/develop:master

Добавить ветку test в удаленный репозиторий origin, указывающую на коммит ветки develop:

git push origin origin/develop:refs/heads/test

Каковы основные различия между раздвоением и клонированием?

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

Разветвление делается на аккаунт github, а клонирование осуществляется с использованием git. При форке репозитория вы создаете копию исходного репозитория (вышестоящего репозитория), но этот репозиторий остается в вашей учетной записи GitHub. В то же время, когда вы клонируете репозиторий, он копируется на вашу локальную машину с помощью Git.

Раздвоение — это понятие, а клонирование — это процесс. Разветвление — это просто содержащая отдельную копию репозитория команда, которая не участвует в этом процессе. Клонирование выполняется с помощью команды «git clone», и это процесс получения всех файлов кода на локальную машину.

Прочие команды и необходимые возможности

Хэш — уникальная идентификация объектов

В git для идентификации любых объектов используется уникальный (то есть с
огромной вероятностью уникальный) хэш из 40 символов, который определяется
хэшируюшей функцией на основе содержимого объекта. Объекты — это все: коммиты,
файлы, тэги, деревья. Поскольку хэш уникален для содержимого, например, файла,
то и сравнивать такие файлы очень легко — достаточно просто сравнить две строки
в сорок символов.

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

Ищет разницу текущего состояния проекта и коммита за номером… сами видите,
каким:

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

Иногда хватает и четырех символов:

Читает лог с коммита по коммит:

Разумеется, человеку пользоваться хэшами не так удобно, как машине, именно
поэтому были введены другие объекты — тэги.

git tag — тэги как способ пометить уникальный коммит

Тэг (tag) — это объект, связанный с коммитом; хранящий ссылку на сам коммит,
имя автора, собственное имя и некоторый комментарий. Кроме того, разработчик
может оставлять на таких тегах собственную цифровую подпись.

Кроме этого в git представленные так называемые «легковесные тэги» (lightweight
tags), состоящие только из имени и ссылки на коммит. Такие тэги, как правило,
используются для упрощения навигации по дереву истории; создать их очень легко.

Создаёт «легковесный» тэг, связанный с последним коммитом; если тэг уже есть,
то еще один создан не будет:

Помечает определенный коммит:

Удаляет тег:

Перечисляет тэги:

Создаёт тэг для последнего коммита, заменяет существующий, если таковой уже был:

После создания тэга его имя можно использовать вместо хэша в любых командах
вроде git diff, git log и так далее:

Обычные тэги имеет смысл использовать для приложения к коммиту какой-либо
информации, вроде номера версии и комментария к нему. Иными словами, если в
комментарии к коммиту пишешь «исправил такой-то баг», то в комментарии к тэгу по
имени «v1.0» будет что-то вроде «стабильная версия, готовая к использованию».

Создаёт обычный тэг для последнего коммита; будет вызван текстовый редактор для
составления комментария:

Создаёт обычный тэг, сразу указав в качестве аргумента комментарий:

Команды перечисления, удаления, перезаписи для обычных тэгов не отличаются от
команд для «легковесных» тэгов.

Относительная адресация

Вместо ревизий и тэгов в качестве имени коммита можно опираться на еще один
механизм — относительную адресацию. Например, можно обратиться прямо к предку
последнего коммита ветки master:

Если после «птички» поставить цифру, то можно адресоваться по нескольким предкам
коммитов слияния:

Ищет изменения по сравнению со вторым предком последнего коммита в master; HEAD
здесь — указатель на последний коммит активной ветки.

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

Что привнес «дедушка» нынешнего коммита:

То же самое:

Обозначения можно объединять, чтобы добраться до нужного коммита:

Файл .gitignore — объясняем git, какие файлы следует игнорировать

Иногда по директориям проекта встречаются файлы, которые не хочется постоянно
видеть в сводке git status. Например, вспомогательные файлы текстовых редакторов,
временные файлы и прочий мусор.

Заставить git status игнорировать определенные файлы можно, создав в корне или
глубже по дереву (если ограничения должны быть только в определенных директория)
файл .gitignore. В этих файлах можно описывать шаблоны игнорируемых файлов
определенного формата.

Пример содержимого такого файла:

Существуют и другие способы указания игнорируемых файлов, о которых можно узнать
из справки git help gitignore.

Серверные команды репозитория

Команда создания вспомогательных файлов для dumb-сервера в $GIT_DIR/info и
$GIT_OBJECT_DIRECTORY/info каталогах, чтобы помочь клиентам узнать, какие ссылки
и пакеты есть на сервере:

Проверяет сколько объектов будет потеряно и объём освобождаемого места при
перепаковке репозитория:

Переупаковывает локальный репозиторий:

Как работает клонирование в Git?

Многие люди хотят создать общий репозиторий, чтобы позволить команде разработчиков публиковать свой код на GitHub / GitLab / BitBucket и т. д. Репозиторий, загружаемый в сеть для совместной работы, называется вышестоящим репозиторием или центральным репозиторием.

Центральный репозиторий указывает, что все изменения от всех участников помещаются только в этот репозиторий. Таким образом, это самый обновленный экземпляр репозитория самого себя. Иногда это часто называют исходным хранилищем. Изображение, приведенное ниже, довольно ясно говорит о концепции клонирования.

Что касается приведенного выше изображения, то процесс клонирования работает на следующих этапах:

Клонирование репозитория: пользователь начинает работу с вышестоящего репозитория на GitHub. Процесс начинается с клонирования репозитория на локальную машину. Теперь у пользователя есть точная копия файлов проекта в их системе, чтобы внести изменения.

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

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

Добавление файлов в git репозиторий

Добавление файлов в репозиторий – это достаточно простая операция, мало чем отличающаяся от отправки изменений в отслеживаемых файлах в репозиторий. Мы уже не раз выполняли эту операцию в предыдущих уроках, но сделаем это ещё раз. Создадим новый репозиторий, для этого перейдите в каталог, в котором вы хотите его расположить и введите команду git init.

> git init

Создайте в каталоге файл README.md любым удобным для вас способом, мы сделаем это с помощью команды touch.

> touch README.md

Теперь проверим состояние отслеживаемой директории.

> git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        README.md

nothing added to commit but untracked files present (use "git add" to track)

Как вы можете видеть: в рабочей директории есть один неотслеживаемый файл README.md. Git нам подсказывает, что нужно сделать для того, чтобы начать отслеживать изменения в файле README.md: необходимо выполнить команду git add, сделаем это.

> git add README.md

Посмотрим ещё раз на состояние.

> git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   README.md

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

> git commit -m "add README.md file"
 add README.md file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

Теперь в рабочей директории и в stage нет объектов, информацию об изменении которых необходимо внести в репозиторий.

> git status
On branch master
nothing to commit, working tree clean

В репозиторий был сделан один коммит.

> git log --oneline
0bb6c94 add README.md file

2 ответа

Лучший ответ

Но «иметь филиал» не так уж много

Git использует имена веток для запоминания конкретных коммитов. Каждое имя запоминает одну и только одну фиксацию. Каждая фиксация уникально идентифицируется своим идентификатором хэша: большим уродливым числом вроде .

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

Это также означает, что мы можем использовать другое, не совсем похожее на ветку, имя, чтобы запомнить некоторые другие ветки Git!

Войдите в ветку удаленного отслеживания

Создание клона включает внутренний запуск . Это копирует коммиты из другого Git, а также копирует их имена . Их имена на самом деле являются названиями ветвей: они запоминают свои кончики веток, например и . Но это не ваша подсказка ветки — пока нет! Ваш Git переименовывает их в и . Имена удаленного отслеживания вашего Git с префиксом запоминают их имена и их подсказки.

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

Темная магия

Когда вы запускаете , Git начинает с поиска в вашем списке имен веток для . Если он существует, Git пытается проверить конкретную фиксацию, являющуюся концом вашей ветки , и сделать ее вашей текущей веткой. Пока все хорошо, но что, если имя не еще существует?

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

Итак, теперь у вас есть , и теперь Git может это проверить!

Фактически, это был самый последний шаг : именно так вы в первую очередь получили свой . После копирования коммитов из и изменения их имен на ваш Git запустил . Ваш еще не существовал, поэтому ваш Git создал его из вашего , который ваш Git создал из своего . (Уфф! Кажется, долгий путь, и это так, но в конечном итоге все это имеет смысл!)

torek
13 Авг 2018 в 07:39

Короткий ответ

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

Попробуйте , чтобы увидеть все.

Дополнительные сведения см. в очень полном ответе Торека, чтобы раскрыть скрытые детали.

RomainValeri
13 Авг 2018 в 07:43

Как переименовать ветку

Иногда оказывается, что первоначально созданное имя ветки не самое лучшее. Его можно изменить.

Локальную

Если еще не выполнена команда push, то достаточно переименовать локальную ветку.

Чтобы переименовать локальную ветку, выполним команду:

$ git branch -m <old-name> <new-name>

Например, переименуем ветку testing в ветку test:

$ git branch –m testing test

Чтобы переименовать текущую ветку, выполним команду:

$ git branch -m <new-name>

Например, текущая ветка у нас subbranch_of_testing. Переименуем ее в subbranch:

$ git branch –m subbranch

Удаленную

Переименовать удаленную ветку (ветку в удаленном репозитории) нельзя. Можно удалить ее и отправить в репозиторий локальную ветку с новым именем:

$ git push origin :old-name new-name

здесь origin — имя удаленного репозитория (обычно удаленный репозиторий так называется),old-name — имя ветки локальной ветки,new-name — новое имя ветки в удаленном репозитории.

Например, надо переименовать ветку testing в test:

$ git push origin :testing test