fetch in git erhält nicht alle Zweige

Question

Ich habe ein Repository geklont, woraufhin jemand anderes einen neuen Zweig erstellt hat, an dem ich nun arbeiten möchte. Ich habe das Handbuch gelesen, und es scheint ganz einfach zu sein. Seltsamerweise funktioniert es nicht, und alle Beiträge, die ich gefunden habe, deuten darauf hin, dass ich das Richtige tue. Ich werde mich also der Kritik aussetzen, denn es gibt muss etwas offensichtlich falsch sein:

Die richtige Maßnahme scheint zu sein

git fetch
git branch -a
* master
  remotes/origin/HEAD --> origin/master
  remotes/origin/master
git checkout -b dev-gml origin/dev-gml

An dieser Stelle gibt es aus irgendeinem Grund ein Problem, nachdem git fetch Ich kann den Remote-Zweig dev-gml nicht sehen. Warum nicht? Wenn ich das Repository neu klone, ist es da, also existiert der entfernte Zweig mit Sicherheit:

$ mkdir ../gitest
$ cd ../gitest
$ git clone https://github.com/example/proj.git
Cloning into proj...
remote: Counting objects: 1155, done.
remote: Compressing objects: 100% (383/383), done.
remote: Total 1155 (delta 741), reused 1155 (delta 741)
Receiving objects: 100% (1155/1155), 477.22 KiB | 877 KiB/s, done.
Resolving deltas: 100% (741/741), done.
$ cd projdir
$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/dev-gml
  remotes/origin/master

Ich habe versucht git update , git pull , git fetch --all , git pretty-please in allen möglichen Permutationen...

Answer 1

Ich hatte ein ähnliches Problem, aber in meinem Fall konnte ich zum entfernten Zweig ziehen/schieben, aber git status den Status der lokalen Zweigstelle im Vergleich zu den entfernten Zweigstellen nicht angezeigt.

Auch in meinem Fall git config --get remote.origin.fetch hat nichts zurückgeschickt

Das Problem ist, dass es einen Tippfehler in der .git/config Datei in der Fetch-Zeile des jeweiligen Remote-Blocks. Wahrscheinlich etwas, das ich vorher aus Versehen hinzugefügt habe (manchmal schaue ich mir diese Datei direkt an, oder bearbeite sie sogar)

Prüfen Sie also, ob Ihr Fernbedienungseintrag im .git/config Datei korrekt ist, z.B.:

[remote "origin"]
    url = https://[server]/[user or organization]/[repo].git
    fetch = +refs/heads/*:refs/remotes/origin/*

Answer 2

git checkout --track origin/formats Das schien zu funktionieren:

% git branch      ### show local branches
* main

% git branch - a  ### show local and remote branches
* main
  remotes/origin/HEAD -> origin/main
  remote/origin/formats
  remote/origin/main

% git checkout --track origin/formats
Switched to a new branch 'formats'
Branch 'formats' set up to track remote branch 'formats' from 'origin'

% git branch
* formats
  main

Das folgende Beispiel sollte das Gleiche bewirken, allerdings mit einem anderen Namen für den lokalen Zweig:

git checkout -b my-formats origin/formats 

Eine neue Syntax git switch ist in git c2.23 verfügbar

git switch -c <branch> --track <remote>/<branch>

Answer 3

Um es genauer zu machen Erstellen Sie einen Verfolgungszweig, was bedeutet, dass Sie jetzt einen entfernten Zweig verfolgen.

git branch --track branch remote-branch
git branch --track exp remotes/origin/experimental

Danach können Sie

git branch   # to see the remote tracking branch "exp" created .

Um diesen Zweig zu bearbeiten, müssen Sie dann

git checkout branchname
git checkout exp

Nachdem Sie Änderungen an der Verzweigung vorgenommen haben. Sie können git fetch und git merge mit Ihrem entfernten Verfolgungszweig verwenden, um Ihre Änderungen zusammenzuführen und in den entfernten Zweig zu übertragen (siehe unten).

git fetch origin
git merge origin/experimental  
git push origin/experimental

Ich hoffe, es hilft Ihnen und gibt Ihnen eine Vorstellung davon, wie das Ganze funktioniert.

Answer 4

Der Grund dafür könnte ein "Face Palm"-Moment sein: Wenn man zwischen mehreren Klonen hin und her wechselt, kann es leicht passieren, dass man sich im falschen Quellbaum wiederfindet und versucht, einen nicht existierenden Zweig zu ziehen. Es ist einfacher, wenn die Klone ähnliche Namen haben, oder die Repos verschiedene Klone für das gleiche Projekt von jedem der mehreren Mitwirkenden sind. Ein neuer Git-Klon scheint dieses "Problem" zu lösen, obwohl das eigentliche Problem darin besteht, den Fokus oder den Arbeitskontext oder beides zu verlieren.

Answer 5

Ich musste in meine GitExtensions Remote Repositories gehen, da hier nichts zu funktionieren schien. Dort sah ich, dass für 2 Zweige kein entferntes Repository konfiguriert war. nach der Anpassung sieht es wie folgt aus

Hinweis Zweigstelle noExternal3 zeigt immer noch an, dass es kein entferntes Repository gibt. Ich bin mir nicht sicher, welche Kombination von Bash-Befehlen dies gefunden oder angepasst hätte.