TL; сводка DR
Коммиты делятся (копируя) между различными репозиториями Git. Ветки являются не общими: когда вы запускаете git fetch, ваш Git запрашивает какой-то другой Git о своих ветвях, а затем ваш Git создает имена для удаленного отслеживания как origin/master чтобы запомнить их ветви. Это не влияет на ваши ветви!
Вы также можете запустить git push, который заставит ваш Git вызвать их Git и попросить их создать или обновить их веток, что опять-таки не повлияет на ваши ветки. Но успешное git push имеет ваше обновление Git ваши имена Git для удаленного слежения, поскольку имена вашего Git для удаленного слежения запоминают, где их ветви Git идут.
Что вы сделали
Вы создали новый пульт . Пульт дистанционного управления - это способ, которым ваш Git запоминает URL-адрес какого-то другого Git, и вместе с этим запоминает некоторые или все их - другие ветви Git - по крайней мере, по состоянию на последний раз твой мерзавец разговаривал со своим мерзавцем.
По умолчанию git remote add просит ваш Git записать, под некоторым именем, URL для какого-то другого Git. Это все по умолчанию, поэтому:
git remote add them <url>
только что ваш Git запомнил <url> под именем them, так что вы можете - позже - запустить git fetch them или git push them без необходимости ввода снова длинный URL.
Добавление -t говорит вашему Git, что он должен не только записать URL, но и изменить способ, которым ваш Git будет общаться со своим Git в будущем. Обычно ваш Git вызывает их Git и выдает список всех их ветвей, а затем копирует все этих имен в ваши имена для удаленного отслеживания. То есть после:
git remote add sprint-01 <url> -t master
(вы можете перетасовать -t больше вперед, как вы это сделали), next git fetch вызов вашего Git для их Git будет выглядеть так:
- ВАШ GIT: Привет
them, какие ветви у вас есть?
- ИХ ГИТ : у меня есть
master, dev и feature-123.
- ВАШ GIT: Меня не волнуют
dev и feature-123, но я даю вам любые master коммиты, которые у меня есть, а у меня нет.
- Вставьте длинный разговор о хеш-идентификаторах - теперь, когда ваш Git знает свой
master хеш-идентификатор, все происходит по хеш-идентификатору. Как только ваш Git узнает, какие хеш-идентификаторы у вас есть, а ваш Git отправит вам все коммиты и все необходимые файлы и так далее.
- Наконец, после того, как ваш Git получил необходимые коммиты, ваш Git создает ваш
sprint-01/master для запоминания их master.
Обратите внимание, что нигде в этом процессе ваши Git никогда не просили их Git создавать какие-либо ветви. Кроме того, ваш Git не создал ни одной ветки : в конце разговора git fetch выше, ваш Git создает вашу sprint-01/master. (Полное название этой вещи refs/remotes/sprint-01/master.) Это способ, которым ваш Гит помнит их Гит master. Ваш Git вставляет sprint-01/ впереди, чтобы помнить, что он пришел от remote , который вы назвали sprint-01: sprint-01 - это имя, которое вы используете, чтобы запомнить URL для своего Git.
Что вы хотели сделать
У вас, вероятно, уже есть пульт, запоминающий URL другого Git. Имя этого пульта origin.
Вы бы хотели, чтобы ваш Git вызвал их Git и начал совсем другой разговор:
ВАШ GIT: Привет origin, я бы хотел, чтобы вы создали новую ветку с именем sprint-01. Сделайте так, чтобы он указывал на (какой-то конкретный идентификатор хэша коммита) .
ИХ ГИТ: ОК, готово.
ВАШ ГИТ: 'kthxbye!
Теперь, когда ваш Git увидел, что его Git создал sprint-01, и знает, какой хеш-код коммита ваш Git попросил использовать, ваш Git создает в вашем хранилище имя для удаленного слежения origin/sprint-01.
Theхитрая часть здесь фраза некоторый конкретный хеш-идентификатор коммита .Где вы получите этот хэш-идентификатор?Единственный хэш-идентификатор, который ваш Git может использовать, это хэш-идентификатор некоторого коммита, который вы имеете в своем собственном репозитории .
Обычно way Вы выбираете идентификатор хеша коммитов, чтобы просмотреть коммиты, которые есть в вашем репозитории, и выберите один из них как правильный коммит, который они должны также использовать как их sprint-01.Например, вы можете использовать git log для поиска этого коммита.
Затем вы создаете свою собственную ветку , используя хеш-код этого коммита:
git branch sprint-01 <hash>
или:
git checkout -b sprint-01 <hash>
Если никакой коммит не подходит, потому что вам нужен новый коммит, вы сначала создаете свой собственный sprint-01 из некоторого существующего хеш-идентификатора коммита:
git checkout -b sprint-01 <existing-hash>
и затем создайте для себя новый коммит, который подходит , как обычно, для любого коммита.
Тогда, в любом случае, теперь у вас есть, в вашем Git, ветвь с именем sprint-01, которая указывает на желаемый идентификатор хеша коммита.Это может быть какой-то существующий коммит, который они, вероятно, уже имеют, или какой-то новый коммит, который вы только что создали, чей идентификатор родительского хэша является некоторым существующим коммитом, который они, вероятно, уже имеют.Теперь вы можете просто запустить:
git push origin sprint-01
, чтобы ваш Git вызывал их Git, предлагал им новые коммиты при необходимости, а затем просил их Git создать их sprint-01 ветвь, указывающая на тот же хеш-код фиксации , который использует ваш.
Терминология: или, tracking - плохо перегруженный глагол
Он создавал удаленную ветвь, мастер слежения, для спринтов (поэтому sprint-01 (удаленный) мастер треков) ...
Это не совсем имеет смысла, как указано.
У Git проблема с терминологией.Я использовал фразу имя удаленного слежения для описания таких строк, как refs/remotes/origin/master (или origin/master для краткости). имя для удаленного отслеживания - это имя в вашем хранилище Git, целью которого является запоминание хеш-идентификатора, хранящегося под их Git's branch name,Git называет это веткой удаленного отслеживания , но на самом деле это не ветка, потому что вы не можете получить на так, как вы можете создать настоящую ветку:
$ git checkout origin/master
Note: checking out 'origin/master'.
You are in 'detached HEAD' state. ...
Обратите внимание на несколько пугающие вещи о "отрешенной голове" здесь.Все это на самом деле означает: вы сейчас не находитесь ни в одной ветке. Запуск git status покажет вам, среди прочего, HEAD detached at ....Но:
$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
Теперь git status скажет on branch master.
Тогда ветвь - это то, что вы можете получить , запустив git checkout <em>branch-name</em>,Вы не можете «включить» имя для удаленного отслеживания, например origin/master, поэтому мы не должны называть его branch .Более длинная фраза «ветка удаленного слежения» содержит слово «ветка», поэтому это не очень хорошая фраза.(Но Git использует его, так что имейте в виду, что «ветка удаленного отслеживания» не является веткой , даже если в ней есть слово «ветка»!)
Теперьветвь - но не имя удаленного слежения - может быть настроена на то, что современный Git называет upstream .У вас может быть один и только один восходящий поток для каждой из ваших ветвей.Чтобы установить восходящий поток какой-либо существующей ветви, выполните:
git branch --set-upstream-to=<upstream> <branch>
Обычно восходящий поток ветви master равен origin/master.Выше dev или develop будет ваш origin/dev или origin/develop.Шаблон здесь ясен: обычно вы хотите, чтобы восходящий поток вашей (локальной) ветки X был (вашим) именем удаленного слежения origin/<em>X</em>.
Чтобы сделать это такчто ветка имеет нет в восходящем направлении, запустите:
git branch --unset-upstream <branch>
Никогда не необходимо до --unset-upstream, но иногда вам может понадобиться.См. Зачем вызывать git branch --unset-upstream для исправления?
WhВ ветке, подобной master, в качестве восходящего потока установлено origin/master, Git говорит, что master - это tracking origin/master.Обратите внимание, что этот глагол tracking применяется к local имени ветви.Вы можете установить восходящий поток одной из ваших (локальных) веток на другую локальную ветку, тоже:
git branch foo # create a new local branch named foo
git branch --set-upstream-to=master foo # set its upstream to master
Вы не можете установить восходящий поток для удаленногоимя отслеживания:
$ git status
On branch master
Your branch is up to date with 'origin/master'.
$ git branch --set-upstream-to=master origin/master
fatal: branch 'origin/master' does not exist
Это правильно: ответвление origin/master не существует;существует только имя удаленного отслеживания origin/master. 1 Это означает, что имя удаленного отслеживания не может ничего отслеживать в том смысле, в котором глагол отслеживает используется для веток!Это верно, даже если это имя для удаленного отслеживания: как имя для удаленного отслеживания, оно просто автоматически обновляется при запуске git fetch, основываясь на том, что ваш Git извлекает из другого Git.
Этот же глагол дорожка применяется и к файлам: некоторые файлы отслеживаются , а другие не отслеживаются .Этот конкретный вид отслеживания не имеет ничего общего с ветками!Файл отслеживается тогда и только тогда, когда он находится в индексе Git.Индекс очень важен, но не имеет ничего общего с именами веток и именами удаленного отслеживания, поэтому все, что я скажу здесь, это то, что вы можете помещать файлы в индекс или извлекать файлы из него в любое время, что означает, чтокакой-то файл отслеживается - это то, что вы можете контролировать;это имеет решающие последствия, когда вы запускаете git commit, потому что git commit делает новые коммиты из индекса, а не из рабочего дерева.
Теперь, когда мы знаем, что tracking , для ветви означает, что имеет восходящий набор , давайте посмотрим на это еще раз:
(так что sprint-01 (удаленный) мастер треков)
Если sprint-01 является локальной ветвью, оно может отслеживать другое имя, например master, но если sprint-01 является именем для удаленного отслеживания, оно не может отслеживать любое другое имя.
Если вы имеете в виду, что когда вы входите в систему на удаленном компьютере и cd в этом хранилище, , то в этом хранилище есть (локальная) ветвь с именем master, ну, , это хранилище(локально) sprint-01 может, конечно, отслеживать любое другое имя в этом хранилище, но ветви этого хранилища их .Их Git не контролирует имена веток в вашем хранилище, и любой вышестоящий набор там даже не видимый для вашего Git!Так что это утверждение - что origin * sprint-01 настроено на origin, так что оно отслеживает origin * master - может быть правдой, но совершенно не имеет отношения к ваш Git.
1 С технической точки зрения ветвь - это любая ссылка, чье полное имя начинается с refs/heads/.Имя для удаленного отслеживания - это любая ссылка, полное имя которой начинается с refs/remotes/.Git обычно удаляет части refs/heads/ и refs/remotes/ для отображения, хотя иногда - например, в выводе git branch -a - он удаляет только refs/ из имен удаленного отслеживания.Некоторые команды Git, такие как git for-each-ref, по умолчанию отображают полное имя ссылки;как правило, только так называемые команды сохраняют полное имя.
Заключение
При работе с Git всегда помните:
В хранилище хранится коммитов .Каждый коммит содержит файлы, поэтому, в конце концов, репозиторий также содержит файлы, но он делает коммит одновременно.Каждый коммит имеет уникальный хэш-идентификатор.
Почти всегда существует более одного хранилища.
При соединении двух хранилищ друг с другом они совместно используютфиксирует по хэш-идентификатору.Отправляющий Git и получающий Git общаются и обмениваются хэш-идентификаторами, чтобы узнать, кто что имеет и кому что нужно.Затем отправитель отправляет коммитов - не файлы, а целые коммиты - получателю.Теперь отправитель и получатель имеют одинаковые коммиты по хеш-идентификатору.
Есливы используете git push, вы отправитель, а они - получатель. В конце ваш Git либо вежливо задает свой Git вопрос: Если вы хотите, пожалуйста, задайте для некоторых имен ваших веток и / или тегов какие-то конкретные хеш-идентификаторы фиксации? или он им командует, как в git push --force: Установите эти имена ветвей и / или тегов для этих хеш-идентификаторов! Хеш-идентификаторы взяты из вашего Git и соответствуют коммитам, которые ваш Git только что поделился при необходимости (если у них их уже не было).
Они могут отказаться! Вежливый запрос будет отклонен, если они потеряют некоторые коммиты, например, установив имя ветви. Команда подчиняется или отклоняется в зависимости от элементов управления и разрешений - по умолчанию всегда выполняется, но в наши дни службы веб-хостинга всегда предлагают элементы управления.
Если они подчиняются запросу или команде, ваш Git обновит ваши имена для удаленного отслеживания. (Ваш Git не знает ни о каких других именах, которые они обновили или не обновили, поэтому ваш Git только обновляет ваши имена для удаленного отслеживания для имен ветвей, для которых вы их установили.)
Если вы используете git fetch, ваш Git является получателем. В большинстве случаев вы получаете все их имена ветвей, а ваш Git затем обновляет все ваши имена для удаленного слежения. Вы можете сознательно ограничить имена, которые ваш Git спрашивает у Git. Например:
git fetch origin master
ваш Git вызывает их Git и спрашивает их только об их master. Вы получаете любые новые коммиты, которые у них есть, а у вас нет, и тогда ваш Git обновляет только свой собственный origin/master - вы не выбирали другие ветви для просмотра, поэтому ваш Git этого не делает.
Вы также можете установить однопоточный режим на любом пульте дистанционного управления. Это то, что git remote add делает при использовании с -t. В этом режиме git fetch автоматически запрашивает только одну из перечисленных вами веток. Это редко очень полезно: в основном это касается огромных, высокоактивных репозиториев, в которых вы только просматриваете или вносите вклад в небольшую часть (одну ветвь), поэтому вам не нужны все действия в большинстве удаленных , Вы можете сделать это для небольших и менее активных репозиториев, но если у вас нет подключения к Интернету со скоростью 9600 бод, это не сэкономит вам достаточно времени, чтобы побеспокоиться.
git pull просто означает run git fetch, затем выполните вторую команду Git . git fetch - это место, где происходят все действия get-me-их-коммитов с удаленным репозиторием. Это также обновило ваш origin/master или что-то еще. Команда second Git полезна , потому что git fetch не касается ваших ветвей. Обычно после получения их новых master коммитов вы также хотите обновить свой master.
Одной из нескольких проблем здесь является как вы хотите обновить master. Вы хотите обновить git merge или git rebase? Если вы заранее знаете наверняка, какую команду вы хотите использовать, вы можете запустить git pull: git pull --rebase запустит git rebase и git pull без --rebase запустит git merge, как вторая команда. Тогда все будет готово, и один git pull удобнее, чем git fetch, за которым следует вторая команда Git.
Но если вы не точно знаете, хотите ли вы git merge или git rebase или, возможно, что-то еще целиком, тогда git pull - ловушка. Мне нравится запускать git fetch, затем проверять, что я только что получил , и только , а затем решить, что делать. Команда git pull заставляет вас решить, что вы будете делать, прежде чем вы сможете увидеть, что вы получили. Поэтому я обычно избегаю этого, но это я, в моей ситуации, которая может отличаться от вас в вашей.
(В очень старых версиях Git, за 1,5 и 1,6 дня, git pull имел вполне заслуженную репутацию за случайное уничтожение вашей работы тоже. Я потерял часть работы из-за ошибок git pull.)