Kann "git pull --all" alle meine lokalen Zweige aktualisieren?

Question

Ich habe oft mindestens 3 Remote-Zweige: Master, Staging und Production. Ich habe 3 lokale Zweige, die diese entfernten Zweige verfolgen.

Die Aktualisierung aller meiner lokalen Zweigstellen ist mühsam:

git fetch --all
git rebase origin/master
git checkout staging
git rebase origin/staging
git checkout production
git rebase origin/production

Ich würde gerne einfach ein "git pull -all" machen, aber ich habe es nicht zum Laufen gebracht. Es scheint ein "fetch --all" zu machen, dann aktualisiert es den aktuellen Arbeitszweig (vorspulen oder zusammenführen), aber nicht die anderen lokalen Zweige.

Ich muss immer noch manuell zu jedem lokalen Zweig wechseln und ihn aktualisieren.

Answer 1

Ich benutze die sync Unterbefehl von Nabe um dies zu automatisieren. Ich habe alias git=hub in meinem .bash_profile Der Befehl, den ich eingebe, lautet also:

git sync

Dies aktualisiert alle lokalen Zweige, die einen passenden Upstream-Zweig haben. Aus der Manpage:

• Wenn der lokale Zweig veraltet ist, spulen Sie ihn vor;
• Wenn der lokale Zweig noch nicht gepushte Arbeit enthält, warnen Sie davor;
• Wenn der Zweig scheinbar zusammengeführt wurde und sein vorgelagerter Zweig gelöscht wurde, löschen Sie ihn.

Es behandelt auch das Stashing/Unstashing von nicht übertragenen Änderungen auf dem aktuellen Zweig.

Früher habe ich ein ähnliches Tool namens git-up aber sie wird nicht mehr gepflegt, und git sync macht fast genau das Gleiche.

Answer 2

Das von Ihnen beschriebene Verhalten für pull --all ist genau wie erwartet, wenn auch nicht unbedingt nützlich. Die Option wird an git fetch weitergegeben, das dann alle Referenzen von allen Remotes abruft, anstatt nur die benötigte; pull führt dann den entsprechenden einzelnen Zweig zusammen (bzw. in Ihrem Fall neu zuordnen).

Wenn Sie andere Zweigstellen besuchen möchten, müssen Sie diese selbst aufsuchen. Und ja, Zusammenführen (und Umbasieren) absolut erfordern einen Arbeitsbaum, so dass sie nicht durchgeführt werden können, ohne die anderen Zweige zu überprüfen. Wenn Sie möchten, können Sie die beschriebenen Schritte in einem Skript/Alias zusammenfassen, obwohl ich vorschlagen würde, die Befehle mit && so dass bei einem Ausfall eines der beiden Systeme nicht versucht wird, weiterzufahren.

Answer 3

Ich weiß, dass diese Frage schon fast 3 Jahre alt ist, aber ich habe mir genau die gleiche Frage gestellt und keine fertige Lösung gefunden. Also habe ich ein benutzerdefiniertes Git-Befehl-Shell-Skript selbst erstellt.

Jetzt geht es los, die git-ffwd-update Skript macht folgendes...

1. gibt sie eine git remote update zum Abrufen der aktuellen Drehzahlen
2. verwendet dann git remote show um eine Liste der lokalen Zweige zu erhalten, die einen entfernten Zweig verfolgen (z. B. Zweige, die mit git pull )
3. dann prüft es mit git rev-list --count <REMOTE_BRANCH>..<LOCAL_BRANCH> wie viele Commits der lokale Zweig hinter dem entfernten liegt (und umgekehrt)
4. wenn der lokale Zweig 1 oder mehr Commits voraus ist, kann er NICHT vorgespult werden und muss von Hand zusammengeführt oder neu gebased werden
5. wenn der lokale Zweig 0 Commits voraus ist und 1 oder mehr Commits zurückliegt, kann er vorgespult werden durch git branch -f <LOCAL_BRANCH> -t <REMOTE_BRANCH>

kann das Skript wie folgt aufgerufen werden:

$ git ffwd-update
Fetching origin
 branch bigcouch was 10 commit(s) behind of origin/bigcouch. resetting local branch to remote
 branch develop was 3 commit(s) behind of origin/develop. resetting local branch to remote
 branch master is 6 commit(s) behind and 1 commit(s) ahead of origin/master. could not be fast-forwarded

Das vollständige Skript sollte gespeichert werden als git-ffwd-update und muss sich auf der PATH .

#!/bin/bash

main() {
  REMOTES="$@";
  if [ -z "$REMOTES" ]; then
    REMOTES=$(git remote);
  fi
  REMOTES=$(echo "$REMOTES" | xargs -n1 echo)
  CLB=$(git rev-parse --abbrev-ref HEAD);
  echo "$REMOTES" | while read REMOTE; do
    git remote update $REMOTE
    git remote show $REMOTE -n \
    | awk '/merges with remote/{print $5" "$1}' \
    | while read RB LB; do
      ARB="refs/remotes/$REMOTE/$RB";
      ALB="refs/heads/$LB";
      NBEHIND=$(( $(git rev-list --count $ALB..$ARB 2>/dev/null) +0));
      NAHEAD=$(( $(git rev-list --count $ARB..$ALB 2>/dev/null) +0));
      if [ "$NBEHIND" -gt 0 ]; then
        if [ "$NAHEAD" -gt 0 ]; then
          echo " branch $LB is $NBEHIND commit(s) behind and $NAHEAD commit(s) ahead of $REMOTE/$RB. could not be fast-forwarded";
        elif [ "$LB" = "$CLB" ]; then
          echo " branch $LB was $NBEHIND commit(s) behind of $REMOTE/$RB. fast-forward merge";
          git merge -q $ARB;
        else
          echo " branch $LB was $NBEHIND commit(s) behind of $REMOTE/$RB. resetting local branch to remote";
          git branch -f $LB -t $ARB >/dev/null;
        fi
      fi
    done
  done
}

main $@

Answer 4

Es ist nicht so schwer zu automatisieren:

#!/bin/sh
# Usage: fetchall.sh branch ...

set -x
git fetch --all
for branch in "$@"; do
    git checkout "$branch"      || exit 1
    git rebase "origin/$branch" || exit 1
done

Answer 5

Das ist immer noch nicht automatisch, ich wünschte, es gäbe eine Option dafür - und es sollte eine Überprüfung geben, die sicherstellt, dass dies nur bei Schnellvorlauf-Updates passieren kann (weshalb ein manueller Pull weitaus sicherer ist!!), aber abgesehen von den Vorbehalten kann man es tun:

git fetch origin
git update-ref refs/heads/other-branch origin/other-branch

um die Position Ihrer örtlichen Zweigstelle zu aktualisieren, ohne dass Sie sie abfragen müssen.

Hinweis: Sie verlieren Ihre aktuelle Zweigposition und verschieben sie dorthin, wo sich der Ursprungszweig befindet, was bedeutet, dass Sie beim Zusammenführen Daten verlieren!