Git что такое origin

32. Что такое origin?

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

Выполните

git remote show origin 

Результат

$ git remote show origin * remote origin Fetch URL: /home/alex/githowto/repositories/work Push URL: /home/alex/githowto/repositories/work HEAD branch: main Remote branches: main tracked style tracked Local branch configured for 'git pull': main merges with remote main Local ref configured for 'git push': main pushes to main (up to date) 

Мы видим, что имя по умолчанию ( origin ) удаленного репозитория — изначальное work . Удаленные репозитории обычно размещаются на отдельной машине, возможно, централизованном сервере. Однако, как мы видим здесь, они могут с тем же успехом указывать на репозиторий на той же машине. Нет ничего особенного в имени origin , однако существует традиция использовать origin в качестве имени первичного централизованного репозитория (если таковой имеется).

3.5 Ветвление в Git — Удалённые ветки

Удалённые ссылки — это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее. Полный список удалённых ссылок можно получить с помощью команды git ls-remote или команды git remote show для получения удалённых веток и дополнительной информации. Тем не менее, более распространённым способом является использование веток слежения.

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

Имена веток слежения имеют вид / . Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, используйте ветку origin/master . Если вы с коллегой работали над одной задачей и он отправил на сервер ветку iss53 , при том что у вас может быть своя локальная ветка iss53 , удалённая ветка будет представлена веткой слежения с именем origin/iss53 .

Возможно, всё это сбивает с толку, поэтому давайте рассмотрим на примере. Скажем, у вас в сети есть свой Git-сервер с адресом git.ourcompany.com . Если вы с него что-то клонируете, команда clone автоматически назовёт его origin , заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка master , и назовёт его локально origin/master . Git также создаст вам локальную ветку master , которая будет начинаться там же, где и ветка master в origin , так что вам будет с чего начать.

Примечание
«origin» — это не специальное название

Подобно названию ветки «master», «origin» не имеет какого-либо специального значения в Git. В то время как «master» — это название по умолчанию для ветки при выполнении git init только потому, что часто используется, «origin» — это название по умолчанию для удалённого сервера, когда вы запускаете git clone . Если вы выполните git clone -o booyah , то по умолчанию ветка слежения будет иметь вид booyah/master .

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

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

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

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

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

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

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

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

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

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

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

Если у вас есть ветка serverfix , над которой вы хотите работать с кем-то ещё, вы можете отправить её точно так же, как вы отправляли вашу первую ветку. Выполните команду git push :

$ git push origin serverfix Counting objects: 24, done. Delta compression using up to 8 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done. Total 24 (delta 2), reused 0 (delta 0) To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfix

Это в некотором роде сокращение. Git автоматически разворачивает имя ветки serverfix до refs/heads/serverfix:refs/heads/serverfix , что означает «возьми мою локальную ветку serverfix и обнови ей удалённую ветку serverfix ». Мы подробно рассмотрим часть с refs/heads/ в главе Git изнутри, но обычно её можно пропустить. Вы также можете выполнить git push origin serverfix:serverfix — произойдёт то же самое — здесь говорится «возьми мою ветку serverfix и сделай её удалённой веткой serverfix ». Можно использовать этот формат для отправки локальной ветки в удалённую ветку с другим именем. Если вы не хотите, чтобы на удалённом сервере ветка называлась serverfix , то вместо предыдущей команды выполните git push origin serverfix:awesomebranch , которая отправит локальную ветку serverfix в ветку awesomebranch удалённого репозитория.

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

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

Если вы не хотите вводить свои данные каждый раз при отправке изменений, вы можете настроить «credential cache». Проще всего держать их в памяти несколько минут, это легко настроить с помощью команды git config —global credential.helper cache .

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

В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает serverfix на сервере, как удалённую ветку origin/serverfix :

$ git fetch origin remote: Counting objects: 7, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix

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

Чтобы слить эти наработки в свою текущую рабочую ветку, выполните git merge origin/serverfix . Если вам нужна локальная ветка serverfix , в которой вы сможете работать, то вы можете создать её на основе ветки слежения:

$ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

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

Отслеживание веток

Получение локальной ветки из удалённой ветки автоматически создаёт то, что называется «веткой слежения» (а ветка, за которой следит локальная называется «upstream branch»). Ветки слежения — это локальные ветки, которые напрямую связаны с удалённой веткой. Если, находясь на ветке слежения, выполнить git pull , то Git уже будет знать с какого сервера получать данные и какую ветку использовать для слияния.

При клонировании репозитория, как правило, автоматически создаётся ветка master , которая следит за origin/master . Однако, при желании вы можете настроить отслеживание и других веток — следить за ветками на других серверах или отключить слежение за веткой master . Вы только что видели простейший пример, что сделать это можно с помощью команды git checkout -b / . Это часто используемая команда, поэтому Git предоставляет сокращённую форму записи в виде флага —track :

$ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

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

$ git checkout serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

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

$ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf'

Теперь ваша локальная ветка sf будет автоматически получать изменения из origin/serverfix .

Если у вас уже есть локальная ветка и вы хотите настроить её на слежение за удалённой веткой, которую вы только что получили, или хотите изменить используемую upstream-ветку, то воспользуйтесь параметрами -u или —set-upstream-to для команды git branch , чтобы явно установить новое значение.

$ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin.

Примечание
Сокращение Upstream

Если у вас настроена отслеживаемая ветка, вы можете ссылаться на неё с помощью сокращений @ или @ . Итак, если вы находитесь на ветке master и она следит за origin/master , при желании вы можете использовать git merge @ вместо git merge origin/master .

Если вы хотите посмотреть как у вас настроены ветки слежения, воспользуйтесь опцией -vv для команды git branch . Это выведет список локальных веток и дополнительную информацию о том, какая из веток отслеживается, отстаёт, опережает или всё сразу относительно отслеживаемой.

$ git branch -vv iss53 7e424c3 [origin/iss53: ahead 2] Add forgotten brackets master 1ae2a45 [origin/master] Deploy index fix * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it testing 5ea463a Try something new

Итак, здесь мы видим, что наша ветка iss53 следит за origin/iss53 и «опережает» её на два изменения — это значит, что у нас есть два локальных коммита, которые не отправлены на сервер. Мы также видим, что наша ветка master отслеживает ветку origin/master и находится в актуальном состоянии. Далее мы можем видеть, что локальная ветка serverfix следит за веткой server-fix-good на сервере teamone , опережает её на три коммита и отстает на один — это значит, что на сервере есть один коммит, который мы ещё не слили, и три локальных коммита, которые ещё не отправлены на сервер. В конце мы видим, что наша ветка testing не отслеживает удалённую ветку.

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

$ git fetch --all; git branch -vv

Получение изменений

Команда git fetch получает с сервера все изменения, которых у вас ещё нет, но не будет изменять состояние вашей рабочей копии. Эта команда просто получает данные и позволяет вам самостоятельно сделать слияние. Тем не менее, существует команда git pull , которая в большинстве случаев является командой git fetch , за которой непосредственно следует команда git merge . Если у вас настроена ветка слежения как показано в предыдущем разделе, или она явно установлена, или она была создана автоматически командами clone или checkout , git pull определит сервер и ветку, за которыми следит ваша текущая ветка, получит данные с этого сервера и затем попытается слить удалённую ветку.

Обычно, лучше явно использовать команды fetch и merge , поскольку магия git pull может часто сбивать с толку.

Удаление веток на удалённом сервере

Скажем, вы и ваши соавторы закончили с нововведением и слили его в ветку master на удалённом сервере (или в какую-то другую ветку, где хранится стабильный код). Вы можете удалить ветку на удалённом сервере используя параметр —delete для команды git push . Для удаления ветки serverfix на сервере, выполните следующую команду:

$ git push origin --delete serverfix To https://github.com/schacon/simplegit - [deleted] serverfix

Всё, что делает эта строка — удаляет указатель на сервере. Как правило, Git сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.

10.5 Git изнутри — Спецификации ссылок

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

$ git remote add origin https://github.com/schacon/simplegit-progit

Эта команда добавляет секцию в файл .git/config , в которой заданы имя удалённого репозитория ( origin ), его URL и спецификация ссылок для извлечения данных:

[remote "origin"] url = https://github.com/schacon/simplegit-progit fetch = +refs/heads/*:refs/remotes/origin/*

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

По умолчанию, после выполнения git remote add origin , Git забирает все ссылки из refs/heads/ на сервере, и записывает их в refs/remotes/origin/ локально. Таким образом, если на сервере есть ветка master , историю данной ветки можно получить, выполнив любую из следующих команд:

$ git log origin/master $ git log remotes/origin/master $ git log refs/remotes/origin/master

Все эти команды эквивалентны, так как Git развернёт каждую запись до refs/remotes/origin/master .

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

fetch = +refs/heads/master:refs/remotes/origin/master

Эта настройка будет использоваться по умолчанию при вызове git fetch для данного удалённого репозитория. Если же вам нужно изменить спецификацию всего раз, можно задать конкретное соответствие веток в командной строке. Например, чтобы получить данные из ветки master из удалённого репозитория в локальную origin/mymaster , можно выполнить:

$ git fetch origin master:refs/remotes/origin/mymaster

Можно задать несколько спецификаций за один раз. Получить данные нескольких веток из командной строки можно так:

$ git fetch origin master:refs/remotes/origin/mymaster \ topic:refs/remotes/origin/topic From git@github.com:schacon/simplegit ! [rejected] master -> origin/mymaster (non fast forward) * [new branch] topic -> origin/topic

В данном случае слияние ветки master выполнить не удалось, поскольку слияние не было простым смещением вперёд. Такое поведение можно изменить, добавив перед спецификацией знак + .

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

[remote "origin"] url = https://github.com/schacon/simplegit-progit fetch = +refs/heads/master:refs/remotes/origin/master fetch = +refs/heads/experiment:refs/remotes/origin/experiment

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

fetch = +refs/heads/qa*:refs/remotes/origin/qa*

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

[remote "origin"] url = https://github.com/schacon/simplegit-progit fetch = +refs/heads/master:refs/remotes/origin/master fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*

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

Спецификации ссылок для отправки данных на сервер

Здорово, что можно получать данные по ссылкам в отдельных пространствах имён, но нам же ещё надо сделать так, чтобы команда QA сначала смогла отправить свои ветки в пространство имён qa/ . Мы решим эту задачу, используя спецификации ссылок для команды push .

Если команда QA хочет отправлять изменения из локальной ветки master в qa/master на удалённом сервере, они могут использовать такой приём:

$ git push origin master:refs/heads/qa/master

Если же они хотят, чтобы Git автоматически делал так при вызове git push origin , можно добавить в конфигурационный файл значение для push :

[remote "origin"] url = https://github.com/schacon/simplegit-progit fetch = +refs/heads/*:refs/remotes/origin/* push = refs/heads/master:refs/heads/qa/master

Аналогично, это приведёт к тому, что при вызове git push origin локальная ветка master будет по умолчанию отправляться в удалённую ветку qa/master .

Примечание

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

Удаление ссылок

Кроме того, спецификации ссылок можно использовать для удаления ссылок на удалённом сервере:

$ git push origin :topic

Так как спецификация ссылки задаётся в виде : , то, пропуская , мы указываем Git, что указанную ветку на удалённом сервере надо сделать пустой, что приводит к её удалению.

Начиная с версии Git v1.7.0, можно использовать следующий синтаксис:

$ git push origin --delete topic

What is the origin in Git?

In Git, «origin» is a shorthand name for the remote repository that a project was originally cloned from. More precisely, it is used instead of that original repository’s URL — and thereby makes referencing much easier.

Note that origin is by no means a «magical» name, but just a standard convention. Although it makes sense to leave this convention untouched, you could perfectly rename it without losing any functionality.

In the following example, the URL parameter to the «clone» command becomes the «origin» for the cloned local repository:

git clone https://github.com/gittower/git-crash-course.git

The Git Cheat Sheet

No need to remember all those commands and parameters: get our popular «Git Cheat Sheet» — for free!

To make working with Git easier, you should try Tower — the popular Git client for Mac and Windows 30 days for free!

Learn More

• Check out the Remote Repositories chapter in our free online book
• More frequently asked questions about Git & version control

Get our popular Git Cheat Sheet for free!

You’ll find the most important commands on the front and helpful best practice tips on the back. Over 100,000 developers have downloaded it to make Git a little bit easier.

About Us

As the makers of Tower, the best Git client for Mac and Windows, we help over 100,000 users in companies like Apple, Google, Amazon, Twitter, and Ebay get the most out of Git.

Just like with Tower, our mission with this platform is to help people become better professionals.

That’s why we provide our guides, videos, and cheat sheets (about version control with Git and lots of other topics) for free.

© 2010-2024 Tower — Mentioned product names and logos are property of their respective owners.