Gibt es einen Standard für die Verwendung von Versions-Tags in Monorepos? Ist etwas in der Art von 1.0.0-myapp1und 2.1.0-myapp2 akzeptabel? Oder gibt es eine andere Möglichkeit, Versionen zwischen Anwendungen zu unterscheiden?
Konventionen für Monorepo-Versions-Tags
Lesezeit: 1 Minute
10127800cookie-checkKonventionen für Monorepo-Versions-Tags
LeGEC
tags sind in Verzeichnissen und Dateien organisiert (alle Git-Referenzen sind run tree .git/refs/tags um das zu sehen), also würde ich vorschlagen, die Tags zu benennen:
myapp1/1.0.0
myapp1/1.0.1
...
myapp2/2.1.0
myapp2/2.2.0
...
Dadurch werden Versionen für jede App zusammen gruppiert, und einige Befehle behandeln die Zahlen “natürlich” :
# list tags, sorted by version number :
$ git tag --list --sort="version:refname"
myapp1/1.0.2
myapp1/1.0.10
myapp1/2.0.0
myapp1/10.0.0
myapp2/1.0.0
myapp2/2.0.0
myapp2/11.0.0
Wenn Sie vermeiden möchten, dass die “Tags für myapp2” angezeigt werden, wenn Sie das Protokoll für myapp1 untersuchen, können Sie verwenden --decorate-refs=<pattern> :
# this will include tags starting with 'myapp1', and all branches :
$ git log --oneline --graph --decorate-refs=refs/tags/myapp1 --decorate-refs=refs/heads
Wenn Sie dies regelmäßig benötigen, können Sie einen Alias dafür hinzufügen:
$ git config alias.logmyapp1 log --decorate-...
Ein Tag entspricht einem Commit, das wiederum dem gesamten Repo entspricht. Es ist also nicht klar, was es bedeuten würde, a zu markieren Mono-repo basierend auf den Namen der einzelnen Komponenten.
– Oliver Charlesworth
15. November 2017 um 19:52 Uhr
Wenn jede App eine andere Version benötigt, ist das ein gutes Zeichen dafür, dass Sie für jede App ein Repo benötigen. Ich würde entweder ein einzelnes Versionsschema für dieses Repo verwenden oder das Repo für jede App aufteilen.
– Gonzalo Matheu
15. November 2017 um 20:12 Uhr