Как мне сделать «git fetch» ​​и «git merge» из удаленной ветки отслеживания (например, «git pull»)

Я настроил несколько удаленных веток отслеживания в git, но мне кажется, что я никогда не смогу объединить их с локальной веткой, как только я обновил их с помощью 'git fetch'.

Например, предположим, что у меня есть удаленная ветвь, называемая an-other-branch. Я настроил это локально как ветвь отслеживания, используя

git branch --track an-other-branch origin/an-other-branch

Пока все хорошо. Но если эта ветка обновляется (как правило, я перемещаю машину и фиксирую с этой машины), и я хочу обновить ее на исходной машине, у меня возникают проблемы с fetch / merge:

git fetch origin an-other-branch
git merge origin/an-other-branch

Всякий раз, когда я делаю это, я получаю сообщение «Уже обновлено» и ничего не сливается.

Тем не менее,

git pull origin an-other-branch

всегда обновляет его, как и следовало ожидать.

Также работает git diff

git diff origin/an-other-branch

показывает, что есть различия, поэтому я думаю, что у меня неправильный синтаксис.

Что я делаю не так?

РЕДАКТИРОВАТЬ [2010-04-09]: Я проверял пару раз, и я определенно не на другой ветке. Должен ли мой 'git fetch' с последующим 'git merge' (как показано выше) делать то же самое, что и git pull? Я получу некоторый рабочий процесс, показывающий результаты состояния git и т. Д.

вопрос задан 8.04.2010
kaybenleroll
7445 репутация

5 ответов


  • 160 рейтинг

    Вы не получаете ветку, вы получаете весь пульт:

    git fetch origin
    git merge origin/an-other-branch
    
    ответ дан Gareth, с репутацией 86936, 8.04.2010
  • 66 рейтинг

    Выбор только одной ветви: fetch/merge vs. pull

    Люди часто советуют вам отделить «выборку» от «слияния». Вместо этого они говорят:

        git pull remoteR branchB
    

    сделать это:

        git fetch remoteR
        git merge remoteR branchB
    

    Что они не упоминают, так это то, что такая команда выборки будет на самом деле извлекать все ветви из удаленного репозитория, а это , а не , что делает эта команда извлечения. Если у вас есть тысячи филиалов в удаленном репо, но вы не хотите видеть их все, вы можете выполнить эту неясную команду:

        git fetch remoteR refs/heads/branchB:refs/remotes/remoteR/branchB
        git branch -a  # to verify
        git branch -t branchB remoteR/branchB
    

    Конечно, это смехотворно трудно запомнить, поэтому, если вы действительно хотите избежать выборки всех веток, лучше изменить свой .git/config, как описано в ProGit.

    А?

    Лучшее объяснение всего этого - в главе 9-5 ProFit, Git Internals - Refspec ( или через github ). Это удивительно трудно найти через Google.

    Во-первых, нам нужно прояснить некоторую терминологию. Для отслеживания удаленных веток обычно нужно знать о трех разных ветках:

    1. Филиал на удаленном репо: refs/heads/branchB внутри другого репо
    2. Ваша ветка удаленного слежения : refs/remotes/remoteR/branchB в вашего репо
    3. Ваша собственная ветка: refs/heads/branchB внутри вашего репо

    Удаленное отслеживание ветвей (в refs/remotes) только для чтения. Вы не изменяете их напрямую. Вы изменяете свою собственную ветку, а затем нажимаете на соответствующую ветку в удаленном репо. Результат не отражается в вашем refs/remotes до тех пор, пока не будет произведено соответствующее извлечение или извлечение. Мне было трудно понять это различие из man-страниц git, главным образом потому, что локальная ветвь (refs/heads/branchB), как говорят, «отслеживает» ветку удаленного отслеживания, когда .git/config определяет branch.branchB.remote = remoteR.

    Думайте о 'refs' как о указателях C ++. Физически это файлы, содержащие SHA-дайджесты, но в основном они просто указатели на дерево коммитов. git fetch добавит много узлов в ваше дерево коммитов, но то, как git решает, какие указатели перемещать, немного сложнее.

    Как уже упоминалось в другой ответ , ни

        git pull remoteR branchB
    

    или

        git fetch remoteR branchB
    

    будет двигаться refs/remotes/branches/branchB, и последний, конечно, не может двигаться refs/heads/branchB. Однако оба ходят FETCH_HEAD. (Вы можете cat любой из этих файлов внутри .git/, чтобы увидеть, когда они изменятся. ) И git merge будет ссылаться на FETCH_HEAD, при этом устанавливая MERGE_ORIG, и т. Д.

    ответ дан cdunn2001, с репутацией 11829, 17.01.2011
  • 9 рейтинг

    Вы уверены, что находитесь на местном an-other-branch при слиянии?

    git fetch origin an-other-branch
    git checkout an-other-branch
    git merge origin/an-other-branch
    

    другое объяснение :

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

    .

    если вы опережаете удаленное репо на один коммит, это удаленное репо устарело, а не вы.

    Но в вашем случае, если git pull работает, это просто означает, что вы не на правильной ветке.

    ответ дан VonC, с репутацией 807261, 8.04.2010
  • 3 рейтинг

    Git pull - это на самом деле комбинированный инструмент: он запускает git fetch (получает изменения) и git merge (объединяет их с текущей копией)

    Вы уверены, что находитесь на правильной ветке?

    ответ дан RDL, с репутацией 6436, 8.04.2010
  • 1 рейтинг

    это команды:

    git fetch origin
    git merge origin/somebranch somebranch
    

    , если вы делаете это во второй строке:

    git merge origin somebranch
    

    он попытается объединить локального мастера с вашей текущей веткой.

    Вопрос, насколько я понял, состоял в том, что вы уже получили локально и хотите теперь объединить свою ветку с последней из той же самой ветки .

    ответ дан user1524957, с репутацией 196, 21.07.2013