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

Как запушить ветку на удаленный репозиторий

  • автор:

Как запушить ветки на гитхаб?

delphinpro

Ветки создаются командой: git branch имя
Всё! Никаких коммитов дополнительно создавать не надо. Главное чтобы репозиторий уже содержал хотя-бы один коммит, чтобы веткам было куда указывать (ветка это лишь указатель на коммит).

Push отправляет конечно же не файлы а именно ветки. По умолчанию только одну ветку, которая текущая. Чтобы отправить сразу все, следует его об этом попросить: git push origin —all

Ответ написан более двух лет назад
Комментировать
Нравится 4 Комментировать

# Создать новую локальную ветку git checkout -b branche_name # внести изменения в файлы, затем добавить их и закоммитить git add * git commit -m 'Commit message' # запушить новую локальную ветку в репу git push origin branche_name

Ответ написан более двух лет назад
Нравится 3 6 комментариев
zaychonok_lisa @zaychonok_lisa Автор вопроса
Большое спасибо!
А нельзя как то сразу все ветки указать?
Типо такого?
git push origin

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

Отправка фиксаций в удаленный репозиторий

Используйте git push для отправки фиксаций в локальной ветви в удаленный репозиторий.

В этой статье

About git push

The git push command takes two arguments:

  • A remote name, for example, origin
  • A branch name, for example, main
git push REMOTE-NAME BRANCH-NAME 

As an example, you usually run git push origin main to push your local changes to your online repository.

Renaming branches

To rename a branch, you’d use the same git push command, but you would add one more argument: the name of the new branch. For example:

git push REMOTE-NAME LOCAL-BRANCH-NAME:REMOTE-BRANCH-NAME 

This pushes the LOCAL-BRANCH-NAME to your REMOTE-NAME , but it is renamed to REMOTE-BRANCH-NAME .

Dealing with «non-fast-forward» errors

If your local copy of a repository is out of sync with, or «behind,» the upstream repository you’re pushing to, you’ll get a message saying non-fast-forward updates were rejected . This means that you must retrieve, or «fetch,» the upstream changes, before you are able to push your local changes.

For more information on this error, see «Dealing with non-fast-forward errors.»

Pushing tags

By default, and without additional parameters, git push sends all matching branches that have the same names as remote branches.

To push a single tag, you can issue the same command as pushing a branch:

git push REMOTE-NAME TAG-NAME 

To push all your tags, you can type the command:

git push REMOTE-NAME --tags 

Deleting a remote branch or tag

The syntax to delete a branch is a bit arcane at first glance:

git push REMOTE-NAME :BRANCH-NAME 

Note that there is a space before the colon. The command resembles the same steps you’d take to rename a branch. However, here, you’re telling Git to push nothing into BRANCH-NAME on REMOTE-NAME . Because of this, git push deletes the branch on the remote repository.

Remotes and forks

You might already know that you can «fork» repositories on GitHub.

When you clone a repository you own, you provide it with a remote URL that tells Git where to fetch and push updates. If you want to collaborate with the original repository, you’d add a new remote URL, typically called upstream , to your local Git clone:

git remote add upstream THEIR_REMOTE_URL 

Now, you can fetch updates and branches from their fork:

git fetch upstream # Grab the upstream remote's branches > remote: Counting objects: 75, done. > remote: Compressing objects: 100% (53/53), done. > remote: Total 62 (delta 27), reused 44 (delta 9) > Unpacking objects: 100% (62/62), done. > From https://github.com/OCTOCAT/REPO >  * [new branch] main -> upstream/main 

When you’re done making local changes, you can push your local branch to GitHub and initiate a pull request.

For more information on working with forks, see «Syncing a fork».

Further reading

  • The «Remotes» chapter from the «Pro Git» book
  • git remote main page
  • «Git cheatsheet»
  • «Git workflows»
  • «Git Handbook»
  • «Troubleshooting the 2 GB push limit»

Что такое git push и как его использовать

В инструкции рассказываем о наиболее частых сценариях использования git push.

Эта инструкция — часть курса «Введение в Git».

Смотреть весь курс

Введение

Команда Git push позволяет отправлять локальную ветку на удаленный репозиторий. Она помогает разработчикам синхронизироваться в команде, а именно отправляет проделанные изменения. Если программист работает один, то пуш позволяет хранить код в облаке, например github, gitlab и не только, избавляя от риска потери данных на компьютере.

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

В этой инструкции мы расскажем, как запушить в удаленный git репозиторий. В статье под «пушем» будем подразумевать git push.

Отправка изменений в чистый репозиторий

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

git remote add link

Вместо repository_name нужно дать имя удаленному репозиторию. Далее в инструкции вместо этого параметра мы будем использовать origin, так как чаще всего используют это имя.

Вместо link — ссылка на удаленный репозиторий, она может выглядеть по-разному в зависимости от того используется ssh или https.

Для ssh, который обязателен для github и gitlab, потребуются сделать дополнительные манипуляции для создания ssh-ключа. Соответствующие инструкции есть на этих ресурсах.

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

Перед пушем надо зафиксировать текущие изменения, то есть сделать git commit.

Далее для отправки в терминале пишем:

git push origin

Вместо branch — имя ветки, которую надо отправить. Чаще всего используется master или main:

git push origin master 

Такое каждый раз писать слишком громоздко, для этого придумали git push по умолчанию. Для этого единожды набираем предыдущую команду с флагом -u:

git push -u origin master

После этого можно писать более коротко, так как git запомнил, что пушить надо на сервер origin ветку под именем master:

git push

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

Дополнительные опции публикации

Отправка ветки на сервер в ветку с другим именем

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

git push origin branch:server_branch

где branch – имя локальной ветки, server_branch – имя удаленной ветки на сервере.

Отправка всех веток на сервер

Вместо имени ветки пишем флаг —all:

git push origin --all

После этого все зафиксированные изменения в ветках отправятся в удаленный репозиторий.

Отправка текущей ветки

Удобный способ отправить текущую ветку с тем же именем на сервере.

git push origin HEAD 

HEAD указывает на текущую ветку (current branch). Тем самым, не надо запоминать имя ветки, на которой вы находитесь.

Принудительная публикация (git push —force …)

При отправке может произойти ошибка публикации:

To github.com:example/test.git ! [rejected] master -> master (fetch first) error: не удалось отправить некоторые ссылки в «github.com:example/test.git»

Это так называемый git push rejected, он означает что пуш был отклонен. Правильнее всего — сделать то, что написано в подсказке к ошибке. Надо получить и смержить изменения, затем снова отправить.

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

Флагом —force или сокращенной его версией -f отключается проверка коммитов и при необходимости выполняется перезапись истории.

git push --force

Нужно быть аккуратными с этой командой, так как она стирает работу других людей. Эта команда оправдана лишь изредка, например, если вы почти сразу внесли изменения коммита с помощью git commit —amend и запушили до того, как кто-то сделал git pull.

Принудительная публикация с параметром (git push —force-with-lease …)

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

git push --force-with-lease

Принудительная публикация с этим параметром чревата появлением git push rejected у других людей

Как пушить в PhpStorm

При первом открытии PhpStorm потребуется создать новый проект.

новый проект

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

часто используемые команды

Синяя стрелка означает git pull, зеленая галочка — git commit, зеленая стрелка — git push. При нажатии на зеленую стрелку (горячие клавиши Ctrl+Alt+K или ⌥ ⌘ K) открывается диалоговое окно с информацией об изменениях и настроках отправки.

Незапушенные коммиты

Самый простой способ узнать про них при помощи команды:

git status 

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

On branch master Your branch is ahead of ‘origin/master’ by 1 commit. (use “git push” to publish your local commits)

Для более подробной информации можно использовать:

git log 

Будет выведена история коммитов:

commit 0fcd9558b013f642a8c3b4a59a16a66de39c99bd (HEAD -> master) Author: Pavel Date: Sun Mar 27 18:57:14 2022 +0300 Local commit commit 289c650767d2c7c2e58486e27b8b3933c6442078 (origin/master, origin/HEAD) Author: Pavel Date: Fri Mar 25 19:41:47 2022 +0300 Pushed commit 

В скобках пишется где и какой коммит расположен.

HEAD -> master означает что текущая ветка (current branch) — это master и это последний локальный коммит в ней.

В нижнем коммите в скобках origin/master означает, что это последний опубликованный коммит на сервере в ветке master, а origin/HEAD, что коммит расположен на ветке, которая совпадает с локальной веткой HEAD.

Как пушить теги

Для создания тегов используют git tag, а для их отправки:

git push origin

Вместо tag_name — имя тега, который надо удалить на сервере.

Также можно сделать отправку всех тегов:

git push --tags

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

Удаление ветки или тега на сервере

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

git push --delete origin

remote_branch_or_tag_name — имя ветки или тега на сервере.

Для удаление локальной ветки:

git branch -d

А для удаления локального тега:

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 на новую позицию.

`git fetch` обновляет ветки слежения

Рисунок 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 .

Ветка слежения `teamone/master`

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *