Git - Jaka jest różnica między „dopasowaniem” i „prostym” push.default


285

Od jakiegoś czasu korzystam z gita, ale nigdy nie musiałem sam tworzyć nowego zdalnego repo i byłem tego ciekawy. Czytam samouczki i nie wiem, jak uruchomić „git push”.

Jeśli po prostu git pushgo użyję, poprosi mnie o wyświetlenie domyślnej gałęzi (?), Aby wskazać? Jaka jest różnica między tymi dwiema opcjami, które dostarcza mi?

git config --global push.default matching
git config --global push.default simple

Dopasowanie tylko wypycha wszystkie gałęzie, które mam na moim lokalnym repozytorium, a jeśli się nie zgadzają, muszę ręcznie nakazać, aby wypchnął wszystkie nowe lokalne oddziały, prawda? Czy to najlepsza praktyka, czy jest prosta?



1
Teraz, jeśli tylko pull.defaultdostępna jest lokalna aktualizacja wszystkich tych oddziałów
Nogurenn

Odpowiedzi:


367

git push może wypchnąć wszystkie gałęzie lub jedną zależną od tej konfiguracji:

Wciśnij wszystkie gałęzie

git config --global push.default matching

Popchnie wszystkie gałęzie do odległej gałęzi i połączy je. Jeśli nie chcesz wypychać wszystkich gałęzi, możesz wypchnąć tylko bieżącą gałąź.

Wciśnij tylko bieżącą gałąź

git config --global push.default simple

Moim zdaniem lepiej jest skorzystać z tej opcji i przesuwać kod gałąź po gałęzi. Lepiej pchać gałęzie ręcznie i indywidualnie.


16
Podobała mi się odpowiedź push.default currentz @UpAndAdam. Nie wie o tym.
alanjds

4
Zauważ, że simplenie jest już opcją. W 1.7.8.4(i wcześniej?) Powoduje błąd podczas próby wypchnięcia. ale currentnadal jest dostępny
sześćdziesiąt4bit

@ sixty4bit: Używam git w wersji 1.7.1. Używam tracking-> push bieżącą gałąź do jej gałęzi upstream.
kevinarpe

@ sixty4bit Nie, został włączony do późniejszej wersji Git, w której nie wiem, ale (1.7) jest stary jak cholera, nawet w 2016 roku. W ogóle nie polecałbym używania tak starych wersji.
Schmoudi

Doceniony. Przepraszamy, ale opis połączonej strony simplenie ma sensu, jest sprzeczny z tą odpowiedzią i jest niepoprawny - co powoduje, że ta odpowiedź jest myląca. Połączona strona mówi: simple„będzie wypychać gałęzie jeden po drugim. Przeważnie związane z bieżącym oddziałem”. Czy to oznacza, że ​​będzie popychał gałęzie sekwencyjnie, a nie równolegle? Co oznacza „najczęściej połączony”? Następnie opis dla simplekontynuuje cytowanie opisu matching, co, jak można sądzić, oznacza, że ​​opis matchingdotyczy również simple. Ale oczywiście nie jest to prawdą.
tvanc

91

Z dokumentacji GIT: Git Docs

Poniżej podano pełne informacje. W skrócie, simplepopchnie tylkocurrent working branch i nawet wtedy, gdy będzie miał również tę samą nazwę na pilocie. Jest to bardzo dobre ustawienie dla początkujących i stanie się domyślnym wGIT 2.0

Natomiast matchingwypycha wszystkie gałęzie lokalnie, które mają takie same nazwy na pilocie. (Bez względu na aktualny działający oddział). Oznacza to, że potencjalnie zostanie przekazanych wiele różnych gałęzi, w tym te, których możesz nawet nie chcieć udostępniać.

W moim osobistym zastosowaniu zazwyczaj używam innej opcji: currentktóra popycha bieżącą działającą gałąź (ponieważ zawsze rozgałęziam się dla wszelkich zmian). Ale dla początkującego sugerowałbymsimple

push.default
Definiuje akcję, którą powinien podjąć git push, jeśli nie podano jawnie refspec. Różne wartości są odpowiednie dla określonych przepływów pracy; na przykład w czysto centralnym przepływie pracy (tj. źródło pobierania jest równe miejscu docelowemu wypychania), upstream jest prawdopodobnie tym, czego chcesz. Możliwe wartości to:

nic - nie wypychaj niczego (błąd), chyba że podano wyraźnie refspec. Jest to przede wszystkim przeznaczone dla osób, które chcą uniknąć błędów, zawsze wyrażając się jasno.

bieżące - naciśnij bieżącą gałąź, aby zaktualizować gałąź o tej samej nazwie na końcu odbierającym. Działa zarówno w centralnym, jak i niecentralnym przepływie pracy.

upstream - zepchnij bieżącą gałąź z powrotem do gałęzi, której zmiany są zwykle zintegrowane z bieżącą gałęzią (która nazywa się @ {upstream}). Ten tryb ma sens tylko wtedy, gdy przepychasz się do tego samego repozytorium, z którego normalnie korzystasz (tj. Centralny przepływ pracy).

proste - w scentralizowanym przepływie pracy pracuj jak nadrzędny z dodatkowym bezpieczeństwem, aby odmówić pushowania, jeśli nazwa gałęzi nadrzędnej jest inna niż nazwa lokalna.

Podczas pchania do pilota innego niż pilot, z którego zwykle wyciągasz, pracuj jako prąd. Jest to najbezpieczniejsza opcja i nadaje się dla początkujących.

Ten tryb stanie się domyślny w Git 2.0.

dopasowywanie - pchnij wszystkie gałęzie o tej samej nazwie na obu końcach. Powoduje to, że repozytorium, które popychasz, zapamiętuje zestaw gałęzi, które zostaną wypchnięte (np. Jeśli zawsze będziesz pchał keep i master tam, i nie ma innych gałęzi, repozytorium, do którego pchasz, będzie mieć te dwie gałęzie, a lokalny keep i master zostanie tam zepchnięty).

Aby skutecznie korzystać z tego trybu, musisz upewnić się, że wszystkie gałęzie, które chcesz wypchnąć, są gotowe do wypchnięcia przed uruchomieniem git push, ponieważ celem tego trybu jest umożliwienie wypchnięcia wszystkich gałęzi za jednym razem. Jeśli zwykle kończysz pracę tylko na jednej gałęzi i wypychasz wynik, podczas gdy inne gałęzie są niedokończone, ten tryb nie jest dla ciebie. Również ten tryb nie nadaje się do wypychania do wspólnego centralnego repozytorium, ponieważ inne osoby mogą dodawać tam nowe gałęzie lub aktualizować końcówkę istniejących gałęzi poza twoją kontrolą.

Jest to obecnie domyślna, ale Git 2.0 zmieni domyślną na prostą.


tak, ale zakładam nawet przy ustawieniu push.default, że jeśli wykonasz polecenie „$ git push origin master ”, spowoduje to popchnięcie tylko bieżącej gałęzi do początku do gałęzi o tej samej nazwie ... prawda? należy wspomnieć, że jest też domyślny pilot
Alexander Mills

1
Nie jestem pewien, czy rozumiem o co ci chodzi. W DOWOLNYM TRYBIE, jeśli powiesz, git push origin masterże zrobi to samo. Istotą trybów i ustawień domyślnych jest generalnie to, co dzieje się, gdy po prostu mówisz, git pusha nie mówisz zdalnie ani odgałęzieniu. Jakie ustawienie domyślne? masz na myśli domyślne ustawienie push.default? domyślne ustawienie, w której wersji git ... jeśli go nie dostaniesz, twój komentarz jest bardzo niejasny.
UpAndAdam

„push.default Definiuje akcję, którą powinien podjąć git push, jeśli nie podano jawnie refspec”, jeśli powiesz, że master git push origin podajesz mu więcej informacji i nadal może nie robić tego, co opisujesz; w zależności od skonfigurowanego refspec
UpAndAdam

2

Informacje o wersji Git v2.0

Uwagi dotyczące zgodności z poprzednimi wersjami

Kiedy git push [$there]nie mówi, co naciskać, do tej pory używaliśmy tradycyjnej semantyki „dopasowywania” (wszystkie twoje gałęzie zostały wysłane do pilota, o ile istnieją już gałęzie o tej samej nazwie). W Git 2.0 domyślną jest teraz „prosta” semantyka, która popycha:

  • tylko bieżąca gałąź do gałęzi o tej samej nazwie i tylko wtedy, gdy bieżąca gałąź jest skonfigurowana do integracji z tą gałęzią zdalną, jeśli pchasz do tego samego pilota, z którego pobierasz; lub

  • tylko bieżąca gałąź do gałęzi o tej samej nazwie, jeśli wypychasz do pilota, który nie jest tam, gdzie zwykle pobierasz.

Aby to zmienić, możesz użyć zmiennej konfiguracyjnej „push.default”. Jeśli jesteś starszym timerem, który chce nadal używać semantyki „dopasowywania”, możesz na przykład ustawić zmienną na „dopasowywanie”. Przeczytaj dokumentację dla innych możliwości.

Kiedy git add -ui git add -Asą uruchamiane w podkatalogu bez określania ścieżek do dodania w wierszu poleceń, działają na całym drzewie w celu zachowania spójności z git commit -ainnymi poleceniami (te polecenia działały tylko w bieżącym podkatalogu). Powiedz git add -u .lub git add -A .jeśli chcesz ograniczyć operację do bieżącego katalogu.

git add <path>jest taki sam jak git add -A <path>teraz, więc git add dir/zauważy ścieżki, które usunąłeś z katalogu i zarejestruje usunięcie. W starszych wersjach Git, git add <path>używane do ignorowania usuwania. Jeśli chcesz, możesz git add --ignore-removal <path>dodać tylko dodane lub zmodyfikowane ścieżki <path>.

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.