Dlaczego muszę jawnie wcisnąć nowy oddział?

Jestem nowy giti ćwiczę. Utworzyłem oddział lokalny, ale zobaczyłem, że kiedy to zrobiłem, git pushmój oddział nie został przesłany do repozytorium. Musiałem faktycznie: git push -u origin --all.
Dlaczego to? Czy gałąź nie jest nową zmianą, która ma być wprowadzana domyślnie? Dlaczego muszę uruchomić drugie polecenie?

Rzeczywistym powodem jest to, że w nowym repozytorium (git init) nie ma żadnej gałęzi (nie master, żadnej gałęzi, zero gałęzi)

Więc kiedy naciskasz po raz pierwszy do pustego repozytorium upstream (zwykle nagiego ), to repozytorium upstream nie ma gałęzi o tej samej nazwie.

I:

• polityka domyślna pchnięcie było „ matching” (wcisnąć wszystkie gałęzie tej samej nazwie, tworząc je, jeśli ich nie ma),
• domyślną zasadą wypychania jest teraz ' simple' (wypychaj tylko bieżącą gałąź i tylko wtedy, gdy ma ona podobnie nazwaną gałąź zdalnego śledzenia w górę, od git 1.7.11 )

W obu przypadkach, ponieważ upstream puste repozytorium nie ma gałęzi:

• nie ma jeszcze pasującej nazwanej gałęzi
• w ogóle nie ma odgałęzienia (o tej samej nazwie lub bez! Śledzenie lub nie)

Oznacza to, że twój pierwszy lokalny push nie ma pojęcia:

• gdzie naciskać
• co wcisnąć (ponieważ nie może znaleźć żadnej gałęzi nadrzędnej, która byłaby zapisana jako zdalna gałąź śledzenia i / lub o tej samej nazwie)

Musisz przynajmniej wykonać:

git push origin master

Ale jeśli tylko to zrobisz, będziesz:

• utworzy mastergałąź upstream na upstream (teraz niepuste repo): good.
• nie zapisuje, że lokalny oddział „ master” musi zostać wypchnięty do upstream ( origin) ” master„ (upstream branch): zły.

Dlatego zaleca się, aby za pierwszym razem wykonać:

git push -u origin master

Będzie to rejestrowane origin/masterjako gałąź zdalnego śledzenia i umożliwi automatyczne push masterdo następnego push origin/master.

git checkout master
git push

I to będzie działać również w przypadku zasad wypychania current”lub„ upstream”.
W każdym przypadku po git push -u origin masterinicjalizacji wystarczy zwykłe wypychanie git, aby kontynuować przepychanie mastera do prawej gałęzi.

Nie widzisz poniżej

Uważam tę „cechę” za dość irytującą, ponieważ nie próbuję wystrzelić rakiet na Księżyc, tylko pchnąć moją cholerną gałąź. Prawdopodobnie też to robisz, inaczej by cię tu nie było!

Oto poprawka: jeśli chcesz, aby niejawnie naciskała na bieżącą gałąź niezależnie od tego, czy gałąź ta istnieje na początku, po prostu wydaj tę komendę raz i nigdy więcej nie będziesz musiał nigdzie:

git config --global push.default current

Więc jeśli tworzysz takie gałęzie:

git checkout -b my-new-branch

a następnie dokonaj kilku zatwierdzeń, a następnie wykonaj

git push -u

aby wydobyć je z pochodzenia (będąc w tej gałęzi) i utworzy dla ciebie wspomnianą gałąź, jeśli nie istnieje.

Zauważ, że bit -u upewnia się, że są one połączone, jeśli chcesz pobrać później z tej gałęzi. Jeśli nie planujesz później wyciągnąć gałęzi (lub jeśli nie masz nic przeciwko kolejnej wkładce) -u nie jest konieczne.

Dane wyjściowe git pushpodczas wypychania nowej gałęzi

> git checkout -b new_branch
Switched to a new branch 'new_branch'
> git push
fatal: The current branch new_branch has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin new_branch

Prosty git pushzakłada, że ​​istnieje już gałąź zdalna, którą śledzi bieżąca gałąź lokalna. Jeśli nie ma takiej zdalnej gałęzi i chcesz ją utworzyć, musisz to określić za pomocą flagi -u(krótkiej formy --set-upstream).

Dlaczego tak jest Wydaje mi się, że realizatorzy uważali, że utworzenie gałęzi na pilocie jest tak ważną czynnością, że ciężko byłoby to zrobić przez pomyłkę. git pushto coś, co robisz cały czas.

„Czy gałąź nie jest domyślnie nową zmianą, którą należy wprowadzić?” Powiedziałbym, że „zmiana” w Git jest zatwierdzeniem. Gałąź jest wskaźnikiem zatwierdzenia. Dla mnie bardziej sensowne jest myślenie o pchnięciu jako o czymś, co popycha zobowiązania do innych repozytoriów. To, które zatwierdzenia są wypychane, zależy od tego, w której gałęzi jesteś, i relacji śledzenia tej gałęzi do gałęzi na pilocie.

Możesz przeczytać więcej o śledzeniu gałęzi w rozdziale Zdalne gałęzie książki Pro Git .

Tak szybko nie mogłem znaleźć uzasadnienia dla oryginalnych programistów, ale mogę dać ci wykształcone domysły na podstawie kilku lat doświadczenia w Git.

Nie, nie każda gałąź jest czymś, co chcesz wypchnąć do świata zewnętrznego. Może reprezentować prywatny eksperyment.

Co więcej, gdzie należy git pushwysłać wszystkie oddziały? Git może współpracować z wieloma pilotami i możesz mieć różne zestawy gałęzi na każdym. Np. Centralny projekt repozytorium GitHub może mieć gałęzie wydania; widelec GitHub może mieć gałęzie tematów do przeglądu; a lokalny serwer Git może mieć oddziały zawierające lokalną konfigurację. Gdyby git pushpopchnąć wszystkie gałęzie do pilota, który śledzi bieżąca gałąź, tego rodzaju schemat byłby łatwy do zepsucia.

HEAD jest skrótem od aktualnej gałęzi, więc HEAD git push -u działa. Teraz, aby uniknąć tego wpisywania za każdym razem, gdy używam aliasu:

git config --global alias.pp 'push -u origin HEAD'

Następnie za każdym razem, gdy chcę przesłać gałąź utworzoną za pomocą gałęzi git -b, mogę przesłać ją za pomocą:

git pp

Mam nadzieję, że to komuś oszczędza czas!

Przy pierwszej kontroli

Krok 1: git remote -v
// jeśli znaleziono, zainicjuj git, a następnie usuń lub pomiń krok 2

Krok 2: git remote rm origin
// Następnie skonfiguruj swój adres e-mail globalnie git

Krok 3: git config --global user.email "youremail@example.com"

Krok 4: git initial

Krok 5: git commit -m "Initial Project"
// Jeśli już dodajesz repozytorium projektu, pomiń krok 6

Krok 6: git remote add origin %repo link from bitbucket.org%

Krok 7: git push -u origin master

Właśnie doświadczyłem dalszej permutacji tego problemu.

Miałem nazwę oddziału, feat/XYZ-1234-some-descriptionponieważ pracowałem nad wydaniem Jira 1234. W trakcie pracy stworzyłem nowy numer Jira, aby śledzić mniejszy fragment pracy, a kiedy przyszedłem do wypychania, postanowiłem przesłać do nazwy oddziału z tym nowym numerem wydania w:

git push -u origin feat/XYZ-5678-a-different-description # failed

To dało mi błąd omawiany w tym wątku SO. Ale ponieważ próbowałem przekazać nazwę inną niż moja obecna, mój problem był inny niż tutaj opisany. Ostatecznie zmieniłem nazwę mojego lokalnego oddziału, zanim mogłem go przekazać:

git branch -m feat/XYZ-1234-some-description feat/XYZ-5678-a-different-description
git push -u origin feat/XYZ-5678-a-different-description # now works

Po nieco więcej lekturach zdałem sobie sprawę, że mogłem ustawić opcję srcna git pushalbo do bieżącej nazwy oddziału, albo po prostu w HEADrazie potrzeby:

git push -u origin feat/XYZ-1234-some-description:feat/XYZ-5678-a-different-description # also works

Jeśli włączysz po raz pierwszy wprowadzanie nowych zmian z nowego oddziału. I poniżej błędu:

*git push -f
fatal: The current branch Coding_Preparation has no upstream branch.

Aby przesunąć bieżącą gałąź i ustawić pilota jako wysyłającego, użyj

git push -u origin new_branch_name


** Successful Result:** 
 git push -u origin Coding_Preparation
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 599 bytes | 599.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote:
remote: Create a pull request for 'Coding_Preparation' on GitHub by visiting: ...
 * [new branch]      Coding_Preparation -> Coding_Preparation
Branch 'Coding_Preparation' set up to track remote branch 'Coding_Preparation' from 'origin'.