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 сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.
In Git, what is the difference between origin/master vs origin master?
I know, origin is a term for the remote repository and master is the branch there. I am purposely omitting the «context» here and I am hoping that the answer should not depend upon the context. So in git command lines, what is the difference between origin/master and origin master. Is there a non-ambiguous way to understand when to use origin/master and when I should use origin master?
Senthil Kumaran
asked Aug 8, 2013 at 22:20
Senthil Kumaran Senthil Kumaran
54.9k 15 15 gold badges 95 95 silver badges 132 132 bronze badges
possible duplicate of Git branching: master vs. origin/master vs. remotes/origin/master
May 20, 2015 at 3:52
It may be a duplicate question, but @Dietrich Epp’s answer below is a clear explanation of the differences that doesn’t make this issue more confusing.
Apr 8, 2021 at 11:38
7 Answers 7
(Note: When this question was originally posted, «master» was the default name for branches in Git. Since «main» is now the default name, this answer has been updated to use «main», in the hope that this will be more natural for people new to Git.)
There are actually three things here: origin main is two separate things, and origin/main is one thing. Three things total.
- main is a local branch
- origin/main is a remote tracking branch (which is a local copy of the branch named «main» on the remote named «origin»)
- origin is a remote
Is origin/main remote?
The origin/main branch is local! Any time you fetch from origin , origin/main will get updated. However, origin/main can be out of date, and it’s even possible that main no longer exists on origin . You can use the —prune option ( -p ) with git fetch to automatically delete remote tracking branches if the branch they track is deleted.
The origin/main branch is not a reference or pointer to the main branch on origin . It is a local copy.
Example: pull in two steps
Since origin/main is a branch, you can merge it. Here’s a pull in two steps:
Step one, fetch main from the remote origin . The main branch on origin will be fetched and the local copy will be named origin/main .
git fetch origin main
Then you merge origin/main into main .
git merge origin/main
Then you can push your new changes in main back to origin :
git push origin main
More examples
You can fetch multiple branches by name.
git fetch origin main stable oldstable
You can merge multiple branches.
git merge origin/main hotfix-2275 hotfix-2276 hotfix-2290
Can you use a different name?
My local branch doesn’t have to be named main if I don’t want to. It doesn’t have to have the same name as the remote branch! Let’s say I want to name my branch alice , but still have it track origin/main :
I can do that easily enough:
git checkout -b alice --track origin/main
You can see that the local branch is named alice , but the remote branch is named main , and the local copy is origin/main . This is totally OK! It might be a bit confusing, but maybe you already have a different branch named main , and you need to switch to a different branch to work on a different change.
answered Aug 8, 2013 at 22:46
Dietrich Epp Dietrich Epp
206k 37 37 gold badges 346 346 silver badges 415 415 bronze badges
The first part is really useful. I could not connect how More examples, especially the merge one is applicable. Thanks for the answer.
Aug 9, 2013 at 0:50
. because when I «git checkout origin/master» I get into a detached head state. If I indeed have a local copy of the remote master branch, why can’t I work on and commit and add to it? Or maybe I can, but why is it detached?
Mar 28, 2014 at 14:51
You can only commit to a local branch, so when you check out a remote branch, you get «detached head». Of course, it’s a local copy of a remote branch, but it’s still a remote branch. There’s no rule that «master» is related to «origin/master» at all, they could be completely different.
Mar 28, 2014 at 15:47
@Jwan622 «origin is a remote». «origin» is just a name, you can choose any name for remotes but «origin» is the default name. A remote is a repository somewhere else. It could be GitHub or it could be a different computer or it could even be somewhere else on the same computer.
Oct 30, 2014 at 19:02
@Jwan622: «git remote add» is a command that creates a new remote. «origin» is the name that the remote adds. Since «origin» is just a name, you can choose a different name if you like. For example, git remote add home my-server:projects/my-project adds a remote named «home». You may wish to refer to the documentation: git-scm.com/docs/git-remote
Oct 31, 2014 at 16:03
origin/master is an entity (since it is not a physical branch) representing the state of the master branch on the remote origin .
origin master is the branch master on the remote origin .
So we have these:
Example (in local branch master ):
git fetch # get current state of remote repository git merge origin/master # merge state of remote master branch into local branch git push origin master # push local branch master to remote branch master
1 1 1 silver badge
answered Aug 8, 2013 at 22:22
60.8k 8 8 gold badges 138 138 silver badges 175 175 bronze badges
This is incorrect. origin master is not a branch. it is in fact two separate things, «origin» (a remote) and «master» (a local branch).
Aug 8, 2013 at 22:32
The state of the remote master branch, is present locally, right?
Aug 9, 2013 at 0:51
yes this is incorrect origin/master is remote master branch. Local branch is just the master.
Apr 12, 2016 at 19:04
@DietrichEpp Isn’t master a name of remote branch and also a name of local branch? According to your answer, the ‘main’ in the git fetch origin main is a branch name of the remote whose name is origin.
May 4 at 9:55
@starriet: Yes, master is often the name of a remote branch. But to be clear, when you are writing git push origin master , in that command, master is a refspec which names a local branch “master” and, by default, names a remote branch also names a remote branch “master”. You can do something like git push origin master:my-cool-branch and in that command, master is the local branch, and my-cool-branch is the remote branch.
May 4 at 18:52
origin/master is the remote master branch
Usually after doing a git fetch origin to bring all the changes from the server, you would do a git rebase origin/master , to rebase your changes and move the branch to the latest index. Here, origin/master is referring to the remote branch, because you are basically telling GIT to rebase the origin/master branch onto the current branch.
You would use origin master when pushing, for example. git push origin master is simply telling GIT to push to the remote repository the local master branch.
answered Aug 8, 2013 at 22:27
10.1k 9 9 gold badges 53 53 silver badges 76 76 bronze badges
This seems to actually be closest to what OP was looking for — origin master is telling the software to do something with whatever is on ‘master’ in the ‘origin’ repository. origin/master is a reference the same way f3a4d5 or HEAD is.
Apr 1, 2019 at 7:39
origin is a name for remote git url. There can be many more remotes example below.
bangalore => bangalore.example.com:project.git boston => boston.example.com:project.git
as far as origin/master (example bangalore/master) goes, it is pointer to «master» commit on bangalore site . You see it in your clone.
It is possible that remote bangalore has advanced since you have done «fetch» or «pull»
answered Aug 9, 2013 at 2:35
3,061 3 3 gold badges 26 26 silver badges 33 33 bronze badges
Given the fact that you can switch to origin/master (though in detached state) while having your network cable unplugged, it must be a local representation of the master branch at origin .
answered Oct 17, 2017 at 10:54
59 1 1 silver badge 1 1 bronze badge
In the answers above and below, people say origin/master is the remote master branch. Your answer is kind of contradicting what they say. Please do explain.
Sep 9, 2018 at 12:50
Before going to the difference we need to understand what is the meaning of origin in Git .
origin is nothing but the original name given to the remote repository. Origin is just a location that’s all. In the below example the repository URL is the origin or the source of truth of where your code resides.
now this origin or the source of truth to you repository can have branches this includes master or develop or you name it.
Now taking origin in the context we can easily under the below things mean.
- origin master: I am a master branch residing on the remote repository which is called (origin).
So if I type git pull origin master What happens?.
This will update my local master branch (on my local machine) will all changes available on the remote master branch (i.e. origin master).
Now I would like my changes to merged with my local master branch how can I achieve this?
git merge origin/master
This will update my local master branch with my changes. The reason to have origin/master is just naming convention you could have named your local master branch origin/master or abcd. So you could have named you local branch instead of origin/master to just master and the command for git would be git merge master.
How would I update my remote master branch with all the local changes?
git push origin master
В чем отличие между git push -u origin master и git push origin master? Зачем ключ -u для команды git push?
Что хочу получить объяснение: в каком случаи ключ -u необходим?
- Вопрос задан более трёх лет назад
- 44684 просмотра
Комментировать
Решения вопроса 1
В том случае, если ветка master (или branch_name) не является отслеживаемой веткой origin/master (или origin/branch_name), а вы хотите сделать её таковой.
Выполнив команду git push -u origin master вы устанавливаете связь между той веткой, в которой вы находитесь и веткой master на удалённом сервере. Команду требуется выполнить единожды, чтобы потом можно было отправлять/принимать изменения лишь выполняя git push из ветки без указания всяких алиасов для сервера и удалённых веток. Это сделано для удобства.
Ответ написан более трёх лет назад
Нравится 39 2 комментария
Блин, круто, а я кучу времени писал push origin ‘brunch name’
Отслеживаемые ветки — это локальные ветки, которые напрямую связаны с удалённой веткой. Если, находясь на отслеживаемой ветке, вы наберёте git push , Git уже будет знать, на какой сервер и в какую ветку отправлять изменения. (блинк)
Ответы на вопрос 0
Ваш ответ на вопрос
Войдите, чтобы написать ответ
- Git
- +1 ещё
Как залить проект на гитхаб с сохранением папок?
- 1 подписчик
- 21 окт.
- 121 просмотр
В чем разница master и origin master
Подобно названию ветки «master», «origin» не имеет какого-либо специального значения в Git. В то время как «master» — это название по умолчанию для ветки при выполнении git init только потому, что часто используется, «origin» — это название по умолчанию для удалённого сервера, когда вы запускаете git clone.
Разница в том, что master — это имя локальной ветки, а origin/master является удаленной веткой с именем master. Отобразим ветки, связанные с нашим репозиторием:> git branch -a* master remotes/origin/master. Ветка master является текущей (помечена *) веткой ЛР. remotes/origin/master — это ветвь с именем master и псевдонимом origin на УР.
- Что такое master в git
- Что такое мастер ветка
- Как получить все удаленные ветки git
- Сколько веток может быть в репозитории
- Почему Master теперь Main
- Почему Main а не Master
Что такое master в git
Ветка «master» в Git — это не какая-то особенная ветка. Она точно такая же, как и все остальные ветки. Она существует почти во всех репозиториях только лишь потому, что её создаёт команда git init, а большинство людей не меняют её название.
Что такое мастер ветка
Master — стабильная ветка, готовая к выкатыванию на production сервер в любой момент. dev — ветка, над которой в данный момент работает команда. Итак, в начале разработки master и dev ветки идентичны. 1.
Как получить все удаленные ветки git
Как посмотреть ветки в Git:
- Список локальных веток Чтобы вывести список локальных веток используется команда: git branch.
- Список удаленных веток Чтобы показать удаленные (remote) ветки используется ключ -r: git branch -r.
- Список всех веток Для вывода всех веток, локальных и удаленных, используется ключ -a: git branch -a.
Сколько веток может быть в репозитории
Число веток в Git не ограничено, и если следовать всем заповедям (одна ветка на задачу), то веток может быть сколько угодно, но срок их жизни будет недолгим.
Почему Master теперь Main
По умолчанию GitHub использует термин «master» для основной версии репозитория исходного кода. Теперь он будет заменено на «main» — в компании посчитали, что такое слово не только более политкорректно, но и более содержательно. В проектах, созданных до октября 2020 года, будет по-прежнему использоваться старый термин.
Почему Main а не Master
Нэт Фридмэн (Nat Friedman), руководитель GitHub подтвердил намерение компании перейти по умолчанию на использование для основных веток имени «main» вместо «master» в знак солидарности с протестующими против полицейского насилия и расизма в США.
Вот мы и подошли к одному из самых занимательных вопросов в Git — в чем же разница между «master» и «origin master»? Некоторые люди думают, что это связано с магией или загадочными силами, но на самом деле все просто.
Давайте начнем с того, что «master» — это название ветки в Git, которая является основной веткой вашего проекта. Если вы создаете новый репозиторий при помощи команды «git init», то Git автоматически создает ветку «master». Ну, ведь почему бы не назвать самую главную ветку своего проекта «мастер»? Это же круто и красиво!
А что такое «origin master»? О, здесь все еще интереснее! «Origin» — это название по умолчанию для удаленного сервера, с которого вы склонировали свой репозиторий. При клонировании репозитория Git создает удаленную ветку с названием «origin/master». И если вы пытаетесь сделать что-то с этой веткой, то вы работаете с веткой «master» на удаленном сервере.
Ну а разница между «master» и «origin master» заключается в том, что первая находится на вашем компьютере, а вторая — на удаленном сервере. Это похоже на то, как у вас может быть личная копия документа на вашем компьютере, а также копия этого же документа на облачном хранилище. Вы можете работать с обоими копиями, но они могут отличаться друг от друга.
Так что же мы выяснили? Да все просто: «master» — это ваша основная ветка на компьютере, а «origin master» — ваша основная ветка на удаленном сервере. И если вы работаете с проектом, который находится на удаленном сервере, то вам нужно использовать «origin master». А если вы работаете с проектом, который находится на вашем компьютере, то «master» вам подойдет лучше.
В общем, надеемся, что этот комментарий помог вам разобраться в разнице между «master» и «origin master». Ну а если все еще есть вопросы, то не стесняйтесь спрашивать — в Git есть еще много интересного!