Skonfiguruj git, aby ciągnął i pchał wszystkie gałęzie


615

Chciałbym domyślnie wypychać i wyciągać wszystkie gałęzie, w tym nowo utworzone.

Czy istnieje ustawienie, które mogę dla niego zdefiniować?

W przeciwnym razie, kiedy dodam nowy oddział lokalnie i chcę go pobrać z serwera, jaki jest najprostszy sposób, aby to zrobić?

Utworzyłem nowy oddział o tej samej nazwie i próbowałem go ściągnąć, ale to nie działa. Pyta mnie o całą zdalną konfigurację oddziału. Jak to ustawić.


4
„i próbował pociągnąć, ale to nie działa”. Szczegóły proszę. Pokaż, jakiej komendy próbujesz użyć.
Jakub Narębski,

Odpowiedzi:


1297

Najprostszym sposobem jest:

git push --all origin

Spowoduje to przesuwanie tagów i gałęzi.


10
Spośród dziesiątek odpowiedzi, które znalazłem w SO i innych miejscach, jest to najprostszy sposób na przekazanie nowo utworzonego lokalnego oddziału, bez dotykania konfiguracji. Dzięki!
András Szepesházi

174
A jeśli dodasz -ujeden raz, np. git push --all origin -uŚledzenie zostanie skonfigurowane, a potem możesz po prostu użyć git push.
Alec

23
W przypadku wersji git 1.7.12.3 musiałem użyć git push --tags origindo wypchnięcia wszystkich tagów.
thisgeek

17
Spójrz też na „--mirror” zamiast na „--all”, to wypchnij więcej rzeczy
Loda

21
OSTRZEŻENIE: Jeśli masz kilka oddziałów LOKALNYCH, których nie wyczyściłeś (funkcje, poprawki) - lub nie wyczyściłeś prawidłowo (ja), spowoduje to zalanie twojego pilota. Cholera. I właśnie zrobiliśmy przycinanie. Nie jestem pewien, dlaczego mój lokalny miał tak wiele oddziałów.
Jack

147

W nowoczesnym git zawsze pobierasz wszystkie gałęzie (jako gałęzie zdalnego śledzenia do refs/remotes/origin/*przestrzeni nazw, widoczne za pomocą git branch -rlub git remote show origin).

Domyślnie (patrz dokumentacja push.defaultzmiennej config) wypychasz pasujące gałęzie , co oznacza, że ​​najpierw musisz zrobić, git push origin branchaby git zawsze wypychał ją git push.

Jeśli chcesz zawsze wypychać wszystkie gałęzie , możesz skonfigurować push refspec. Zakładając, że pilot ma nazwę origin, możesz użyć git config :

$ git config --add remote.origin.push '+refs/heads/*:refs/heads/*'
$ git config --add remote.origin.push '+refs/tags/*:refs/tags/*'

lub bezpośrednio edytuj .git/configplik, aby mieć coś takiego:

[zdalne „pochodzenie”]
        url = użytkownik@example.com: /srv/git/repo.git
        fetch = + referencje / głowice / *: referencje / piloty / pochodzenie / *
        fetch = + refs / tags / *: refs / tags / *
        push = + refs / heads / *: refs / heads / *
        push = + refs / tags / *: refs / tags / *

3
@Merc: git push --all originjest dobre do jednorazowego opublikowania wszystkich gałęzi i tagów, choć domyślnie aż do obecnej wersji semantyczne „dopasowanie” oznaczałoby, że później pchnąłbyś wszystkie gałęzie… chyba że dodasz nową gałąź lub tag. Ustawienie na „wciśnij [...] wszystkie gałęzie domyślnie” jest tak napisane.
Jakub Narębski

Możesz poprawić odpowiedź, aby dodać sposób rekonfiguracji Git w ten sposób. Jest to przydatne dla użytkowników, którzy ustawili tryb prosty.
Dereckson,

3
Zmieniło się to od wersji 2.0. Domyślne ustawienia push są proste i już nie pasują.
Mike,

Próbowałem tego i dostałem błąd przy wypychaniu: fatal: Invalid refspec ''+refs/heads/*:refs/heads/*'' (Uwaga: korzystam z git 2.0. Nadal pracuję nad tym, jak to naprawić).
Brian Lacy

2
Teraz domyślną wartością push.defaultjest simple.
hasanghaforian 21.04.16

32

Dołączenie + do specyfikacji wypychania jest prawdopodobnie złym pomysłem, ponieważ oznacza to, że git z przyjemnością wykona wypychanie nie do przodu nawet bez opcji -f , a jeśli zdalny serwer jest skonfigurowany do akceptowania tych, możesz stracić historię.

Spróbuj tego:

$ git config --add remote.origin.push 'refs/heads/*:refs/heads/*'
$ git config --add remote.origin.push 'refs/tags/*:refs/tags/*'
$ git config --add remote.origin.fetch 'refs/heads/*:refs/remotes/origin/*'
$ git config --add remote.origin.fetch 'refs/tags/*:refs/tags/*'

Możesz również dodać --globalopcję do każdego z nich, aby ustawić globalną wartość domyślną dla wszystkich swoich repozytoriów.
Eter

Szkoda, że ​​git dodaje się automatycznie podczas działania + git remote add.
Eter

26

Użyłem poniższych poleceń do migracji wszystkich gałęzi do nowego repozytorium.

~$ git clone --mirror <url_of_old_repo>
~$ cd <name_of_old_repo>
~$ git remote add new-origin <url_of_new_repo>
~$ git push new-origin master
~$ git push new-origin --mirror

UWAGA : Musiałem użyć drugiej komendy (tj. Push master first) podczas klonowania repozytorium z Atlassian Stash do AWS CodeCommit (puste repo). Nie jestem pewien powodu, ale po wypchnięciu ( git push new-origin --mirror) domyślna gałąź odnosiła się do innej gałęzi niż master.


1
Idealny do przenoszenia repozytorium na inny host. Dziękuję Ci!
Pelmered

2
To jest rzeczywiście tylko przydatna metoda. Użyj git push new_origin --allpo prostu wypchnij bieżące lokalne gałęzie do new_origin, nie wszystkie gałęzie pochodzenia.
yanzi1225627

Wystarczy zauważyć, że tworzy to --barerepozytorium, które nieco różni się od zwykłego repozytorium, zawiera tylko .gitpliki, a nie pliki. Wystarczy, jeśli nie zamierzasz w tym pracować. Zobacz --barei --mirror git-scm.com/docs/git-clone .
jmmut,

Mimo że ma tylko pliki .git, a nie rzeczywisty kod źródłowy, jeśli wykonasz zdalną aktualizację, ponownie pobierze wszystko od źródła do miejsca docelowego.
SanthoshM

To był ratownik! Ta metoda „master przed lustrem” rozwiązała problem z Bitbucket jako miejscem docelowym, a główną gałęzią była wiara w inną gałąź niż „master”.
Toddius Zho,

12

Jeśli przenosisz oddziały do ​​nowego repozytorium ze starego i NIE masz lokalnych wszystkich starych repozytoriów, musisz je najpierw śledzić.

for remote in `git branch -r | grep -v '\->'`; do git branch --track $remote; done

Następnie dodaj nowe zdalne repozytorium:

git remote add bb <path-to-new-repo>

Następnie możesz wypchnąć wszystkich za pomocą tego polecenia:

git push -u bb --all

Lub możesz skonfigurować repo za pomocą komend git config wymienionych w innych odpowiedziach tutaj, jeśli nie robisz tego jednorazowo lub chcesz jedynie przenieść lokalne oddziały.

Ważny punkt, pozostałe odpowiedzi popychają tylko wszystkie LOKALNE gałęzie. Jeśli gałęzie istnieją tylko w alternatywnym repozytorium ZDALNYM, nie będą się one poruszać bez uprzedniego ich śledzenia. Zaprezentowana tutaj pętla for pomoże w tym.


BTW, używam tutaj „bb” zamiast „origin”, ponieważ zakładam, że twoje oryginalne / stare repozytorium zostało nazwane „origin” i prawdopodobnie nadal jest dołączone do tej etykiety. „bb” dotyczy Bitbucket, do którego przeniosłem moje oryginalne repozytorium, ale możesz nazwać to bardziej odpowiednim, jak „neworigin”, jeśli wolisz.
Lance Cleveland

2
To nie działało dla mnie. Skończyło się na tym, że wszystkie odległe gałęzie śledziły ten sam oddział lokalny: /
jhsowter

2
AFAIK to nie powinno działać, jak na komentarz @jhsowter. właściwym dla mnie poleceniem do śledzenia zdalnej gałęzi w nowo sklonowanym repozytorium jest git branch --track reponame origin/reponameinaczej, aby wszystkie zdalne gałęzie były śledzone w bieżącej gałęzi lokalnej
Pioneer Skies

Zmieniłem fragment repo-kolekcji na git branch -r | grep -v '\->' | sed 's/ origin\///', który daje tylko nazwę oddziału zdalnego.
Paul Hicks,

6

Aby zobaczyć wszystkie gałęzie bez użycia git branch -a, należy wykonać:

for remote in `git branch -r`; do git branch --track $remote; done
git fetch --all
git pull --all

Teraz możesz zobaczyć wszystkie gałęzie:

git branch

Aby wypchnąć wszystkie gałęzie, spróbuj:

git push --all

1
λ git fetch
all

próbujesz git fetch --all?
tokhi

4

Jeśli przenosisz wszystkie gałęzie do nowej repozytorium ze starej, wtedy w repozytorium lokalnym musisz skonfigurować śledzenie każdej gałęzi do istniejących gałęzi początkowych, przed wypchnięciem do nowej repozytorium, w przeciwnym razie wszystkie gałęzie początkowe nie pojawią się w nowe pochodzenie. Zrób to ręcznie, śledząc lub sprawdzając każdy oddział, lub użyj jednego linera:

for remote in `git branch -r | grep -v '\->' | grep -v master`; do git branch --track `echo $remote|sed 's=origin/=='` `echo $remote`; done

To jedno wierszowe polecenie oparte jest na jego wersjach w innych odpowiedziach na tej stronie, ale jest prawdopodobnie lepsze, ponieważ:

  1. poprawnie konfiguruje śledzenie gałęzi, w przeciwieństwie do niektórych starszych wariantów tej komendy na tej stronie, które podają tylko jeden parametr do --track, a zatem każda gałąź kończy master śledzenia - niezbyt dobrze
  2. nazywa lokalne oddziały bez przedrostka „origin /”, którego osobiście nie chcę - i jest spójny z tym, co dzieje się, gdy normalnie kasujesz oddział.
  3. pomija master śledzenia, ponieważ to już się dzieje
  4. tak naprawdę nic nie kasuje, dlatego jest szybki
  5. unika potknięcia się o -> na wyjściu gałęzi git -r

Następnie, jeśli zmieniasz źródła, zastąp link do starego źródła i wskaż nowego pilota. Upewnij się, że najpierw utworzysz nowy pilot przy użyciu GUI bitbucket / github, ale nie dodawaj do niego żadnych plików, w przeciwnym razie wystąpi problem z scalaniem. Na przykład

git remote set-url origin git@bitbucket.org:YOUR/SOMEREPO.git

Teraz pchnij. Zauważ, że drugie polecenie jest również potrzebne do wypchnięcia tagów:

git push -u --all origin
git push --tags origin

0

Rozwiązanie bez kodowania originw konfiguracji

W globalnej gitconfig użyj następujących opcji

[remote]
    push = +refs/heads/*
    push = +refs/tags/*

Spycha to wszystkie gałęzie i wszystkie tagi

Dlaczego NIE powinieneś hardcode originw konfiguracji?

Jeśli kodujesz na stałe:

  1. Skończysz originjako zdalny we wszystkich repozytoriach. Więc nie będziesz w stanie dodać pochodzenia, ale musisz użyć set-url.
  2. Jeśli narzędzie tworzy zdalny system o innej nazwie, wszystkie konfiguracje nie zostaną zastosowane. Następnie musisz zmienić nazwę pilota, ale zmiana nazwy nie zadziała, ponieważ originjuż istnieje (od punktu 1) pamiętaj :)

Pobieranie jest już obsługiwane przez nowoczesny git

Zgodnie z odpowiedzią Jakuba Narębskiego:

Dzięki nowoczesnemu gitowi zawsze pobierasz wszystkie gałęzie (jako gałęzie do zdalnego śledzenia w przestrzeni nazw ref / remotes / origin / *

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.