Удалённые ветки
Удалённые ссылки — это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее. Полный список удалённых ссылок можно получить с помощью команды git ls-remote или команды git remote show для получения удалённых веток и дополнительной информации. Тем не менее, более распространенным способом является использование веток слежения.
Ветки слежения — это ссылки на определённое состояние удалённых веток. Это локальные ветки, которые нельзя перемещать; Git перемещает их автоматически при любой коммуникации с удаленным репозиторием, чтобы гарантировать точное соответствие с ним. Представляйте их как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.
Для синхронизации ваших изменений с удаленным сервером выполните команду git fetch (в нашем случае git fetch origin ). Эта команда определяет какому серверу соответствует «origin» (в нашем случае это git.ourcompany.com ), извлекает оттуда данные, которых у вас ещё нет, и обновляет локальную базу данных, сдвигая указатель origin/master на новую позицию.
Отправка изменений
Когда вы хотите поделиться веткой, вам необходимо отправить её на удалённый сервер, где у вас есть права на запись. Ваши локальные ветки автоматически не синхронизируются с удалёнными при отправке — вам нужно явно указать те ветки, которые вы хотите отправить. Таким образом, вы можете использовать свои личные ветки для работы, которую не хотите показывать, а отправлять только те тематические ветки, над которыми вы хотите работать с кем-то совместно.
Если вы используете HTTPS URL для отправки изменений, Git-сервер будет спрашивать имя пользователя и пароль для аутентификации. По умолчанию вам будет предложено ввести эти данные в терминале, чтобы сервер мог определить разрешена ли вам отправка изменений.
Для получения более подробной информации о различных вариантах кэша учётных данных обратитесь к разделу Хранилище учётных данных.
В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает serverfix на сервере, как удалённую ветку origin/serverfix :
Отслеживание веток
В действительности, это настолько распространённая команда, что существует сокращение для этого сокращения. Если вы пытаетесь извлечь ветку, которая не существует, но существует только одна удалённая ветка с точно таким же именем, то Git автоматически создаст ветку слежения:
Чтобы создать локальную ветку с именем, отличным от имени удалённой ветки, просто укажите другое имя:
Важно отметить, что эти цифры описывают состояние на момент последнего получения данных с каждого из серверов. Эта команда не обращается к серверам, а лишь говорит вам о том, какая информация с этих серверов сохранена в локальном кэше. Если вы хотите иметь актуальную информацию об этих числах, вам необходимо получить данные со всех ваших удалённых серверов перед запуском команды. Сделать это можно вот так:
Получение изменений
Удаление веток на удалённом сервере
Всё, что делает эта строка — удаляет указатель на сервере. Как правило, Git сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.
Git Forks and Upstreams: How-to and a cool tip
Nicola Paolucci
Forking projects to make your own changes lets you easily integrate your own contributions. But if you’re not sending those changes back upstream—which means sending it back to the parent repository—you’re at risk for losing track of them, which can cause divergent lines in your repository. To make sure all contributors are drawing from the same place, you’ll need to know some principles of how git forking interacts with git upstream. In this blog, I’ll introduce you to the basics, the gotchas, and even leave you with a cool tip to get you ahead of the curve.
Git upstream: Keep up-to-date and contribute
Let me start by detailing a common setup and the most basic workflow to interact with upstream repositories.
In a standard setup, you generally have an origin and an upstream remote — the latter being the gatekeeper of the project or the source of truth to which you wish to contribute.
First, verify that you have already setup a remote for the upstream repository, and hopefully an origin too:
If you don’t have an upstream you can easily add it with the remote command:
Verify that the remote is added correctly:
Generally, you want to keep your local main branch as a close mirror of the upstream main and execute any work in feature branches, as they might later become pull requests.
You can also use rebase instead, then merge to make sure the upstream has a clean set of commits (ideally one) to evaluate:
Publish with git fork
After the above steps, publish your work in your remote fork with a simple push :
A slight problem arises if you have to update your remote branch feature-x after you’ve published it, because of some feedback from the upstream maintainers. You have a few options:
Personally I prefer to keep the history as clean as possible and go for option three, but different teams have different workflows. Note: You should do this only when working with your own fork. Rewriting history of shared repositories and branches is something you should NEVER do.
Tip of the day: Ahead/Behind numbers in the prompt
Here is how it will look on your prompt once you’ve configured it:
Inner workings
For those who like details and explanations here is how it works:
We get the symbolic name for the current HEAD, i.e. the current branch:
We get the remote that the current branch is pointing to:
We get the branch onto which this remote should be merged (with a cheap Unix trick to discard everything up to and including the last forward slash [ / ]):
Now we have what we need to collect the number of counts for the commits we are ahead or behind:
Getting started with git upstream
That is a basic walk-through on git upstream — how to set up a git upstream, create a new branch, collect changes, publish with git fork, and a sweet tip for how many commits ahead/behind you are of your remote branch.
Bitbucket Server includes fork synchronization which basically relieves the developer from all the burden of keeping up to date with its forks, and Bitbucket Cloud has an easy 1-step sync check it out!
Follow me @durdn and the awesome @Bitbucket team for more DVCS rocking.
Определение «downstream» и «upstream»
Я начал играть с Git и столкнулся с терминами «upstream» и «downstream». Я видел это раньше, но никогда не понимал их полностью. Что означают эти термины в контексте SCM (инструменты управления конфигурацией программного обеспечения) и исходного кода?
ОТВЕТЫ
Ответ 1
С точки зрения контроля источника, вы » вниз по течению» при копировании (клонирование, проверка и т.д.) из репозитория. Информация передавалась вам «вниз по течению».
Когда вы вносите изменения, вы обычно хотите отправить их » вверх по течению«, чтобы они попали в этот репозиторий, чтобы все, вытаскивая из одного источника, работали со всеми теми же изменениями. Это в основном социальная проблема того, как каждый может координировать свою работу, а не технические требования контроля источника. Вы хотите внести свои изменения в основной проект, чтобы не отслеживать расходящиеся линии разработки.
Иногда вы будете читать о менеджерах пакетов или выпусков (люди, а не инструмент), говорящие о внесении изменений в «вверх по течению». Обычно это означает, что они должны были корректировать исходные источники, чтобы они могли создать пакет для своей системы. Они не хотят продолжать делать эти изменения, поэтому, если они отправят «вверх по течению» в исходный источник, им не придется иметь дело с той же проблемой в следующей версии.
Ответ 2
Когда вы читаете на странице git tag :
Одним из важных аспектов git является то, что он распространяется, и его распространение в значительной степени означает, что в системе нет присущих «вверх по течению» или «вниз по течению».
Это просто означает, что не существует абсолютного обратного или обратного репо.
Эти понятия всегда являются относительными между двумя репозиториями и зависят от способа передачи данных:
Если «yourRepo» объявил «otherRepo» удаленным, то:
Обратите внимание на «от» и «для»: вы не просто «ниже по течению», вы «ниже по течению от/для», отсюда и относительный аспект.
Суть DVCS (распределенной системы управления версиями) такова: вы не представляете, что на самом деле представляет собой нисходящий поток, кроме вашего собственного репо относительно объявленных вами удаленных репо.
С точки зрения «потока данных», ваше репо находится в нижней части («нисходящего») потока, идущего из репозиториев в восходящем направлении («извлекать из») и возвращающегося к (тому же или другому) репозиториям в восходящем направлении («толчок в»)).
Вы можете увидеть иллюстрацию на git-rebase странице git-rebase с параграфом «ВОССТАНОВЛЕНИЕ ОТ UPSBREAM REBASE»:
Это означает, что вы вытаскиваете репо «вверх по течению», в котором произошла перебазировка, и вы (репо «вниз по течению») застряли со следствием (множество дублирующих коммитов, потому что ветвь, перебазированная вверх по течению, воссоздала коммиты той же ветки есть локально).
Это плохо, потому что для одного «восходящего» репо может быть много нисходящих репо (т.е. Репо, извлекающих из вышестоящего репо с перебазированной ветвью), причем все они потенциально могут иметь дело с дублирующими коммитами.
Опять же, по аналогии с «потоком данных», в DVCS одна плохая команда «вверх по течению» может иметь «волновой эффект» вниз по течению.
Примечание: это не ограничивается данными.
Это также относится к параметрам, так как команды git (например, «фарфоровые») часто вызывают внутри себя другие команды git («соединительные»). Смотрите страницу rev-parse :
Ответ 3
Восходящий поток (связанный с) Отслеживание
Термин вверх по течению также имеет недвусмысленное значение, поскольку он входит в набор инструментов GIT, особенно относительно отслеживания
будет печатать (последнее кэшированное значение) количество коммитов за (слева) и вперед (справа) от вашей текущей рабочей ветки по сравнению с (если есть) в настоящее время отслеживающей удаленной ветвью для это локальное отделение. В противном случае оно выведет сообщение об ошибке:
это «ветвь» (если есть) на «указанном удалении», которая отслеживает «текущую ветку» в вашем «локальном репозитории».
Это ветка, которую вы извлекаете/извлекаете, когда вы выдает простой git fetch / git pull без аргументов.
Предположим, хотите, чтобы источник/ветвь удаленной ветки был ветвью отслеживания для локальной ветки мастера, которую вы проверили. Просто выпустите:
теперь попробуйте (при условии, что «восходящий» пульт имеет ветвь «dev» )
.git/config теперь читает:
Upstream и Push (Gotcha)
Это предотвращает случайное нажатие на ветки, которые вы еще не готовы нажимать.
Ответ 4
Это немного неофициальная терминология.
Что касается Git, каждый другой репозиторий является просто удаленным.
Термины не ограничены репозиториями Git.
Например, Ubuntu является производным Debian, поэтому Debian находится вверх по течению для Ubuntu.
Ответ 5
Входящий вред, вызванный вводом в эксплуатацию
Например, он говорит о слиянии, что приводит к быстрой перемотке, что это происходит, потому что
фиксация, на которую указывает ваша ветка, была напрямую вверх по течению от youre на
В самом деле, сам Чакон, по-видимому, использует «нисходящий поток» позже, чтобы иметь в виду то же самое, когда он говорит о переписывании всех дочерних коммитов удаленной фиксации:
Вы должны переписать все коммиты ниже по течению от 6df76, чтобы полностью удалить этот файл из истории Git
What Is Git Upstream And How To Set Upstream Branch
Home » SysAdmin » What Is Git Upstream And How To Set Upstream Branch
When you clone a Git repository or create new features through branches, you need know how upstream branches work and how to set them up.
This article gives an overview of how to set up a Git upstream branch, how to change it and how to have an overview of which Git branch is tracking which upstream branch.
Note: To install Git, check out our tutorials:
What is a Git Upstream Branch?
Using a river analogy to illustrate the flow of data, upstream is sending your data back to where the river stream is coming from. When you send something upstream, you are sending it back to the original authors of the repository.
How to Set Upstream Branch in Git
There are two ways to set an upstream branch in Git:
Method 1: Set Upstream Branch Using Git Push
Using git push to set an upstream branch is the most straightforward way to set upstream branches in Git.
Note: Forgot how to clone a repository? Freshen up your memory with our Git Commands Cheat Sheet.
1. Create a new branch and give it a name. We named ours test. Switch to it using the checkout command with the -b option:
A switch branch confirmation appears:
Note: From this point on, the active branch is listed as (
) instead of (main). In our case, it’s (test).
You get confirmation that your branch has been set up to track a remote branch:
The test branch now has a set upstream branch.
Method 2: Set Upstream Branch Using Alias
Instead of going through these commands every time you create a new branch, set up a short alias command. You can modify your existing Git commands or create a bash command.
1. Configure the global alias command through git config with the —global command:
Or create a bash alias command using alias :
Note: Pushing to HEAD will push to a remote branch with the same name as your current branch.
2. Run your global alias by typing:
Or your bash alias by typing its name:
How to Change Upstream Branch in Git
Track a different upstream branch than the one you just set up by running:
The terminal prints out a confirmation message:
How to Check Which Git Branches Are Tracking Which Upstream Branch
List all your branches and branch tracking by running git branch with the -vv option:
The main branch has a tracking branch of [origin/main]. The test branch has a tracking branch of [origin/global]. The global branch has no tracking branches, and therefore no upstream branch.
Note: The current active branch is denoted by the asterisk (*) sign.
You should now know what upstream branches are, how they work, and most importantly, how to set an upstream branch in Git.
Feel free to experiment and get comfortable with upstream. You can easily delete a git branch remotely and locally and remove a git remote from a repository.
Я создал локальную ветку для тестирования Solaris и Sun Studio. Затем я подтолкнул ветку вверх по течению. После внесения изменений и попытки их изменения:
Почему я должен сделать что-то особенное для этого?
Есть ли разумный вариант использования, когда кто-то может создать
, нажмите
для удаленного доступа, а затем запросить фиксацию для
не должно быть для
Вот вид на другую машину. Ветвь явно существует, поэтому она была создана и перемещена:
2 ответа
Ответ на заданный вами вопрос, который я немного перефразирую как «должен ли я установить восходящий поток», заключается в следующем: нет, у вас нет для установки восходящего потока на все.
Что такое восходящий поток?
У каждой ветви есть возможность установить один (1) восходящий поток. То есть каждая ветвь либо имеет восходящий поток, либо не имеет восходящего. Ни одна ветвь не может иметь более одного восходящего потока.
Что хорошего в вышестоящем?
(Все это предполагает, что ваша версия Git не ниже 2.0.)
Восходящий поток влияет на git push
Восходящий поток влияет на origin и git merge тоже
Если вы запустите git rebase или git merge без дополнительных аргументов Git использует текущую ветку upstream. Таким образом, это сокращает использование этих двухкоманды.
Восходящий поток влияет на git rebase
(Обычно вы должны просто выполнить эти два шага вручную, по крайней мере, пока вы не будете достаточно хорошо знать Git, чтобы в случае сбоя любого шага, что в конечном итоге произойдет, вы узнаете, что пошло не так, и узнаете, что с этим делать.)
Восходящий поток влияет на git rebase
Это на самом деле может быть самым важным. Если у вас есть восходящий набор, git status может сообщить о разнице между вашей текущей веткой и ее восходящей, с точки зрения коммитов.
Это потому, что origin/B работает:
Настройка восходящего потока дает вам все эти вещи.
Почему origin/B уже имеет вышестоящий набор?
Когда вы впервые клонируете с какого-либо пульта, используйте:
Если вы создаете новую ветку:
Когда вы впервые нажимаете на новую ветку:
Разве Git не должен просто установить это, как восходящий поток автоматически?
1 Чтобы быть справедливым, тогда еще не было ясно, что первоначальная реализация была подвержена ошибкам. Это стало ясно только тогда, когда каждый новый пользователь каждый раз совершал одни и те же ошибки. Теперь оно «менее бедное», что нельзя сказать «здорово».
2 «Никогда» немного сильное, но я обнаружил, что новички в Git понимают вещи намного лучше, когда я разделяю шаги, особенно когда я могу показать им, что git merge на самом деле, и они могут увидеть, что git rebase или git push будет дальше.
4 Измеряется методом Остина Пауэрса /Доктора Зла, во всяком случае, просто говоря «один МИЛЛЛЛ-ЮН».
