Git push set upstream что это

Каково назначение ключа `-u` при git push?

Ответы в английской версии StackOverflow на аналогичный вопрос — stackoverflow.com/questions/5697750/… — Вам понятны? Спасибо.

1 мар 2016 в 9:49

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

С ключом -u (полный вариант —set-upstream ) вы создаёте (если ещё не существует) в удалённом репозитории ветку, соответствующую вашей локальной и связываете их:

• В remote/branchname будет производиться push в локальную ветку branchname
• Из remote/branchname будет производиться pull в локальную ветку branchname

Для master это актуально, только если вы пушите в пустой репозиторий. Если клонировали — то соответствие ветвей уже настроено. А вот как только вы создадите новую локальную ветвь и захотите её запушить на remote, вам понадобится ключ -u .

# есть у нас локальная ветка git checkout -b mybranch # Создаем ветку на remote git push -u origin mybranch # Можно выбрать другое имя для создаваемой ветки на remote. git push -u origin mybranch_with_other_name 

Вопрос №52170 от пользователя Margarita в уроке «Анализ сделанных изменений», курс «Введение в Git»

Почему изменения не отобрабражаются в GitHub после обновления?

Margarita, Добрый день! Для команды git push нужно указывать ветку и удаленный репозиторий, куда вы хотите отправить изменения. Например, так: git push origin main . Выполнив эту команду один раз с флагом —set-upstream или сокращенно -u , например так git push —set-upstream origin main , вы сделаете удаленную ветку main репозитория origin отслеживаемой. И в дальнейшем вы сможете не указывать репозиторий и ветку, отправляя изменения просто командой git push и они автоматически будут попадать в отслеживаемую ветку

Что такое 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

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

git tag -d

Продвинутые возможности

Удаление локальных данных (prune)

Если на сервере была удалена ветка, то локально она все еще существует. Чтобы удалить все локальные ветки, которых нет на сервере:

git remote prune origin

Проверить, удастся ли пушинг (dry run option)

С этой опцией пушинг фактически не произойдет, но покажет вывод словно он произошел.

git push --dry-run

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

Атомарный пушинг (atomic option)

Если отправить несколько веток на сервер, некоторые могут быть приняты, а другие — нет. Иногда это не то поведение, которое ожидалось. Например, пушинг делает некоторая проверяющая система и ожидаемое поведение такое: либо все будут приняты, либо все будут отклонены. В таких случаях надо делать пушинг атомарно:

git push --atomic origin branch1 branch2 …

Заключение

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

git push –help

Git rebase — перебазирование коммитов и веток

Что такое GitLab, как и для чего он используется

Зарегистрируйтесь в панели управления

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

Читайте также:

Инструкция

Как автоматизировать подготовку к собеседованиям с помощью Telegram-бота

29 сентября 2023

Инструкция

Как реализовать очередь в Redis

14 сентября 2023

Инструкция

Как генерировать истории с помощью ChatGPT и Telegram

Форки и вышестоящие репозитории в Git: инструкции и интересный совет

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

Вышестоящий репозиторий Git: следите за обновлениями и вносите свой вклад

Сначала ознакомимся с общей конфигурацией и основным рабочим процессом взаимодействия с вышестоящими репозиториями.

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

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

git remote -v

origin git@bitbucket.org:my-user/some-project.git (fetch)
origin git@bitbucket.org:my-user/some-project.git (push)

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

git remote add upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git

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

Перемещение полного репозитория Git

СМ. РЕШЕНИЕ

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

Убедитесь, что удаленное подключение добавлено правильно:

git remote -v

origin git@bitbucket.org:my-user/some-project.git (fetch)
origin git@bitbucket.org:my-user/some-project.git (push)
upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git (fetch)
upstream git@bitbucket.org:some-gatekeeper-maintainer/some-project.git (push)

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

(Если в проекте есть теги, которые не объединены с главной веткой, нужно также выполнить команду git fetch upstream —tags.)

git fetch upstream

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

На этом этапе вы можете свободно выбирать между командами merge и rebase , поскольку в большинстве случаев они дадут одинаковый результат. Воспользуемся командой merge :

git checkout main
git merge upstream/main

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

Кроме того, вы можете провести перебазирование с помощью команды rebase , а затем выполнить слияние командой merge , чтобы оставить в вышестоящем репозитории чистый набор коммитов (а лучше всего один) для оценки:

git checkout -b feature-x

#some work and some commits happen
#some time passes

git fetch upstream
git rebase upstream/main

Публикация в форке репозитория Git

Выполнив описанные выше действия, опубликуйте работу в своем удаленном форке простой командой push :

git push origin feature-x

git push -f origin feature-x

Я предпочитаю сохранять историю максимально чистой и поэтому выбираю третий вариант, однако у разных команд разные рабочие процессы. Примечание: совершайте эти операции только при работе с собственным форком. НИ В КОЕМ СЛУЧАЕ не перезаписывайте историю общих репозиториев и веток.

Полезный совет: значения опережения/отставания в подсказке

Выполнив команду git status после fetch , вы сможете просмотреть, на сколько коммитов ваша ветка опережает синхронизированную удаленную ветку или отстает от нее. Было бы здорово видеть эту информацию в своей верной командной подсказке, не правда ли? Я тоже так подумал, поэтому настроил в Bash соответствующие параметры.

Вот как будет выглядеть подсказка после настройки:

nick-macbook-air:~/dev/projects/stash[1|94]$

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

function ahead_behind curr_branch=$(git rev-parse --abbrev-ref HEAD); 
curr_remote=$(git config branch.$curr_branch.remote); 
curr_merge_branch=$(git config branch.$curr_branch.merge | cut -d / -f 3); 
git rev-list --left-right --count $curr_branch. $curr_remote/$curr_merge_branch | tr -s '\t' '|';
>

export PS1="\h:\w[\$(ahead_behind)]$"

«Внутренняя кухня»

Изложу принцип работы для тех, кто любит развернутые пояснения.

Получаем символическое имя текущего указателя HEAD, то есть текущей ветки:

curr_branch=$(git rev-parse --abbrev-ref HEAD);

Получаем удаленную ветку, на которую указывает текущая ветка:

curr_remote=$(git config branch.$curr_branch.remote);

Получаем ветку, с которой нужно объединить эту удаленную ветку (в Unix можно легко убрать все символы до последней косой черты [/] включительно):

curr_merge_branch=$(git config branch.$curr_branch.merge | cut -d / -f 3);

Теперь у нас есть все необходимое, чтобы узнать, на сколько коммитов наша ветка опережает удаленную или отстает от нее:

git rev-list --left-right --count $curr_branch. $curr_remote/$curr_merge_branch | tr -s '\t' '|';

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

Начало работы с вышестоящим репозиторием Git

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

Bitbucket Server поддерживает синхронизацию форков, которая освобождает разработчиков от обязанности поддерживать актуальность своих форков. В Bitbucket Cloud используется простая одноэтапная синхронизация. Опробуйте эти возможности самостоятельно!

Подпишитесь на меня (@durdn) и замечательную команду @Bitbucket, чтобы осваивать новые навыки работы с распределенными системами управления версиями.

Nicola Paolucci

Nicola is an all-round hacker who loves exploring and teaching bleeding edge technologies. He writes and talks about Git, development workflows, code collaboration and more recently about Docker. Prior to his current role as Developer Instigator at Atlassian he led software teams, built crowd sourcing applications for geo-spacial data, worked on huge e-commerce deployments. Little known facts about Nicola: he gesticulates a lot while speaking (being Italian), lives in Amsterdam and rides a Ducati.