Я думаю, что на данном этапе (на основе обсуждения выше), что вы получаете немного перепутали с тем, что значит быть «на ветке», и т.д.
Глубоко внутри мерзавца, когда вы делаете git checkout NAME
, git разрешает NAME
конкретному конкретному фиксации. Эта фиксация привязана к дереву - дереву каталогов, заполненному файлами, - и проверяет попытки получить то конкретное дерево в ваше дерево (не сбивая никаких несохраненных файлов и т. Д.), Но давайте предположим, что ваше дерево работы во всех случаях является нетронутым, чтобы упростить здесь).
Другое дело checkout
действительно, если имя является одним из ваших собственных имен филиалов, оно записывает вашу «текущую ветвь» как HEAD
. Тем не менее, это имя возможно для того, чтобы не называть «свою» ветвь. Это верно, если вы заканчивали явный «удаленный» филиал:
$ git checkout remotes/origin/master
Note: checking out 'remotes/origin/master'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at fb4a1b2... (some commit message)
Это также является то, что произойдет, если вы заканчивали явный тег:
$ git checkout v1.0
Previous HEAD position was fb4a1b2... (some commit message)
HEAD is now at cfb9904... (another commit message)
Во всех этих случаях, у вас есть отлично подходящее дерево работы, которое представлено этими конкретными идентификаторами фиксации. Вы больше не находитесь «на ветке» вообще (состояние «отдельно стоящего HEAD»). (Вы можете «вернуться на ветку», проверив какую-либо локальную ветку или создав новую локальную ветвь с git checkout -b newname
, чей совет тогда является то, что HEAD is now at ...
)
Теперь скажите, что у вас есть «удаленная ветка», умышленное отслеживание:
$ git checkout GRONKLE # my local branch, which tracks remotes/origin/GRONKLE
$ git pull
«тянуть» здесь состоит из выборки и слияния. В шаге «выборка» используется соответствующий базовый транспорт для переноса любых новых коммитов на удаленную ветку. Это дает вам «то, что они сделали». Шаг «merge» затем пытается применить «то, что они сделали» к «тому, что у вас есть» в вашей локальной сети.
Скажем, например, что «то, что у вас есть» было полностью синхронизировано с «тем, что они сделали» вчера. Затем, сегодня вы изменили dir1/file1 и dir1/file2 (и зафиксировали это). Между тем, «они» изменили dir2/file3 (и зафиксировали это в вашем репозитории remotes/origin).Когда вы делаете «git fetch», это получает их обновления в dir2/file3 и делает remotes/origin/GRONKLE
имя «что у них есть». Ваша отрасль: behind ... by 1 commit
.
Когда вы продолжать делать «GIT слияния», однако, что касается их изменения dir2/file3, но и сохраняет изменения в dir1/file1 и file2 dir1 /. Это дает вам новый commit, который является «фиксацией слияния». Ваша ветка теперь впереди одной фиксацией.
Если вы хотите создать «то, что у них есть» - это то, что вы сказали в исходном вопросе, - тогда вы не должны ваши изменения в dir1/file1 и dir1/file2, сидящие вокруг. Вы можете просто проверить remotes/origin/GRONKLE
(в этом примере), и у вас будет именно то, что они вам дали, не больше и не меньше.
Если вы хотите построить «то, что у них есть, плюс то, что у меня есть», вам необходимо объединить и/или переупаковать, как сказал @Adam Dymitruk. Но это не «то, что у них есть». И - в ответ на ваш ответ на него - вы никогда не «на теге» вообще. Тег - это просто имя конкретной фиксации, и если вы проверите этот тег, вы снова находитесь в том же состоянии «отдельно стоящего HEAD». Если вы хотите внести изменения в «новую ветку, которая начинается с того, где начинается этот тег» (см. Сноску), вам нужно создать новую ветку, начиная с этого тега.
Если вы хотите создать новый (местное) отделение, начиная с некоторого заданного фиксации, есть два простых способа:
$ git checkout <commit>
(теперь вы на этой фиксации и может посмотреть вокруг и увидеть, если это на самом деле тот, который вы хотите), а затем:
$ git checkout -b new_local_branch
Или, если вы достаточно уверены в своей начальной точки:
$ git checkout -b new_local_branch <commit>
(и примерно полдюжины других способов, используя git branch
, но вышеприведенных двух хватает).
Сноска: ветви на самом деле не «начинают» нигде, ведь все сказано и сделано. Точнее, вы получаете исходную точку - проверяете какой-то конкретный идентификатор фиксации - и делаете любую работу, которая вам нравится оттуда, делаете новые коммиты и т. Д., Но как только вы помещаете ярлык филиала, чтобы помнить эту работу, ветвь метка просто следует «подсказке» этой работы. До тех пор, если вы находитесь в состоянии «отдельно стоящего HEAD», первичная ссылка на любые новые фиксации, которые вы делаете, - это ваша отдельная головка. Легко «потерять» эту ссылку, хотя, если вы
не делаете новую ветку, хотя, если вы соскучитесь внутри git, вы можете найти все дополнительные места, которые она сохраняет для вас, как правило, до трех месяцы.
Если вы действительно хотите построить на основе удаленной ветви, есть ли какая-то причина не проверять эту фактическую ветку? 'git checkout remotes/origin/GRONKLE' предоставит вам состояние' HEAD' ('.git/HEAD' будет содержать исходный идентификатор фиксации), чтобы ваше дерево работы содержало то, что находится в удаленной ветке. Аналогично, вы можете просто «git checkout tagname» проверить эту ветку. Вам нужно только создать и/или объединить в локальный ветвь, если вы хотите, чтобы локальная ветка и/или локальные изменения. – torek
Я нахожусь в локальной ветке и хочу перейти к указанной ветке/тегу (как входной аргумент) и построить его. Однако, если это касается ветви, мне нужно выполнить какое-то нажатие, чтобы объединить все удаленные изменения. Только проверка ветки не даст мне последних изменений. – edbras
Вам не нужно использовать 'pull'; 'git fetch' получит самые последние обновления с пульта. См. Также ответ @Adam Dymitruks ... но я думаю, что у вас есть какое-то фундаментальное непонимание того, как работают ветки, теги и «пульты», и я не уверен, что это недоразумение. – torek