Ausführliche Erklärung des Repos

Repo verwendet

1. Repo-Einführung

Android verwendet Git als Codeverwaltungstool und hat Gerrit für die Codeüberprüfung entwickelt, um den Code zentralisiert besser verwalten zu können. Außerdem wurde das Repo- Befehlszeilentool entwickelt, das einige Git- Befehle kapselt und mehr als 100 Git- Repositorys effektiv organisiert .

1.1 Einführung in die Manifest-Bibliotheksdatei

Ein Manifest-Repository kann mehrere Manifestdateien und mehrere Zweige enthalten, und jede Manifestdatei und jeder Zweig verfügt über eine entsprechende Version. Manifestdateien sind im XML-Format organisiert. Zum Beispiel:

Das Remote-Element definiert ein Remote-Repository namens korg, dessen Basisadresse git://172.16.1.31/ ist.
Das Standardelement legt das Standard-Remote-Repository für jedes Projekt auf Korg fest, und der Standardzweig ist Gingerbread-Exdroid-Stable. Natürlich kann jedes Projekt (Projektelement) auch seine eigene Fernbedienung und Revision definieren, um die Standardkonfiguration zu überschreiben.
Das Projektelement wird zum Definieren eines Projekts verwendet, das Pfadattribut gibt den Klonspeicherort im Arbeitsbereich an und das Namensattribut gibt den relativen Pfad des Remote-Repositorys des Projekts an.
Das Unterelement copyfile des Projektelements definiert eine Anhangsaktion nach dem Klonen des Projekts und kopiert die Datei von src nach dest.

1.2 Laden Sie den Repo-Code herunter

$mkdir android2.3.4
$cd android2.3.4
$git clone git://172.16.1.31/repo.git

Es gibt also einen Repo-Ordner im Android-Verzeichnis, der den Quellcode von Repo enthält, und darin ein Repo-Skript, mit dem der Repo-Befehl ausgeführt wird.

Benutzer, die lokal entwickeln, müssen den Repo-Code herunterladen, und Benutzer, die auf dem 172.16.1.7-Server entwickeln, müssen den Repo-Code nicht herunterladen, da das Repo-Skript zur Umgebungsvariablen hinzugefügt wurde und die Repo-Initialisierung zusätzlich den Repo-Code herunterlädt Repo-Code.

2. Allgemeine Repo-Befehle

Anmerkungen: „*“ kennzeichnet einen neu hinzugefügten Befehl

2.1 Repo-Init (Repo herunterladen und Manifest klonen)

Verwendung:

repo init –u URL [OPTIONS]

Optionen:

-u: Gibt eine URL an, die eine Verbindung zu einem Maniest-Repository herstellt.
-m: Wählen Sie eine XML-Datei im Manifest-Repository aus.
-b: Wählen Sie einen bestimmten Zweig in einem der größten Repositorys aus.

Der Befehl repo init sollte die folgenden Vorgänge ausführen:

Schließen Sie den vollständigen Download des Repo-Tools ab. Das ausgeführte Repo-Skript ist lediglich der Bootloader
Manifestbibliothek manifest.git klonen (Adresse stammt vom Parameter -u)
Das geklonte Manifest-Repository befindet sich in manifest.git und ist lokal nach .repo/manifests geklont. manifest.repo/manifest.xml ist lediglich ein Symlink, der auf .repo/manifests/default.xml verweist
Wenn die Manifeste mehrere XML-Dateien enthalten, kann Repo-Init eine davon willkürlich auswählen, und die Standardauswahl ist default.xml

Beispiel:

repo init  -u git://172.16.1.31/manifest.git

Der Ordner .repo erscheint im Verzeichnis android2.3.4

repo  init  -u git://172.16.1.31/manifest.git –m android.xml

Die Konfiguration in android.xml ist ausgewählt und .repo/manifest.xml verweist auf .repo/manifests/android.xml.

2.2 Repo- Synchronisierung (Download-Code)

Verwendung:

repo sync [<project>…]

Es wird zum Klonen und Synchronisieren des Repositorys mit Bezug auf die Manifestdatei .repo/manifest.xml verwendet. Wenn noch kein Projekt-Repository vorhanden ist, entspricht die Ausführung des Befehls „repo sync“ der Ausführung von „git clone“. Wenn das Projekt-Repository bereits vorhanden ist, entspricht dies der Ausführung der folgenden beiden Anweisungen:

git remote update
entspricht der Durchführung eines Abrufvorgangs für jede Remote-Quelle
git rebase origin/branch
führt einen Rebase-Vorgang für den Tracking-Zweig des aktuellen Zweigs durch.

Beispiel:

repo sync

Es besteht auch die Möglichkeit, eines der Projekte zu klonen:

repo sync platform/build

2.3 Repo-Start (Zweige erstellen und wechseln)

Verwendung:

repo start  <newbranchname> [--all | <project>…]

Der neu geklonte Code hat keine Verzweigungen und der Repo-Start ist eigentlich die Kapselung des Befehls git checkout –b. Erstellen Sie für das angegebene Projekt oder alle Projekte (wenn der Parameter --all verwendet wird) einen Feature-Zweig unter Verwendung des in der Manifestdatei angegebenen Zweigs. Diese Anweisung unterscheidet sich deutlich von git checkout –b. git checkout –b erstellt einen Feature-Branch basierend auf dem aktuellen Branch, während repo start einen Feature-Branch basierend auf dem Branch-Set in der Manifestdatei erstellt.

Beispiel:

repo start  stable  --all

Unter der Annahme, dass der in der Manifestdatei festgelegte Zweig Gingerbread-Exdroid-Stable ist, besteht die Ausführung des obigen Befehls darin, für alle Projekte einen Feature-Zweig Stable auf der Basis von Gingerbread-Exdroid-Stable zu erstellen.

repo start  stable  platform/build platform/bionic

Unter der Annahme, dass der in der Manifestdatei festgelegte Zweig „gingerbread-exdroid-stable“ ist, besteht die Ausführung des obigen Befehls darin, den Feature-Zweig „stable“ auf der Grundlage von „gingerbread-exdroid-stable“ für die Projekte „platform/build“ und „platform/bionic“ zu erstellen.

2.4 Repo-Checkout (Zweig wechseln)

Verwendung:

repo checkout <branchname>  [<project>…]

Es handelt sich tatsächlich um eine Kapselung des Befehls git checkout, der Parameter -b kann jedoch nicht verwendet werden, sodass dieser Befehl nicht zum Erstellen eines Feature-Zweigs verwendet werden kann.

Beispiel:

repo checkout crane-dev 
repo checkout crane-dev  platform/build  platform/bionic

2,5 Repo-Zweige (Zweig anzeigen)

Verwendung:

repo branches [<project>…]

Beispiel:

repo branches 
repo branches platform/build platform/bionic

2.6 Repo-Diff (Unterschiede zwischen Arbeitsbereichsdateien anzeigen)

Verwendung:

repo diff [<project>…]

Tatsächlich handelt es sich um die Kapselung des Befehls git diff, mit der die Dateiunterschiede im Arbeitsbereich jedes Projekts angezeigt werden.

Beispiel:

repo diff                                 ---查看所有项目
repo diff platform/build platform/bionic  ---只查看其中两个项目

2.7 Repo-Phase (Dateien zur Indextabelle hinzufügen)

Tatsächlich handelt es sich um eine Kapselung des Befehls git add –interactive, mit dem Änderungen im Arbeitsbereich jedes Projekts ausgewählt werden, um sie dem temporären Speicherbereich hinzuzufügen.

Verwendung:

repo stage -i [<project>…]

-i steht im Befehl git add –interactive für –interactive und gibt dem Benutzer eine Schnittstelle zur Auswahl.

2.8 Repo Prune (zusammengeführte Zweige löschen)

Tatsächlich handelt es sich um eine Kapselung des Befehls git branch –d, mit dem die verschiedenen Zweige des Projekts gescannt und die zusammengeführten Zweige gelöscht werden. Die Verwendung ist wie folgt:

repo prune [<project>…]

2.9 Repo-Abbruch (den angegebenen Zweig löschen)

Tatsächlich handelt es sich um eine Kapselung des Befehls git branch –D, und seine Verwendung ist wie folgt:

repo abandon <branchname> [<project>…]

2.10 Repo-Status (Dateistatus anzeigen)

Tatsächlich handelt es sich um eine Kapselung der Befehle git diff-index und git diff-filse und zeigt gleichzeitig den Status des temporären Speicherbereichs und den Status lokaler Dateiänderungen an

$repo/repo status platform/bionic

Das Repo verwendet
die obige Beispielausgabe, um den Änderungsstatus des Plattform-/Bionic-Projektzweigs anzuzeigen

Die erste Zeile jedes Unterabschnitts zeigt den Namen des Envy und den Namen des Zweigs, in dem er sich befindet
Der erste Buchstabe gibt den Dateiänderungsstatus des temporären Speicherbereichs an
- -:Keine Änderung
- A: Hinzufügen (nicht im HEAD, im temporären Speicherbereich)
- M: Ändern (in HEAD, im Staging-Bereich, ist der Inhalt anders)
- D: Löschen (im HEAD, nicht im temporären Speicherbereich)
- R: umbenennen (nicht in HEAD, im Staging-Bereich, Pfadänderung)
- C: kopieren (nicht im HEAD, im temporären Speicherbereich, aus anderen Dateien kopieren)
- T: Der Dateistatus hat sich geändert (in HEAD, im Staging-Bereich, ist der Inhalt derselbe)
- U: Nicht zusammengeführt, erfordert Konfliktlösung
Der zweite Buchstabe gibt den geänderten Status der Arbeitsbereichsdatei an
- -: neu/unbekannt (nicht im Bereitstellungsbereich, sondern im Arbeitsbereich)
- m: ändern (im temporären Speicherbereich, im Arbeitsbereich, geändert)
- d: Löschen (im temporären Speicherbereich, nicht im Arbeitsbereich)
Nach den beiden Buchstaben, die den Status angeben, werden die Informationen zum Dateinamen angezeigt. Wenn eine Datei mit demselben Namen vorhanden ist, werden auch der Dateiname vor und nach der Änderung sowie die Ähnlichkeit der Datei angezeigt

2.11 Repo Remote (Remote-Warehouse festlegen)

Verwendung:

repo remote add <remotename>  <url> [<project>…] 
repo remote rm <remotename>  [<project>…]

Beispiel:

repo remote add org ssh://172.16.1.31/git_repo

Bei dieser Anweisung handelt es sich um einen Remote-Zweig, der gemäß der XML-Datei hinzugefügt wird, was zum Senden von Code an den Server praktisch ist. Nach der Ausführung können Sie die neue Remote-Zweigorganisation im Build-Verzeichnis sehen:

Repo verwendet zum Löschen des Remote-Warehouse:

$repo  remote  rm  org

2.12 Repo-Push

repo push org

Dies ist eine neu hinzugefügte Anweisung zum Senden von Code an den Server mit der folgenden Methode:

repo push <remotename> [--all |<project>…]

Repo fragt die Elemente ab, die an den Server übermittelt werden müssen, und fordert den Benutzer dazu auf.

2.13 Repo insgesamt

Verwendung:

repo forall [<project>…] –c <command>

Iterator, kann in allen angegebenen Projekten den gleichen Shell-Befehl ausführen

Optionen:
- -c: Die folgenden Parameter sind Shell-Befehle
- -p: Listen Sie den Projektnamen vor der Ausgabe des Shell-Befehls auf.
- -v: Listen Sie die Fehlerinformationen auf, die durch die Ausführung des Shell-Befehls ausgegeben werden.
Zusätzliche Umgebungsvariablen:
- REPO_PROJECT: Geben Sie die an Projekt -
REPO_PATH: Geben Sie den relativen Pfad des Projekts im Arbeitsbereich an.
- REPO_REMOTE: Geben Sie den Namen des Remote-Warehouses des Projekts an.
- REPO_LREV: Geben Sie den Hash-Wert an, der der letzten Übermittlung des Projekts an das Server-Warehouse entspricht.
- REPO_RREV: Geben Sie an Der angegebene Zweig des Projekts beim Klonen, Manifest Das Revisionsattribut in

Wenn der Shell-Befehl nach -c die oben genannten Umgebungsvariablen enthält, müssen Sie den Shell-Befehl außerdem in einfache Anführungszeichen setzen.

2.13.1 Umgebungsvariablen hinzugefügt

repo forall –c ‘echo $REPO_PROJECT’
repo forall  –c ‘echo $REPO_PATH’

2.13.2 Zusammenführen (mehrere Zweige zusammenführen)

Wechseln Sie alle Projekte zum Hauptzweig und führen Sie die folgenden Anweisungen aus, um den Themenzweig mit dem Hauptzweig zusammenzuführen

repo forall –p –c git merge topic

2.13.3 Tag (Tagging)

Beschriften Sie alle Projekte

repo forall –c git tag crane-stable-1.6

2.13.4 Remote (Remote-Warehouse festlegen)

Verweisen Sie auf die Umgebungsvariable REPO_PROJECT, um ein Remote-Warehouse hinzuzufügen:

repo forall –c ‘git remote add korg sh://[email protected]/$REPO_PROJECT.git’

Löschen Sie das Remote-Repository:

repo forall –c git remote add korg

2.13.5 Zweig (einen Feature-Zweig erstellen)

repo forall –c git branch crane-dev
repo forall –c git checkout –b crane-dev

3. Zusätzlicher Befehlssatz für Repo

3.1 Repo grep

Entspricht der Kapselung von Git Grep und wird zum Suchen nach Inhalten in Projektdateien verwendet

3.2 Repo-Manifest

Inhalt der Manifestdatei
anzeigen

repo manifest –o android.xml

3.3 Repo-Version

Zeigt die Versionsnummer des Repos an

3.4 Repo-Upload

Repo-Upload entspricht Git-Push, es gibt jedoch große Unterschiede. Beim Klonen werden die Änderungen der Versionsbibliothek nicht an den Remote-Server übertragen, sondern mithilfe des SSH-Protokolls an die spezielle Referenz des Codeüberprüfungsservers (Gerrit-Software-Setup). Der Codeüberprüfungsserver führt eine spezielle Verarbeitung der gepushten Übermittlung durch, zeigt die neue Übermittlung als zu überprüfenden Änderungssatz an und startet den Codeüberprüfungsprozess. Erst nachdem die Überprüfung bestanden wurde, wird sie in das offizielle Repository zusammengeführt.

Da Allwinner über keinen Code-Review-Server verfügt, kann dieser Befehl nicht verwendet werden.

Verwendung:

repo upload [--re --cc] {
    
    [<project>]… | --replace <project>}

Optionen:

-h, --help: Hilfeinformationen anzeigen
-t: Senden Sie den lokalen Filialnamen an den Gerrit-Codeüberprüfungsserver
--replace: Senden Sie ein aktualisiertes Patchset für diesen Zweig
–re=REVIEWERS: Bitten Sie die angegebenen Personen um eine Bewertung
–cc=CC: Benachrichtigungen gleichzeitig an die folgenden E-Mail-Adressen senden

3.5 Repo-Download

Wird hauptsächlich von Codeprüfern verwendet, um von Mitwirkenden eingereichte Revisionen herunterzuladen und zu bewerten
.

repo download {
    
    project change [patchset]}…

3.6 Repo-Selbstaktualisierung

Für die Aktualisierung des Repos selbst
Referenz: http://wenku.baidu.com/view/672c8faddd3383c4bb4cd257.html

4. Remote-Befehl hinzugefügt

Fügen Sie remote.py in sumcmds hinzu. Die Vorgehensweise ist wie folgt:

# Copyright (C) 2009 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

import sys
from color import Coloring
from command import Command
from progress import Progress

class Remote(Command):
  common = True
  helpSummary = "View current topic branches"
  helpUsage = """
       %prog add <remotebranchname> <url> [<project>...]
       %prog rm  <remotebranchname> [<project>...]
       --------------
              """
  def str_last(self ,string):
     for c in string:
         last=c
     return last

  def Execute(self, opt, args):
    if not args:
      print >>sys.stderr, "error:..........wrong command........"
      print >>sys.stderr, "Usage:repo remote add <remotebranchname> <url> [<project>...]"
      print >>sys.stderr, "      repo remote rm  <remotebranchname> [<project>...] "          
      print >>sys.stderr, "................................"
      return

    err = []
    operate=args[0]
    #url = args[2]
    #branch_name=args[1]
    if operate == "rm":
       if not len(args) >=2:
         print >>sys.stderr, "error:miss remotebrancname"
         return

       branch_name=args[1]
       projects = args[2:]
    elif operate == "add":
       if not len(args) >=3:
         print >>sys.stderr, "error:miss remotebranchname or url"
         return

       branch_name=args[1]
       projects = args[3:]
    else:
       print >>sys.stderr, "error: the operand is add or rm "
       return

    all = self.GetProjects(projects)
    #print >>sys.stderr, all
    pm = Progress('remote %s' % operate, len(all))
    for project in all:
       if operate == "add":
          if self.str_last(args[2])=="/":
             url = args[2]+project.name+'.git'
          else :
             url = args[2]+'/'+project.name+'.git'
       else:
         url = ""

       pm.update() 
       if not project.Remote(operate,branch_name,url):
         err.append(project)
    pm.end()

    if err:
      if len(err) == len(all):
        print >>sys.stderr, 'error: no project remote  %s %s' % (operate,branch_name)  
      else:
        for p in err:
          print >>sys.stderr,\
            "error: %s/: cannot remote %s %s " \
            % (p.relpath, operate,branch_name)
      sys.exit(1)

在preject.py中添加Remote（operate,branch_name,url）方法：
   def Remote(self,operate,branch_name,url):
     """Prune  topic branches already merged into upstream.
     """
     if url=="":   #rm
       return GitCommand(self,
                         ['remote', operate, branch_name],
                         capture_stdout = True,
capture_stderr = True).Wait() == 0

     else:  #add
       return GitCommand(self,
                         ['remote', operate, branch_name,url],
                         capture_stdout = True,
                         capture_stderr = True).Wait() == 0

5. Push-Befehl hinzufügen

Fügen Sie push.py in subcmds hinzu. Der Code lautet wie folgt:

#
# Copyright (C) 2010 [email protected]
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

import copy
import re
import sys
from command import InteractiveCommand
from editor import Editor
from error import UploadError, GitError
from project import ReviewableBranch

def _ConfirmManyUploads(multiple_branches=False):
  if multiple_branches:
    print "ATTENTION: One or more branches has an unusually high number of commits."
  else:
    print "ATTENTION: You are uploading an unusually high number of commits."
  print "YOU PROBABLY DO NOT MEAN TO DO THIS. (Did you rebase across branches?)"
  answer = raw_input("If you are sure you intend to do this, type 'yes': ").strip()
  return answer == "yes"

def _die(fmt, *args):
  msg = fmt % args
  print >>sys.stderr, 'error: %s' % msg
  sys.exit(1)

def _SplitEmails(values):
  result = []
  for str in values:
    result.extend([s.strip() for s in str.split(',')])
  return result

class Push(InteractiveCommand):
  common = True
  helpSummary = "Upload changes for code review"