Git-Alias, der für „main“ oder „master“ oder andere funktioniert

Lesezeit: 9 Minuten

Benutzeravatar von Thymine
Thymin

Wie kann ich bei der Vielzahl der Standard-Branch-Optionen in Git ein Skript/einen Alias ​​schreiben, das unabhängig vom Namen auf den Standard-Branch verweist?

Mein spezifisches Beispiel ist mein Alias, der auf den neuesten Remote-Master rebasiert:

### version for `master`
#   rebaseOn = "!f() { BRANCH=$(git symbolic-ref --short HEAD) && git fetch && git pull --rebase; git rebase origin/${1:-master}; }; f"
### version for `main`
    rebaseOn = "!f() { BRANCH=$(git symbolic-ref --short HEAD) && git fetch && git pull --rebase; git rebase origin/${1:-main}; }; f"

Verwendungszweck: git rebaseOn oder git rebaseOn newParentBranch (weil es die Eingabe zurücksetzt ${1:-main})

Ich möchte, dass dieser Befehl dort für beide Versionen funktioniert, da verschiedene Repositories, mit denen ich arbeite, vorhanden sind main oder master oder default oder trunk


Bisher habe ich https://stackoverflow.com/a/50056710/356218 gefunden: git remote show upstream | grep "HEAD branch" | sed 's/.*: //' aber das ist ziemlich lang für das Einfügen in einen Alias.

Gibt es eine bessere Option als das?


Beste Antwort bisher

Wiederhole die derzeit beste Antwort in meinen eigenen Worten:

@matt schlägt vor, zu verwenden git branch --set-upstream-to:

  • Ich nehme an, Sie setzen git branch --set-upstream-to <main/master> wenn Sie ein Repo zum ersten Mal klonen, und führen Sie diesen Befehl sehr konsequent mit jedem Repo aus, das Sie berühren
  • Dann können Sie ignorieren, was github oder so sagt, ist der Standard-Master, und wissen, dass Sie es in diesem Setup von Ihnen sind stets Verwenden Sie Ihre Präferenz lokal
    • Im Gegensatz zu Paarprogrammierung oder irgendetwas anderem, bei dem Sie auf Standardverhalten zurückgreifen müssen
  • Dann vor dem Umbasieren auf defaultdu musst pull Ihre Wahl des Namens (skripten Sie dies), damit alle neuen Commits vor dem Rebase eingeschlossen werden
    • Wenn Sie also einen Zweig verwenden, um parallel zu etwas anderem zu arbeiten, an dem Sie arbeiten default Sie können das mit dieser Methode nicht wirklich tun, benötigen immer einen separaten Zweig für Commits, die noch nicht zum Pushen bereit sind
  • Dann können Sie in verschmelzen default und ohne Mehrarbeit schieben

Das Zusammenführen funktioniert wahrscheinlich etwas besser (wie es immer bei Git der Fall ist).

Beachten Sie das real Frustration ist, wenn ein Repo sowohl a master und main Zweig, und es ist schwierig, sich zu merken/zu wissen/zu entdecken, welcher der primäre über die CLI ist (muss git log und schauen Sie sich Daten an, erinnern Sie sich an ziemlich obskure Befehle oder überprüfen Sie github. All dies dauert länger als 2 Sekunden und ein Kontextwechsel, um eine Vorstellung vom Grad der Frustration zu geben.)

  • Verwenden Sie keinen Alias, erstellen Sie einfach git-rebaseOn bash-Skript und Sie können es mit aufrufen git rebaseOn

    – Ôrel

    16. Februar 2021 um 23:51 Uhr

  • Könnten Sie das überdenken? Der Name des Zweigs ist nichts Besonderes, warum ändern Sie ihn also nicht einfach in master oder main oder welchen konsistenten Namen Sie auch immer mögen, örtlichbeim Verlassen der Fernbedienung Tracking-Zweig mit dem richtigen Zweig auf der Fernbedienung verbunden? Es gibt kein Gesetz, das besagt, dass Ihr lokaler Name mit dem entfernten Namen übereinstimmen muss, wissen Sie.

    – matt

    17. Februar 2021 um 3:36 Uhr


  • @matt, ja, es gibt nichts, was das sagt, aber ich habe das Gefühl, dass Sie die Schwierigkeit nur an eine andere Stelle verschieben. Anstatt also wissen zu müssen, wann ich rebasiere oder auf andere Weise, muss ich wissen, dass ich das einrichten muss beim ersten Klon? Ich möchte, dass das Problem automatisiert wird, da dies einfach zu bewerkstelligen sein sollte, nicht nur eine andere manuelle Aktion, die es in den üblichen Fällen unterstützt

    – Thymin

    17. Februar 2021 um 18:39 Uhr

  • “Ich muss wissen, dass ich das beim ersten Klon einrichten muss.” Sie müssen nichts wissen. Es gibt wirklich keinen “Standardzweig”. Wenn Sie einen Klon erstellen und Ihnen der Name des primären Zweigs nicht gefällt, ändern Sie ihn einfach lokal in das, was Ihnen gefällt. Dieser Teil erfordert Denken. Aber jetzt ist das Problem automatisiert, weil Sie den Namen des primären Zweigs kennen: Es ist der Name, den Sie immer verwenden. 🙂

    – matt

    17. Februar 2021 um 18:41 Uhr


Benutzeravatar von jtompl
jtompl

Als Fortsetzung des großartigen Kommentars von @torek können Sie Ihre Aliase so festlegen:

main-branch = !git symbolic-ref refs/remotes/origin/HEAD | cut -d"https://stackoverflow.com/" -f4
remotesh = remote set-head origin --auto
com = "!f(){ git checkout $(git main-branch) [email protected];}; f"
upm = "!f(){ git pull --rebase --autostash origin $(git main-branch) [email protected];}; f"
rebasem = "!f(){ git rebase -i --autosquash origin/$(git main-branch) --no-verify [email protected];}; f"

git main-branch gibt den Namen des aktuellen “Haupt”-Zweigs (main/master) zurück.

In anderen Aliasnamen verwenden $(git main-branch) statt fest codiert master Zweigname. Denken Sie nur daran, dass es sich um ein Shell-Skript handeln muss (das mit !) so, dass die $(git main-branch) tatsächlich interpoliert wird.

Wenn einer der Alias-Fehler mit fatal: ref refs/remotes/origin/HEAD is not a symbolic refdann einfach ausführen git remotesh .

  • Was ist git remotsh? Es funktioniert auf meinem System nicht und ich kann online keine Dokumentation finden.

    – Martin JH

    27. März um 19:51 Uhr

  • Ein Alias, der durch die in der Antwort erwähnte Konfiguration hinzugefügt wird.

    – jtompl

    28. März um 14:11 Uhr

Hier haben Sie zahlreiche Möglichkeiten. Ich würde dir aber die Verwendung empfehlen keiner von denen, die ich hier aufliste, weil dein Filialnamen sind deine. Es gibt keinen Grund, dass Sie die gleichen Namen wie bei anderen Repositorys verwenden müssen. Das suggeriert Matt auch in einem Kommentar.

Ihre Optionen umfassen jedoch:

  • Lesen origin/HEAD in Ihrem eigenen Repository.

    repo-A$ git symbolic-ref refs/remotes/origin/HEAD
    refs/remotes/origin/master
    
    repo-B$ git symbolic-ref refs/remotes/origin/HEAD
    refs/remotes/origin/main
    

    wobei repo-A ein Klon eines älteren Repositorys ist, das verwendet master und repo-B ist ein Klon eines neueren Repositorys, das verwendet mainzum Beispiel.

    Beachten Sie, dass Sie gelegentlich laufen müssen git remote set-head --auto um Ihr Git dazu zu bringen, das zu bemerken ihr Git wurde umbenannt master zu main und damit Ihre zu aktualisieren origin/HEAD passen. Dein origin/HEAD wird beim Laufen aufgebaut git clone und danach nicht aktualisiert, es sei denn, Sie verwenden git remote set-head --auto. Das könntest du natürlich stellen git remote set-head Operation in Ihren Alias.

  • Verwenden git remote show, so wie du es gezeigt hast. Es ist in einem Alias: Warum interessiert es Sie, wie lang der Alias ​​ist?

  • Verwenden Sie die Upstream-Einstellung (git branch --set-upstream-to) und dann einfach laufen git rebase, um den Upstream des aktuellen Zweigs auszuwählen. Das wird natürlich meistens sein origin/name für Filiale name; Vermutlich verwenden Sie diesen Alias, wenn Sie Ihre aktualisieren möchten name vor einem erzwungenen Push, um den benannten Zweig zu aktualisieren name vorbei origin. Wenn ja, ist diese Option eine schlechte.

  • Schreiben Sie ein Drehbuch. Legen Sie das Skript in Ihre $PATH irgendwo, es benennen git-rebase-on-default-branch zum Beispiel. Betrieb git rebase-on-default-branch wird Ihr Skript ausführen. Jetzt, da es kein Alias, sondern ein Skript ist – in jeder beliebigen Sprache –, können Sie so viel Code einfügen, wie Sie möchten, und es so clever und ausgefallen gestalten, wie Sie möchten. (Das ist, wie ich sehe, auch Ôrels Vorschlag.)

Es gibt zweifellos mehr, aber dies sollte zumindest einige der Grundlagen abdecken.

  • Danke für eine gut durchdachte Antwort. Ich interessiere mich für die Länge des Teils des Alias, den ich mithilfe der Logik in andere Aliase kopieren/einfügen müsste, damit das ausführbare Skript besser ist (obwohl es wieder nur auf meinem Betriebssystem und Setup funktioniert). Ich verstehe das wirklich nicht git Denkweise hier, kommunizierst du nicht eng mit anderen Menschen, oder du bist in Ordnung mit der Ebene der Abstraktion, die für deine Umgebung völlig einzigartig ist, und das ist in Ordnung mit der mentalen Gymnastik, um das zu wissen auf meiner Maschine es ist master still. Es ist geringfügig, kommt aber Dutzende Male am Tag vor

    – Thymin

    17. Februar 2021 um 18:46 Uhr

  • @Thymine: Sobald Sie anfangen, komplizierte Dinge zu tun, z. B. drei oder vier Fernbedienungen zu verwenden, haben Sie keine Möglichkeit mehr, Ihren Zweig genauso zu benennen wie ihren Zweig, da es drei oder vier verschiedene entfernte foo / master-s gibt. Man gewöhnt sich also daran, dass die Namen nicht mehr übereinstimmen. (Für einfachere Fälle tendiere ich dazu, meine genauso zu benennen wie ihre, aber in diesem speziellen Fall kümmere ich mich einfach nicht um a master / main überhaupt, und verwenden origin/whatever direkt. Bisher war das kein Problem.)

    – Torek

    18. Februar 2021 um 2:13 Uhr


  • Ich vergesse Gabeln und so, da immer nur das Unternehmen Enterprise GitHub als einzige Fernbedienung hat, also ist das viel verständlicher. Mein Gedanke ist GUI für den Sieg (sehen der vollständige Kontext, aus dem Sie auswählen), aber Git fehlt es auch die meiste Zeit an vollwertigen GUIs 🙂 Danke für die Erbauung Ihres Workflows!

    – Thymin

    18. Februar 2021 um 18:57 Uhr


Benutzeravatar von Martin Tournoij
Martin Tournij

Ich habe es mit einem „git“-Wrapper gelöst, der „main“ in „master“ (oder umgekehrt, abhängig vom Standard-Branch-Namen) in den Befehlsargumenten umschreibt, bevor git aufgerufen wird.

Fügen Sie dies Ihrem PATH irgendwo vor dem eigentlichen hinzu git Befehl, zum Beispiel /usr/local/bin, ~/bin, ~/.local/bin, oder was auch immer auf Ihrem System sinnvoll ist. Denken Sie daran, es auch ausführbar zu machen.

Beachten Sie, dass:

  • Sie benötigen zsh (nicht als Standard-Shell, nur installiert); Ich bin mir sicher, dass es auch in Bash geht, aber es ist schwieriger und ich habe keine Lust, es zu portieren.

  • Es wird davon ausgegangen, dass Git drin ist /usr/bin/git; Wir brauchen den vollständigen Pfad, weil es sich sonst ständig selbst aufruft. Konnte es aus analysieren PATHaber das ist komplexer.

  • Es funktioniert überall in der Befehlszeile (dies ist eine Funktion): Wenn Sie etwas wie eingeben git commit -am main dann wird dies auch umgeschrieben, wenn der Zweigname lautet master.

  • Sie könnten es in eine Shell-Funktion umwandeln, die etwas schneller ist. Dann funktioniert es jedoch nur von Ihrer Shell aus (was gut sein kann oder auch nicht, aber ich mag es, weil z :!git von Vim funktioniert identisch).

Das Ergebnis all dessen ist, dass Sie nicht für jeden Befehl spezielle Aliase benötigen und git einfach wie bisher verwenden können.

#!/usr/bin/env zsh
#
# Frob with git so that "main" gets rewritten to "master" if that's the default
# branch, or vice versa.
#
# The "real" git is assumed to be in /usr/bin/git.
[ "${ZSH_VERSION:-}" = "" ] && echo >&2 "Only works with zsh" && exit 1
setopt err_exit no_unset no_clobber pipefail

def=${$(/usr/bin/git symbolic-ref refs/remotes/origin/HEAD >&/dev/null ||:):t}
if [[ $def="master" && $argv[(i)main] -le $#argv ]] then
    print >&2 "Using 'main' instead of 'master'"
    argv[$argv[(i)main]]=master
elif [[ $def="main" && $argv[(i)master] -le $#argv ]] then
    print >&2 "Using 'master' instead of 'main'"
    argv[$argv[(i)master]]=main
fi

exec /usr/bin/git $argv

1429440cookie-checkGit-Alias, der für „main“ oder „master“ oder andere funktioniert

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy