Git - как я могу создать главную ветку на основе ветки gh-pages?

Введение¶

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

Как избежать такого в дальнейшем?

В GitHub и GitLab есть функциональность под названием «защищённые ветки» (protected branches). Отметьте , , или какие ещё ветки важны для вас как защищённые и система не даст вам выстрелить себе в ногу. Если force push всё же понадобится, то защиту всегда можно на время снять. См

документацию: https://help.github.com/articles/defining-the-mergeability-of-pull-requests/

Создайте алиасы для команд, которые должны делать , чтобы обезопасить себя от ошибок по неосторожности:

Прекратите уже экспериментировать прямо в основной ветке! Команда — ваш друг.

Pro Tip: У команды также ещё очень хорошо сочетаются друг с другом ключи и , особенно, если вы отвлеклись от проекта на месяцок-другой. Попробуйте, если, конечно, вам всё ещё мало приключений…

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

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

В 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 каталогах, чтобы помочь клиентам узнать, какие ссылки
и пакеты есть на сервере:

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

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

Метод / шаг

Войдите в github на своей личной домашней странице, нажмите «Репозитории», вы увидите созданные вами проекты или «Форк».
Найдите «Репозитории» (или проект), которые хотите удалить, и нажмите, чтобы войти.
Найдите «Настройки» в правом нижнем углу страницы репозиториев, как показано на рисунке, и нажмите «Настройки» для входа (в это время вам может быть предложено ввести пароль).
После входа в «Настройки» нажмите «Параметры» в левом фрейме (обычно этот вариант используется по умолчанию), а затем перетащите его в нижнюю часть, вы увидите «Удалить этот репозиторий».
Нажмите «Удалить этот репозиторий», появится диалоговое окно, в котором нужно ввести имя «Репозиториев», которые вы хотите удалить. Если вы не заполните его, вы не сможете удалить его. Меня зовут «Тест», после чего можно удалить весь проект.

9. Приватный репозиторий школы

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

Приватный репозиторий школы видите только вы сами, менторы и админы. Другие студенты его увидеть не смогут. Будьте внимательны, когда сабмитите ссылки на свои работы для кросс-чек проверки. Нет смысла отправлять ссылку на приватный репозиторий школы или PR в нём, проверяющие его не увидят. Работу для проверки необходимо залить на и сабмитить ссылку на задеплоенную версию. Перед сабмитом проверьте ссылку на деплой, открывается ли она в режиме инкогнито браузера и смогут ли проверяющие увидеть вашу работу.

6. Создание Pull Request

В ходе выполнения проектов в RS School вы чаще всего будете делать Pull Request из ветки разработки в главную ветку своего репозитория или , а также из ветки разработки в ветку .

Pull Request создаётся через интерфейс GitHub. Для этого

выберите ветку разработки
нажмите на вкладку Pull Request вверху слева
нажмите на кнопку Compare & pull request справа вверху. Такая кнопка появится если в ветке разработки есть изменения по сравнению с другой веткой репозитория, хоть лишняя точка в файле README
укажите из какой ветки репозитория в какую делаете Pull Request
нажмите на зелёную кнопку внизу Create pull request.
Вы открыли Pull Request. В таком виде его и оставьте. В открытом Pull Request ментору будет удобно проверять код.
добавить в описание Pull Request изображение можно просто перетянув его с компьютера
Если нажать на кнопку Merge pull request, Pull Request закроется, при этом файлы из ветки разработки переместятся в ту ветку, в которую делаете Pull Request.

Переименование файлов в репозитории Git

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

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

Как переименовать файл с помощью Git

Поскольку у нас нет никакого файла в репозитории Git, создайте новый файл, например toolsqa.txt. После этого вы должны проверить состояние git. Подтвердите, что это чистый каталог, как мы уже делали выше. Как только все будет сделано, введите следующую команду и нажмите клавишу enter:

git mv <original_file_name> <new_file_name>

Проверьте состояние репозитория через git status.

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

Как переименовать файл вне Git

В этом разделе мы рассмотрим, как Git реагирует, когда файл переименовывается, не сообщая об этом Git. Используйте ту же команду без “git”.

Введите следующую команду в Git Bash и нажмите клавишу enter:

mv <original_file_name> <new_file_name>

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

Здесь очень важно заметить реакцию Git. Git удалил файл под названием renaming.txt и добавил новый файл toolsqa.txt

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

Теперь Git распознал переименование и, следовательно, показывает вам то же самое. Зафиксируйте эти изменения в репозитории Git. Вы заметите что-то, когда будете фиксировать изменения.

Выделенная строка гласит: rename renaming.txt -> toolsqa.txt (100%)

Означает, что предыдущий файл и новый файл абсолютно одинаковы и нет никакой разницы. Это называется уровнем доверия. Если бы вы внесли какие-либо изменения в новый файл, а затем зафиксировали эти изменения, он показал бы менее 100%.

3. Клонирование репозитория на компьютер

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

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

Например, чтобы склонировать себе на компьютер репозиторий с тасками курса https://github.com/rolling-scopes-school/tasks, необходимо открыть Git Bash и выполнить в нём команду

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

Как перенести изменения из локального репозитория в удаленный репозиторий в Git

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

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

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

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

После выполнения команды git status появятся следующие строки:

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

Your branch is up to date with origin/master: Origin — это имя удаленного репозитория, которое мы дали при подключении локального репозитория к удаленному репозиторию.

Последовательность действий

Перечислите все файлы с командой ls в репозитории.

Так как существует только один файл (README.md это всего лишь инструкция), давайте внесем некоторые изменения в его содержание.

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

Добавьте внесенные изменения в промежуточную область и зафиксируйте их.

Примечание: GitHub и Git распознают любые изменения только через коммиты (commits). Если пользователь не зафиксировал изменения и пытается протолкнуть их на GitHub, он отобразит сообщение “Everything is up-to-date”

Введите следующую команду, чтобы перенести эти изменения в репозиторий GitHub, и нажмите клавишу enter.

git push origin master

Пользователь получает приглашение предоставить учетные данные с помощью GitHub в качестве части безопасности. Введите свои учетные данные и нажмите на кнопку входа в систему.

Как только пользователь получит одобрение и изменения объединятся, он получит следующее сообщение в Git Bash.

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

https://github.com/harishrajora805/ToolsQA.git: URL-адрес репозитория, который отражает изменения.

1в4522а..285f559: показывает хэш-значение обеих ветвей. Таким образом, хэш-значение конечного коммита, отраженного на GitHub, равно 285f559.

master -> master: строка master — > master показывает исходную ветвь, из которой происходит слияние с целевой ветвью. В приведенном выше сценарии обе ветви являются главными.

Строка Writing Objects: 100% имеет важное значение. В Git можно сказать, была ли команда push выполнена успешно или нет, только взглянув на эту строку

Если она показывает 100%, то все изменения успешно перенесены в облако.

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

Что происходит при удалении удаленного репозитория?

Удаление репозитория на GitHub похоже на полное удаление файла с вашего ПК. Однако при удалении удаленного репозитория следует учитывать следующее:

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

Учитывая последствия удаления репозитория GitHub, вы можете передумать. Однако GitHub также позволяет вам архивировать репозитории вместо их удаления.

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

7. Деплой на gh-pages

Деплой это размещение в интернете вашего проекта — сайта или приложения.
Предположим, весь наш проект — файл index.html с содержимым

Загрузите его в ветку gh-pages удалённого репозитория (репозиторий должен быть публичным).
Загрузить файл в репозиторий можно как через GitHub, так и через Git (см. п.4 ).

При загрузке файлов через Git последовательно выполняем команды:

При создании в публичном репозитории ветки , GitHub автоматически размещает её содержание в интернете. То есть, если репозиторий публичный, в нём есть ветка gh-pages, и в корне этой ветки находится файл , этот файл уже размещён в интернете. Всё, что осталось сделать, найти ссылку на него.

Идём в настройки репозитория (шестерёнка с надписью справа вверху)

Ссылка на GitHub Pages имеет вид:,
в ней нужно указать — nick name пользователя GitHub — название репозитория

6 ответов

Лучший ответ

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

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

Самое близкое, что я могу сделать к тому, о чем вы просите, — это откат всех, кроме первого коммита. Для этого сначала нужно найти SHA1 первого коммита, например:

… а затем запустите либо

…или

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

Наконец, вы бы сбежали

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

К сожалению, как уже объяснялось, этот подход не удаляет всю историю.

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

Это поместит пустой коммит в корень вашей истории и пометит его тегом с именем ROOT. Тогда вы можете сделать что-то вроде

Или

Чтобы вернуть вас к первой пустой фиксации.

Чтобы лучше понять, что делает , я рекомендую прочитать это .

kjo
11 Май 2013 в 18:28

Касса к мастеру:

Показать журнал:

Сброс до первой фиксации:

Затем отправьте изменения на удаленный:

Alexey Slusar
20 Ноя 2019 в 13:28

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

Где — это sha1 некоторой исторической фиксации.

Однако это редко требуется, если вы учитесь и хотите поэкспериментировать.

Вместо этого вы можете просто создать новую ветку для своих экспериментов, например:

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

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

Если вы хотите уничтожить ветку , просто выполните:

mvp
11 Май 2013 в 20:57

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

(т.е. в значительной степени то, что сказал VonC)

(добавлен для защиты от неверных меток времени)

Community
23 Май 2017 в 10:31

Вы можете вернуться к первой фиксации:

«Как показать первую фиксацию с помощью ‘git log’? «описывает, как найти первую фиксацию:

(работает, только если нет нескольких корневых веток)

Обратите внимание, что после сброса, чтобы действительно получить чистый лист, вы можете просто создать новое репо и скопировать содержимое вашей первой фиксации, которую вы только что сбросили (и добавить и зафиксировать в этом новое репо)

Community
23 Май 2017 в 12:02

Просто удалите каталог после проверки вашего первого коммита. Как таковой:

GoZoner
12 Май 2013 в 00:04

9 ответов

Лучший ответ

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

Evgeny Karkan
24 Июл 2016 в 22:19

сгенерируйте свой ключ

SSH — серийник
Визуализируйте свои ключи

ls ~ / .ssh

id_rsa id_rsa.pub
Запустить агент

eval
Запустить агент

ssh-add ~ / .ssh / id_rsa

Waldeyr Mendes da Silva
22 Май 2018 в 16:06

Мне нужно было указать, какой хост будет использовать какой SSH-ключ. В папке SSH на локальном компьютере, обычно в разделе , создайте / отредактируйте файл с именем , используя предпочтительный редактор, например vim или gedit .

И добавьте следующее с вашими git Host , HostName и ssh IdentityFile (путь к файлу закрытого ключа ssh):

Waqleh
23 Июл 2018 в 17:06

Получил после того, как потратил много времени …

В принятом ответе Shravan40 все было нормально, но я, идиот, добавил на github.com новый репозиторий с добавлением нового README.md, и это вызвало ошибку

После множества попыток я добавил новый репозиторий без нового README.md, и все было в порядке, но я не знаю причины. До вчерашнего дня при новой попытке я наконец заметил это …

Итак, мое решение в дополнение к ответу Shravan40s:

Может это кому то поможет …

-1

Ulli H
29 Июл 2016 в 14:43

За свой короткий опыт использования git с Linux я обнаружил, что есть два простых ответа на эту ошибку.

Запустите эти команды в этом порядке

Это изменит конфигурацию вашего файла конфигурации для использования источника HTTPS вместо SSH.

Теперь попробуйте запустить команды push или pull.

ИЛИ

Перезагрузите виртуальную машину Linux (если вы ее используете) и / или хост-машину. Перезагрузка неоднократно решала проблему.

-1

Blusteel408
6 Мар 2020 в 19:44

У меня была такая же проблема с моим ssh-соединением. Я пробовал работать через ssh, но не нашел рабочего решения. Итак, в этом случае я изменил свой удаленный URL-адрес с SSH на HTTPS. Я использовал команду: . Вы можете увидеть, что ваш удаленный URL-адрес изменился, используя: .

Более подробную информацию можно найти здесь

Это изменит ваш удаленный URL-адрес на HTTPS, поэтому теперь вам нужно будет ввести свое имя пользователя и пароль GitHub, чтобы отправить свой проект в удаленное репо. Я знаю, что ssh проще, чем HTTPS, что означает, что вам не нужно вводить свое имя пользователя и пароль, но это может быть полезно, если вы не нашли решения для его исправления через ssh, и вы спешите, чтобы код в ваше репо.

shreeshr
9 Ноя 2019 в 17:52

Сгенерируйте ключ SSH с помощью .
Скопируйте вывод в буфер обмена
Вставьте скопированный выше вывод в форму по адресу https://github.com/settings/ssh/new

Shravan40
17 Май 2020 в 12:17

убедитесь, что вы правильно назвали файлы «открытый ключ» и «закрытый ключ»; в точности как «id_rsa» и «id_rsa.pub». Это то, что вы можете найти в папке users / .ssh.
добавить публичный ключ в GitHub
Перезагрузите терминал (поддерживается bash) и попробуйте снова клонировать

Если у вас есть доступ для записи в репо, вы должны быть готовы выполнить эти изменения.

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

Удачного кодирования!

Vikas Pandey
21 Сен 2017 в 17:13

Если кто-то из вас сталкивается с такой же проблемой на Bitbucket, то вот решение:

Проблема: —— Демо @ L90TQCLQ MINGW64 / u / works (мастер) $ git clone ssh: //git@bitbucket.internal.abc.com: 5449 / rem / jenkinspipeline.git Клонирование в jenkinspipeline … git@bitbucket.internal.abc.com: В доступе отказано (публичный ключ). фатальный: не удалось прочитать из удаленного репозитория .

Убедитесь, что у вас есть правильные права доступа и репозиторий существует.

Решение: Демо @ L90TQCLQ MINGW64 / u / works (мастер) $ cat

Перейти к: https: //bitbucket.internal. abc.com/plugins/servlet/ssh/projects/REM/repos/jenkinspipeline/keys 1) Добавить ключи Скопируйте / вставьте туда значение ключа id_rsa.pub:

Готово! Теперь вы можете клонировать репозиторий git

KDemo @ L90TQCLQ MINGW64 / u / works (master) $ git clone ssh: //git@bitbucket.internal.abc.com: 5449 / rem / jenkinspipeline.git Клонирование в ‘jenkinspipeline’ … удаленный: Перечисление объектов: 1146, сделанный. удаленный: Подсчет объектов: 100% (1146/1146), готово. remote: Сжатие объектов: 100% (987/987), готово. удаленный: Всего 1146 (дельта 465), повторно используется 0 (дельта 0) Принимающие объекты: 100% (1146/1146), 149,53 КБ | 172.00 КБ / с, готово. Разрешение дельт: 100% (465/465), выполнено.

nk07
12 Дек 2019 в 10:57

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

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

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

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

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

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

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

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

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