Вопрос по git, git-remote – Разветвление Git: мастер против источника / мастер против удаленных / источник / мастер

origin - This is a custom and most common name to point to remote.

$ git remote add origin https://github.com/git/git.git --- Вы запустите эту команду, чтобы связать ваш проект github с origin. Здесь происхождениеuser-defined. $ git remote rename old-name new-name

master - The default branch name in Git is master. For both remote and local computer. origin/master - This is just a pointer to refer master branch in remote repo. Remember i said origin points to remote.

$ git fetch origin - Загружает объекты и ссылки из удаленного хранилища на локальный компьютер [origin / master]. Это означает, что это не повлияет на вашу локальную главную ветку, если вы не объедините их, используя$ git merge origin/master, Не забудьте оформить правильную ветвь, где вам нужно объединиться, прежде чем запускать эту команду

Note: Fetched content is represented as a remote branch. Fetch gives you a chance to review changes before integrating them into your copy of the project. To show changes between yours and remote $git diff master..origin/master

git branch -a (чтобы показать все ветки, о которых знает git). Вероятно, это будет выглядеть примерно так:

* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

Вот,master это ветка в локальном репозитории.remotes/origin/master это ветка с именемmaster на пульте имениorigin, Вы можете сослаться на это какorigin/master, как в:

git diff origin/master..master

Вы также можете сослаться на это какremotes/origin/master:

git diff remotes/origin/master..master

Это просто два разных способа обращения к одной и той же вещи (кстати, обе эти команды означают "показать мне изменения между удаленнымиmaster филиал и мойmaster ветка).

remotes/origin/HEAD этоdefault branch для пульта имениorigin, Это позволяет просто сказатьorigin вместоorigin/master.

& quot; пульты / origin / HEAD - это ветвь по умолчанию & quot; не совсем правильно.

remotes / origin / master была веткой по умолчанию в удаленном репозитории (когда вы последний раз проверяли). ГОЛОВА не ветвь, она просто указывает на ветвь.

Думайте о ГОЛОВЕ как о вашей рабочей зоне. Когда вы думаете об этом таким образом, тогда «git checkout branchname» имеет смысл изменить файлы рабочей области на файлы определенной ветви. Вы & quot; оформить заказ & quot; Разместите файлы в вашей рабочей области. Голова для всех практических целей - это то, что вы видите в своей рабочей зоне.

origin/master is "where master was over there last time I checked" master is "where master is over here based on what I have been doing"

1 в вашем репозитории Git есть только локальные имена, которыеshould соответствуют имена на другой, другой репо. Названныеorigin/whatever Первоначально будет совпадать с теми, которые находятся в репо, с которого вы клонировали:

git clone ssh://some.where.out.there/some/path/to/repo # or git://some.where...

делает локальную копию другого репо. По пути он отмечает все ветви, которые были там, и фиксирует те, на которые ссылаются, и вставляет их в локальный репозиторий под именами.refs/remotes/origin/.

В зависимости от того, как долго вы идете, прежде чемgit fetch или эквивалентно обновлению "моей копии файла some.where.out.there", они могут менять свои ветви, создавать новые и удалять некоторые. Когда вы делаете свойgit fetch (или жеgit pull который действительно принесет плюс слияние), ваш репо сделает копии своей новой работы и изменит всеrefs/remotes/origin/<name> записи по мере необходимости. Это тот моментfetchчто все совпадает (ну, это, и первоначальный клон, и некоторые случаиpushing in & # x2014; в основном всякий раз, когда Git получает возможность проверить & # x2014; но см. предостережение ниже).

Git обычно ссылается на ваш собственныйrefs/heads/<name> как раз<name>и удаленные какorigin/<name>и все это работает только потому, что очевидно, какой из них есть какой. Иногда возможно создать свои собственные имена ветвей, которые делают это не очевидным, но не беспокойтесь об этом, пока это не произойдет. :-) Просто дайте Git самое короткое имя, которое делает его очевидным, и оно пойдет оттуда:origin/master где мастер был там в прошлый раз, когда я проверял & quot; иmaster "где мастер находится здесь на основе того, что я делал". Бежатьgit fetch обновить Git на «где мастер там» по мере необходимости.

Предостережение: в версиях Git старше 1.8.4,git fetch имеет некоторые режимы, которые не обновляют, где мастер находится там. (точнее, режимы, которые не обновляют ветки удаленного отслеживания). Бегgit fetch origin, или жеgit fetch --allили даже простоgit fetch, does Обновить. Бегgit fetch origin master doesn't, К сожалению, это «не обновляет» режим запускается обычнымgit pull, (Это в основном незначительное раздражение и исправлено в Git 1.8.4 и позже.)

1Ну, есть одна вещь, котораяcalled & quot; удаленный & quot ;. Но это также локально! Имяorigin это то, что Git называет «удаленным». Это в основном просто короткое имя для URL, который вы использовали при клонировании. Это также гдеorigin вorigin/master происходит от. Имяorigin/master называетсяremote-tracking branch, который иногда сокращается до «удаленной ветви», особенно в более старой или более неофициальной документации.

щих:

origin/master is the state of master branch on remote repository master is the state of master branch on local repository

I think this git slash notation is probably best understood by looking inside your .git folder.

Например, вот несколько сокращенное дерево моего .git для исходной базы LibreOffice.

Вlinux sudo apt-get install tree Это полезно для просмотра.
ВWindows я думаюtree команда все еще может работать.

Прокрутите вниз и посмотрите на ссылки (также называемые ссылками) внизу:

$ tree  
.  
├── branches  
├── config  
├── description  
├── FETCH_HEAD  
├── gitk.cache  
├── HEAD  
├── hooks  
│   ├── applypatch-msg.sample  
    ...
├── index  
├── info  
│   └── exclude  
├── logs  
│   ├── HEAD  
│   └── refs  
│       ├── heads  
│       │   ├── master  
│       │   └── remotes  
│       │       └── origin  
│       └── remotes  
│           └── origin  
│               ├── distro  
│               │   ├── cib  
│               │   │   └── libreoffice-6-0  
│               │   ├── collabora  
│               │   │   └── cp-6.0  
│               │   └── lhm  
│               │       └── libreoffice-5-2+backports  
│               ├── HEAD  
│               ├── libreoffice-6-2  
│               ├── master  
│               └── private  
│                   └── mst  
│                       └── sw_redlinehide_4a  
├── objects  
│   ├── info  
│   └── pack  
│       ├── pack-b80087dc57e2b3315f449ca0f1aaa91987bf0c5e.idx  
│       ├── pack-b80087dc57e2b3315f449ca0f1aaa91987bf0c5e.pack  
│       ├── pack-eb4e6808029e712d8d9c2671accbbd98aaeb9a04.idx  
│       └── pack-eb4e6808029e712d8d9c2671accbbd98aaeb9a04.pack  
├── ORIG_HEAD  
├── packed-refs  
└── refs  
    ├── heads  
    │   ├── master  
    │   └── remotes  
    │       └── origin  
    ├── remotes  
    │   └── origin  
    │       ├── distro  
    │       │   ├── cib  
    │       │   │   └── libreoffice-6-0  
    │       │   ├── collabora  
    │       │   │   └── cp-6.0  
    │       │   └── lhm  
    │       │       └── libreoffice-5-2+backports  
    │       ├── HEAD  
    │       ├── libreoffice-6-2  
    │       ├── master  
    │       └── private  
    │           └── mst  
    │               └── sw_redlinehide_4a  
    └── tags  
        └── libreoffice-6-2-branch-point  

32 directories, 45 files

Это могло бы быть менее запутанным, если бы оно было так изложено, но это не так:

repositories (i.e. independent trees)
├──local
│  └──master
│
└──origin1
│  └──master
└──origin2
   └──master

У нас есть три основных типа ссылок:heads, remotes, а такжеtags.

.git/refs/heads holds our local master.

.git/refs/remotes can hold a number of remotes, although at the moment we only have origin in it.

.git/refs/tags (is discussed elsewhere).

origin таким образом, это наш единственный пульт. Держитorigin/master.

Мы находим, что у нас есть 2HEADS (указатели на текущие ветви), один локальный и один удаленный:

$ cat .git/HEAD                        #         local:  HEAD -> master
ref: refs/heads/master

$ cat .git/refs/remotes/origin/HEAD    # remote origin:  HEAD -> master
ref: refs/remotes/origin/master

Если вы перечислитеbranches:

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/aoo/aw080
  remotes/origin/aoo/trunk
  remotes/origin/distro/capgemini/cg-4.1
  remotes/origin/distro/cib/libreoffice-5-0
  remotes/origin/distro/cib/libreoffice-5-1
  remotes/origin/distro/cib/libreoffice-5-2
  ...

The first branch listed (master) is the only one which is not a remote. So in this case we have one local branch. This is where we'll start our own work from, for our own new branches and subsequent commits.

Далее, у вас может быть много удаленных веток отслеживания, и мы делаем это здесь. Вы знаете, что это удаленные ветви отслеживания, потому что они имеют префикс & apos;remotes/& APOS ;. Те, что показаны здесь, предназначены для удаленного именованного источника.

So the second line is origin's current branch pointer. Remotes/origin: HEAD --points to--> master. This shows that in the remote repository, the current branch is their branch named master, (not to be confused with our local branch named master).

The remaining branches aren't found in your .git/refs/ tree, but rather you'll find them in .git/packed-refs.

Когда мыgit fetch мы загружаем изменения из удаленного репозитория в наш удаленный репозиторий отслеживания.

Когда мыgit merge мы объединяем изменения в этом локальном удаленном репозитории отслеживания с нашей рабочей локальной ветвью или ветвями, в данном случае с нашей главной ветвью.

(Когда мыgit pull мы делаем оба эти два шага в одной операции.)

Интересно также отметить этиlocal а такжеremote UUID дляmaster в данный момент указывают на тот же узел (он же "commit"):

$ cat refs/heads/master                   # local         master
1ca409292272632f443733450313de5a82c54a9c

$ cat refs/remotes/origin/master          # remote origin master
1ca409292272632f443733450313de5a82c54a9c

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

[local] master = [remote] origin master

Наконец, я думаю, что также полезно взглянуть на.git/packed-refs

$ cat packed-refs 
# pack-refs with: peeled fully-peeled 
3c1d4742e649fe9c8aed8c2817fe3e1f3364f298 refs/remotes/origin/aoo/aw080
e87c8b7922e9a73e0abb7f9a7a47c9ac3374a826 refs/remotes/origin/aoo/trunk
b70fdffb041c12f124dcc0822b61bf3450e53137 refs/remotes/origin/distro/capgemini/cg-4.1
5dbc3f1754809b9489faaf380b1a4bdbcfbb6205 refs/remotes/origin/distro/cib/libreoffice-5-0
cfdbc96ca47d68d6785fd21829a8d61f49d6e591 refs/remotes/origin/distro/cib/libreoffice-5-1
5189c8c47461ef09739086e55512fc6a10245273 refs/remotes/origin/distro/cib/libreoffice-5-2
3bee5917569ca8e6ee3b086458f5b1a917b88ca1 refs/remotes/origin/distro/cib/libreoffice-5-3
92fbe703f9ca480d3a2b8610d87e991c729edf77 refs/remotes/origin/distro/cib/libreoffice-5-4
05c0a5df66cc69d75280f05b804cf82f3387d42b refs/remotes/origin/distro/cib/libreoffice-6-0
7fe193e759b24b90852e6e327115b77114d7b119 refs/remotes/origin/distro/cib/libreoffice-6-1
8187f7aa413e7ef7b377eea2b057d336bf256867 refs/remotes/origin/distro/collabora/cd-5.3
7a6b608591e21ef61dc05cff9fc58da531035755 refs/remotes/origin/distro/collabora/cd-5.3-3.1
....

Без сомнения, это оставляет больше вопросов, чем ответов, но я думаю, что это может помочь вам ответить на ваши собственные вопросы о том, что и что.