Wie kann ich beim Hinzufügen eines Git-Submoduls einen Zweig / ein Tag angeben?

Wie funktioniert das git submodule add -b?

Nach dem Hinzufügen eines Submoduls mit einem bestimmten Zweig befindet sich ein neues geklontes Repository (nachher git submodule update --init) in einem bestimmten Commit, nicht im Zweig selbst ( git statusim Submodul wird "Derzeit in keinem Zweig" angezeigt).

Ich kann keine Informationen über .gitmodulesoder .git/configüber den Zweig des Submoduls oder ein bestimmtes Commit finden. Wie findet Git das heraus?

Ist es auch möglich, ein Tag anstelle eines Zweigs anzugeben?

Ich verwende Version 1.6.5.2.

Hinweis: Git 1.8.2 hat die Möglichkeit hinzugefügt, Zweige zu verfolgen. Sehen Sie einige der Antworten unten.

Es ist etwas verwirrend, sich daran zu gewöhnen, aber Submodule befinden sich nicht in einem Zweig. Sie sind, wie Sie sagen, nur ein Zeiger auf ein bestimmtes Commit des Repositorys des Submoduls.

Dies bedeutet, wenn jemand anderes Ihr Repository auscheckt oder Ihren Code abruft und das Git-Submodul aktualisiert, wird das Submodul für dieses bestimmte Commit ausgecheckt.

Dies ist ideal für ein Submodul, das sich nicht oft ändert, da dann jeder im Projekt das Submodul gleichzeitig festschreiben kann.

Wenn Sie das Submodul in ein bestimmtes Tag verschieben möchten:

cd submodule_directory
git checkout v1.0
cd ..
git add submodule_directory
git commit -m "moved submodule to v1.0"
git push

Ein anderer Entwickler, der möchte, dass submodule_directory in dieses Tag geändert wird, führt dies aus

git pull
git submodule update --init

git pullÄnderungen, auf die das Submodulverzeichnis verweist, verweisen auf. git submodule updateführt tatsächlich den neuen Code zusammen.

Ich möchte hier eine Antwort hinzufügen, die eigentlich nur ein Konglomerat anderer Antworten ist, aber ich denke, dass sie vollständiger sein kann.

Sie wissen, dass Sie ein Git-Submodul haben, wenn Sie diese beiden Dinge haben.

1. Ihr .gitmoduleshat einen Eintrag wie folgt:

   [submodule "SubmoduleTestRepo"]
       path = SubmoduleTestRepo
       url = https://github.com/jzaccone/SubmoduleTestRepo.git
   

2. Sie haben ein Submodul-Objekt (in diesem Beispiel SubmoduleTestRepo genannt) in Ihrem Git-Repository. GitHub zeigt diese als "Submodul" -Objekte an. Oder über git submodule statuseine Befehlszeile. Git-Submodulobjekte sind spezielle Arten von Git-Objekten und enthalten die SHA-Informationen für ein bestimmtes Commit.

   Wann immer Sie a ausführen git submodule update, wird Ihr Submodul mit Inhalten aus dem Commit gefüllt. Es weiß aufgrund der Informationen in der, wo das Commit zu finden ist .gitmodules.

   Jetzt -bmüssen Sie nur noch eine Zeile in Ihre .gitmodulesDatei einfügen. Nach dem gleichen Beispiel würde es also so aussehen:

   [submodule "SubmoduleTestRepo"]
       path = SubmoduleTestRepo
       url = https://github.com/jzaccone/SubmoduleTestRepo.git
       branch = master
   

   Hinweis: In einer .gitmodulesDatei wird nur der Zweigname unterstützt , SHA und TAG jedoch nicht! (Stattdessen kann das Commit der Verzweigung für jedes Modul verfolgt und aktualisiert werden, indem "git add . , beispielsweise " git add ./SubmoduleTestRepo, und Sie müssen die .gitmodulesDatei nicht jedes Mal ändern. )

   Das Submodul-Objekt zeigt immer noch auf ein bestimmtes Commit. Das einzige, was die -bOption Ihnen kauft, ist die Möglichkeit, eine hinzuzufügen--remote , Ihrem Update Flag gemäß Vogellas Antwort hinzuzufügen:

   git submodule update --remote
   

   Anstatt den Inhalt des Submoduls mit dem Commit zu füllen, auf das das Submodul verweist, ersetzt es dieses Commit durch das letzte Commit im Master-Zweig. DANN wird das Submodul mit diesem Commit gefüllt. Dies kann in zwei Schritten durch die Antwort von djacobs7 erfolgen. Da Sie jetzt das Commit aktualisiert haben, auf das das Submodulobjekt zeigt, müssen Sie das geänderte Submodulobjekt in Ihr Git-Repository übertragen.

   git submodule add -bist keine magische Möglichkeit, mit einer Filiale alles auf dem neuesten Stand zu halten. Es fügt einfach Informationen zu einem Zweig in die .gitmodulesDatei ein und bietet Ihnen die Möglichkeit, das Submodulobjekt auf das neueste Commit eines angegebenen Zweigs zu aktualisieren, bevor Sie es füllen.

(Git 2.22, Q2 2019, wurde eingeführt git submodule set-branch --branch aBranch -- <submodule_path> )

Beachten Sie Folgendes : Wenn Sie ein vorhandenes Submodul haben, das noch keinen Zweig verfolgt , dann ( wenn Sie Git 1.8.2+ haben ):

• Stellen Sie sicher, dass das übergeordnete Repo weiß, dass sein Submodul jetzt einen Zweig verfolgt:

  cd /path/to/your/parent/repo
  git config -f .gitmodules submodule.<path>.branch <branch>
  

• Stellen Sie sicher, dass sich Ihr Submodul tatsächlich auf dem neuesten Stand dieses Zweigs befindet:

  cd path/to/your/submodule
  git checkout -b branch --track origin/branch
    # if the master branch already exist:
    git branch -u origin/master master
  

         (wobei 'origin' der Name des Upstream-Remote-Repos ist, von dem das Submodul geklont wurde.
         Ein git remote -vInnere dieses Submoduls zeigt es an. Normalerweise ist es 'origin')

• Vergessen Sie nicht, den neuen Status Ihres Submoduls in Ihrem Eltern-Repo aufzuzeichnen:

  cd /path/to/your/parent/repo
  git add path/to/your/submodule
  git commit -m "Make submodule tracking a branch"
  

• Bei der nachfolgenden Aktualisierung dieses Submoduls muss die folgende --remoteOption verwendet werden:

  # update your submodule
  # --remote will also fetch and ensure that
  # the latest commit from the branch is used
  git submodule update --remote
  
  # to avoid fetching use
  git submodule update --remote --no-fetch 
  

Beachten Sie, dass Sie mit Git 2.10+ (Q3 2016) ' .' als Filialnamen verwenden können :

Der Name der Niederlassung wird wie submodule.<name>.branchin .gitmodulesfür aufgezeichnet update --remote.
Ein spezieller Wert von .gibt an, dass der Name des Zweigs im Submodul mit dem Namen des aktuellen Zweigs im aktuellen Repository identisch sein soll .

Aber wie von LubosD kommentiert

Mit git checkout, wenn die Zweignamen zu folgen ist „ .“, wird sie Ihre uncommitted Arbeit töten!
Verwenden Sie git switchstattdessen.

Das bedeutet Git 2.23 (August 2019) oder mehr.

Siehe " Verwirrt vongit checkout "

Wenn Sie alle Ihre Submodule nach einem Zweig aktualisieren möchten:

    git submodule update --recursive --remote

Beachten Sie, dass das Ergebnis für jedes aktualisierte Submodul fast immer ein abgetrennter KOPF ist , wie Dan Cameron in seiner Antwort feststellt .

( Clintm merkt in den Kommentaren an, dass, wenn Sie ausführengit submodule update --remote und das resultierende sha1 mit dem Zweig identisch ist, in dem sich das Submodul gerade befindet, es nichts tut und das Submodul immer noch "in diesem Zweig" und nicht im Status "Abgelöst" bleibt. )

Um sicherzustellen, dass der Zweig tatsächlich ausgecheckt ist (und dadurch die SHA1 des speziellen Eintrags, der das Submodul für das übergeordnete Repo darstellt, nicht geändert wird), schlägt er vor:

git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; git switch $branch'

Jedes Submodul verweist weiterhin auf dasselbe SHA1. Wenn Sie jedoch neue Commits vornehmen, können Sie diese verschieben, da sie von dem Zweig referenziert werden, den das Submodul verfolgen soll.
Vergessen Sie nach diesem Push innerhalb eines Submoduls nicht, zum übergeordneten Repo zurückzukehren, den neuen SHA1 für diese modifizierten Submodule hinzuzufügen, festzuschreiben und zu pushen.

Beachten Sie die Verwendung von $toplevel, empfohlen in den Kommentaren von Alexander Pogrebnyak .
$toplevelwurde im Mai 2010 in git1.7.2 eingeführt: commit f030c96 .

Es enthält den absoluten Pfad des Verzeichnisses der obersten Ebene (wo .gitmodulesist).

dtmlandfügt in den Kommentaren hinzu :

Das foreach-Skript kann Submodule, die keinem Zweig folgen, nicht auschecken.
Dieser Befehl bietet Ihnen jedoch beide:

 git submodule foreach -q --recursive 'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; [ "$branch" = "" ] && git checkout master || git switch $branch' –

Der gleiche Befehl, aber leichter zu lesen:

git submodule foreach -q --recursive \
    'branch="$(git config -f $toplevel/.gitmodules submodule.$name.branch)"; \
     [ "$branch" = "" ] && \
     git checkout master || git switch $branch' –

umläute verfeinert den Befehl von dtmland mit einer vereinfachten Version in den Kommentaren :

git submodule foreach -q --recursive 'git switch $(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'

mehrere Zeilen:

git submodule foreach -q --recursive \
  'git switch \
  $(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'

Vor Git 2.26 (Q1 2020) erzeugt ein Abruf, der angewiesen wird, Aktualisierungen in Submodulen rekursiv abzurufen, zwangsläufig Unmengen von Ausgaben, und es wird schwierig, Fehlermeldungen zu erkennen.

Dem Befehl wurde beigebracht, Submodule aufzulisten, bei denen am Ende des Vorgangs Fehler aufgetreten sind .

Siehe Commit 0222540 (16. Januar 2020) von Emily Shaffer ( nasamuffin) .
^{(Zusammengeführt von Junio ​​C Hamano - gitster- in Commit b5c71cc , 05. Februar 2020)}

fetch: Fehler beim Abrufen des Submoduls hervorheben

^{Abgemeldet von: Emily Shaffer}

In Fällen, in denen ein Submodul-Abruf fehlschlägt, wenn viele Submodule vorhanden sind, wird der Fehler des einzelnen fehlgeschlagenen Submodul-Abrufs unter Aktivität auf den anderen Submodulen vergraben, wenn mehr als ein Abruf zurückfiel fetch-by-oid.
Rufen Sie einen Fehler zu spät auf, damit der Benutzer weiß, dass und wo etwas schief gelaufen ist .

Da fetch_finish()nur synchron durch run_processes_parallel,Mutexing aufgerufen wird, ist um nicht erforderlich submodules_with_errors.

Git 1.8.2 hat die Möglichkeit hinzugefügt, Zweige zu verfolgen.

# add submodule to track master branch
git submodule add -b branch_name URL_to_Git_repo optional_directory_rename

# update your submodule
git submodule update --remote 

Siehe auch Git-Submodule

Ein Beispiel, wie ich Git-Submodule verwende.

1. Erstellen Sie ein neues Repository
2. Klonen Sie dann ein anderes Repository als Submodul
3. Dann muss dieses Submodul ein Tag namens V3.1.2 verwenden
4. Und dann verpflichten wir uns.

Und das sieht ein bisschen so aus:

git init 
vi README
git add README
git commit 
git submodule add git://github.com/XXXXX/xxx.yyyy.git stm32_std_lib
git status

git submodule init
git submodule update

cd stm32_std_lib/
git reset --hard V3.1.2 
cd ..
git commit -a

git submodule status 

Vielleicht hilft es (obwohl ich ein Tag und keinen Zweig verwende)?

Nach meiner Erfahrung führen das Wechseln von Zweigen im Superprojekt oder zukünftige Checkouts immer noch zu getrennten HEADs von Submodulen, unabhängig davon, ob das Submodul ordnungsgemäß hinzugefügt und verfolgt wird (dh @ djacobs7- und @Johnny Z-Antworten).

Und anstatt den richtigen Zweig manuell oder über ein Skript manuell auszuchecken, kann das Submodul foreach verwendet werden.

Dadurch wird die Submodul-Konfigurationsdatei auf die Verzweigungseigenschaft überprüft und der festgelegte Zweig ausgecheckt.

git submodule foreach -q --recursive 'branch="$(git config -f <path>.gitmodules submodule.$name.branch)"; git checkout $branch'

Git-Submodule sind etwas seltsam - sie befinden sich immer im "Detached Head" -Modus - sie werden nicht wie erwartet auf das neueste Commit für einen Zweig aktualisiert.

Dies ist jedoch sinnvoll, wenn Sie darüber nachdenken. Sagen wir , ich Repository erstellen foo mit Submodul bar . Ich drücke meine Änderungen und fordere Sie auf, Commit a7402be aus dem Repository foo zu überprüfen .

Stellen Sie sich dann vor, dass jemand eine Änderung an der Repository- Leiste festlegt , bevor Sie Ihren Klon erstellen können.

Wenn Sie Commit a7402be aus dem Repository foo auschecken , erwarten Sie, dass Sie denselben Code erhalten, den ich gepusht habe. Aus diesem Grund werden Submodule erst aktualisiert, wenn Sie sie explizit anweisen und dann ein neues Commit durchführen.

Persönlich denke ich, dass Submodule der verwirrendste Teil von Git sind. Es gibt viele Orte, die Submodule besser erklären können als ich. Ich empfehle Pro Git von Scott Chacon.

So wechseln Sie den Zweig für ein Submodul (vorausgesetzt, Sie haben das Submodul bereits als Teil des Repositorys):

• cd zum Stammverzeichnis Ihres Repositorys mit den Submodulen
• .gitmodulesZum Bearbeiten öffnen
• Fügen Sie die folgende Zeile hinzu path = ...und url = ...das heißt branch = your-branch, für jedes Submodul; Datei speichern .gitmodules.
• dann ohne verzeichniswechsel zu tun $ git submodule update --remote

... dies sollte die neuesten Commits für den angegebenen Zweig für jedes so modifizierte Submodul abrufen.

Ich habe dies in meiner .gitconfig-Datei. Es ist noch ein Entwurf, hat sich aber ab sofort als nützlich erwiesen. Es hilft mir, die Submodule immer wieder an ihren Zweig anzuschließen.

[alias]

######################
#
#Submodules aliases
#
######################


#git sm-trackbranch : places all submodules on their respective branch specified in .gitmodules
#This works if submodules are configured to track a branch, i.e if .gitmodules looks like :
#[submodule "my-submodule"]
#   path = my-submodule
#   url = git@wherever.you.like/my-submodule.git
#   branch = my-branch
sm-trackbranch = "! git submodule foreach -q --recursive 'branch=\"$(git config -f $toplevel/.gitmodules submodule.$name.branch)\"; git checkout $branch'"

#sm-pullrebase :
# - pull --rebase on the master repo
# - sm-trackbranch on every submodule
# - pull --rebase on each submodule
#
# Important note :
#- have a clean master repo and subrepos before doing this !
#- this is *not* equivalent to getting the last committed 
#  master repo + its submodules: if some submodules are tracking branches 
#  that have evolved since the last commit in the master repo,
#  they will be using those more recent commits !
#
#  (Note : On the contrary, git submodule update will stick 
#to the last committed SHA1 in the master repo)
#
sm-pullrebase = "! git pull --rebase; git submodule update; git sm-trackbranch ; git submodule foreach 'git pull --rebase' "

# git sm-diff will diff the master repo *and* its submodules
sm-diff = "! git diff && git submodule foreach 'git diff' "

#git sm-push will ask to push also submodules
sm-push = push --recurse-submodules=on-demand

#git alias : list all aliases
#useful in order to learn git syntax
alias = "!git config -l | grep alias | cut -c 7-"

Wir verwenden Quack , um ein bestimmtes Modul aus einem anderen Git-Repository abzurufen. Wir müssen Code ohne die gesamte Codebasis des bereitgestellten Repositorys abrufen - wir benötigen ein sehr spezifisches Modul / eine sehr spezifische Datei aus diesem riesigen Repository und sollten jedes Mal aktualisiert werden, wenn wir ein Update ausführen.

So haben wir es erreicht:

Konfiguration erstellen

name: Project Name

modules:
  local/path:
    repository: https://github.com/<username>/<repo>.git
    path: repo/path
    branch: dev
  other/local/path/filename.txt:
    repository: https://github.com/<username>/<repo>.git
    hexsha: 9e3e9642cfea36f4ae216d27df100134920143b9
    path: repo/path/filename.txt

profiles:
  init:
    tasks: ['modules']

Mit der obigen Konfiguration wird ein Verzeichnis aus dem bereitgestellten GitHub-Repository erstellt, wie in der ersten Modulkonfiguration angegeben, und das andere besteht darin, eine Datei aus dem angegebenen Repository abzurufen und zu erstellen.

Andere Entwickler müssen nur laufen

$ quack

Und es zieht den Code aus den obigen Konfigurationen.

Die einzige Auswirkung der Auswahl eines Zweigs für ein Submodul besteht darin, dass Sie immer dann, wenn Sie das übergeben --remote Option Option ingit submodule update Git Befehlszeile übergeben, im getrennten HEAD- Modus (wenn das Standardverhalten --checkoutausgewählt ist) das letzte Commit dieses ausgewählten Remote- Zweigs auscheckt .

Sie müssen besonders vorsichtig sein, wenn Sie diese Remote Branch Branch-Funktion für Git-Submodule verwenden, wenn Sie mit flachen Klonen von Submodulen arbeiten. Der Zweig, den Sie zu diesem Zweck in den Einstellungen des Submoduls auswählen , wird NICHT während dieser Zeit geklont git submodule update --remote. Wenn Sie auch den --depthParameter übergeben und Git nicht anweisen, welchen Zweig Sie klonen möchten - und das können Sie eigentlich nicht in dergit submodule update Befehlszeile !! - verhält es sich implizit wie in der git-clone(1)Dokumentation erläutert, git clone --single-branchwenn der explizite --branchParameter fehlt, und klont daher nur den primären Zweig .

Kein Wunder, dass nach der Klonphase von der git submodule update Befehl ausgeführten Klonphase endlich versucht wird, das letzte Commit für den Remote- Zweig zu überprüfen, den Sie zuvor für das Submodul eingerichtet haben. Wenn dies nicht der primäre Zweig ist, ist er nicht Teil von Ihr lokaler flacher Klon, und daher wird es mit scheitern

tödlich: Benötigte eine einzige Revision

Der aktuelle Ursprung / die NotThePrimaryBranch- Revision im Submodulpfad 'mySubmodule' konnte nicht gefunden werden.

Git-Submodul add -b Develop - Name Branch-Name - https: //branch.git