Co to jest „git remote add…” i „git push origin master”?

Dość często Git i Rails wyglądają jak magia ... tak jak w pierwszym rozdziale podręcznika Rails 3 , mówi o Git:

git remote add origin git@github.com:peter/first_app.git
git push origin master

i w zasadzie mówi „po prostu działa”, nie mówiąc zbyt wiele o tym, czym są i zacznij mówić o rozgałęzianiu. Wyszukiwanie w sieci pokazuje, że git remote addnależy dodać „krótką nazwę”, na przykład origin, i może to być dowolna nazwa, która jest jak alias adresu URL. I originjest to zwykła ścieżka do miejsca, w którym wskazuje zdalne repo. (w http://git-scm.com/book/en/Git-Basics-Working-with-Remotes w „Dodawanie zdalnych repozytoriów”)

Dlaczego więc URL nie git://git@github.com/peter/first_app.gitjest inny niż w innej składni - jaka to jest składnia? Dlaczego to musi się kończyć .git? Próbowałem nie używać .gitna końcu i to też działa. Jeśli nie .git, to co jeszcze może być? gitW git@github.comwydaje się być konto użytkownika na serwerze git?

Ponadto, dlaczego musi być tak gadatliwy w użyciu git push origin master? Czy domyślną wartością nie może być pochodzenie i wzorzec? Przekonałem się, że za pierwszym razem origin masterjest to potrzebne, ale po niewielkiej edycji i zatwierdzeniu, git pushto wszystko, czego potrzebuje (nie ma potrzeby origin master). Czy ktoś, kto wie, co się dzieje, może podać jakieś szczegóły?

Czasami wydaje się, że to dużo magii bez wyjaśnienia ... a czasami osoba, która go używa, jest taka pewna siebie i zapytana dlaczego, nie może tego wyjaśnić i odpowiada coś w stylu „tak jest”. Czasami bardzo praktyczny i pragmatyczny. Nie jest źle być praktycznym, ale prawdopodobnie nie praktycznym do tego stopnia, że ​​nie wiadomo, co się dzieje.

gitjest jak UNIX. Przyjazny dla użytkownika, ale wybredny wobec swoich przyjaciół. Jest tak potężny i przyjazny dla użytkownika jak potok powłoki.

To powiedziawszy, kiedy zrozumiesz jego paradygmaty i pojęcia, będzie miał taką samą zen przejrzystość, jakiej oczekuję od narzędzi wiersza poleceń UNIX. Powinieneś rozważyć chwilę wolnego, aby przeczytać jeden z wielu dobrych samouczków git dostępnych online. Książka Pro Git to dobry początek.

Aby odpowiedzieć na pierwsze pytanie.

1. Co jest git remote add ...

   Jak zapewne wiesz, gitjest to rozproszony system kontroli wersji. Większość operacji odbywa się lokalnie. Aby komunikować się ze światem zewnętrznym, gitużywa tak zwanych remotes. Są to repozytoria inne niż te na dysku lokalnym, w których można pushwprowadzać zmiany (aby inni mogli je zobaczyć) lub pullz (aby można było uzyskać zmiany innych). Polecenie git remote add origin git@github.com:peter/first_app.gittworzy nowy pilot o nazwie originznajduje się git@github.com:peter/first_app.git. Gdy to zrobisz, w swoich poleceniach wypychania możesz wypychać originzamiast wpisywać cały adres URL.

2. Co jest git push origin master

   Jest to polecenie, które mówi „wypchnij zatwierdzenia w lokalnym oddziale o nazwie masterdo zdalnego o nazwie origin”. Po wykonaniu tego wszystkie rzeczy, które ostatnio synchronizowałeś z początkiem, zostaną wysłane do zdalnego repozytorium i inne osoby będą mogły je tam zobaczyć.

Teraz o transporcie (tj. Co git://) znaczy. Zdalnego repozytorium adresy URL mogą być różnego rodzaju ( file://, https://etc.). Git po prostu polega na mechanizmie uwierzytelniania zapewnianym przez transport, aby zająć się uprawnieniami i innymi sprawami. Oznacza to, że w przypadku file://adresów URL będą to uprawnienia do plików w systemie UNIX itp. git://Schemat prosi git o użycie własnego wewnętrznego protokołu transportowego, zoptymalizowanego do wysyłania zestawów zmian git. Jeśli chodzi o dokładny adres URL, to tak jest z powodu sposobu, w jaki github skonfigurował swój gitserwer.

Teraz gadatliwość. Polecenie, które wpisałeś, jest ogólne. Można powiedzieć gitowi coś w rodzaju „gałąź, którą mastertu wywołujemy, jest lokalnym lustrem gałęzi wywoływanej foona pilocie o nazwie bar”. W git speak oznacza to, że master utwory bar/foo . Kiedy klonujesz po raz pierwszy, otrzymasz oddział o nazwie masteri pilot o nazwie origin(z którego sklonowałeś) z lokalnym zestawem wzorcowym do śledzenia wzorca na początku. Po skonfigurowaniu możesz po prostu powiedzieć git pushi zrobi to. Dłuższe polecenie jest dostępne w razie potrzeby (np. git pushMoże przesyłać do oficjalnego publicznego repozytorium i git push review mastermoże być używane do przekazywania do osobnego pilota, którego zespół używa do przeglądania kodu). Możesz ustawić swoją gałąź jako gałąź śledzenia za pomocą--set-upstreamopcja git branchpolecenia.

Czułem, że git (w przeciwieństwie do większości innych aplikacji, z których korzystałem) jest lepiej rozumiany od wewnątrz. Kiedy zrozumiesz, w jaki sposób dane są przechowywane i przechowywane w repozytorium, polecenia i ich działania stają się krystalicznie czyste. Zgadzam się z tobą, że wśród wielu gitużytkowników jest pewien elitarność, ale zauważyłem też, że z użytkownikami UNIXa dawno temu warto było przejechać obok nich, aby nauczyć się systemu. Powodzenia!

Aktualizacja: zauważ, że obecnie akceptowana odpowiedź utrwala powszechne nieporozumienie dotyczące zachowania git push, które nie zostało poprawione pomimo wskazującego komentarza.

Twoje podsumowanie dotyczące pilotów - jak pseudonim dla adresu URL repozytorium - jest poprawne.

Dlaczego więc adres URL nie jest git: //git@github.com/peter/first_app.git, ale w innej składni - jaka to jest składnia? Dlaczego musi kończyć się na .git? Próbowałem nie używać .git na końcu i to też działa. Jeśli nie .git, co jeszcze może być? Git na początku wygląda na konto użytkownika na serwerze git?

Dwa wspomniane adresy URL wskazują, że należy użyć dwóch różnych protokołów transportowych. Pierwszy zaczyna się git://od protokołu git, który jest zwykle używany tylko do dostępu do repozytoriów tylko do odczytu. Drugi git@github.com:peter/first_app.git, to jeden z różnych sposobów określania dostępu do repozytorium przez SSH - jest to „składnia w stylu scp” opisana w dokumentacji . To, że nazwa użytkownika w składni stylu SCP jest gitspowodowana sposobem, w jaki GitHub radzi sobie z identyfikacją użytkowników - w zasadzie ta nazwa użytkownika jest ignorowana, a użytkownik jest identyfikowany na podstawie pary kluczy SSH, której użyli do uwierzytelnienia.

Jeśli chodzi o gadatliwość git push origin master, zauważyłeś, że po pierwszym naciśnięciu możesz to zrobićgit push . Wynika to z serii trudnych do zapamiętania, ale ogólnie pomocnych wartości domyślnych :)

• Jeśli nie określono pilota, remote.master.urlużywany jest pilot skonfigurowany dla bieżącej gałęzi ( w twoim przypadku). Jeśli to nie jest skonfigurowane, toorigin jest używane.
• Jeśli nie ma „refspec” (np master, master:my-experimentitd) określony, a następnie git domyślnie naciska każdy lokalny oddział, który ma taką samą nazwę jak oddział na pilocie. Jeśli po prostu masz gałąź masterwspólną dla swojego repozytorium i zdalnej, będzie to to samo, co wypychanie masterdo zdalnego master.

Osobiście, ponieważ zwykle mam wiele gałęzi tematycznych (i często kilka pilotów), zawsze używam formularza:

git push origin master

... aby uniknąć przypadkowego popchnięcia innych gałęzi.

W odpowiedzi na twoje komentarze do jednej z pozostałych odpowiedzi brzmi to tak, jakby były nauki o git w top-down sposób bardzo skutecznie - odkryłeś, że domyślnie pracować, a pytanie jest pytaniem, dlaczego;), aby poważniej, git możemoże być używany zasadniczo tak samo jak SVN, ale znajomość pilotów i gałęzi oznacza, że ​​możesz używać go bardziej elastycznie, a to może naprawdę zmienić sposób pracy na lepszy. Twoja uwaga na temat kursu semestralnego przypomina mi coś, co Scott Chacon powiedział w wywiadzie podcastowym - studenci uczą się wszelkiego rodzaju podstawowych narzędzi informatycznych i inżynierii oprogramowania, ale bardzo rzadko kontroli wersji. Rozproszone systemy kontroli wersji, takie jak git i Mercurial, są teraz tak ważne i tak elastyczne, że warto na nich uczyć kursów, aby zapewnić ludziom dobre uziemienie.

Moim zdaniem gitta krzywa uczenia się jest absolutnie tego warta - praca z wieloma gałęziami tematycznymi, łatwe łączenie ich oraz przesuwanie i przeciąganie ich pomiędzy różnymi repozytoriami jest fantastycznie przydatne, gdy tylko poczujesz się pewnie z systemem. Szkoda tylko, że:

• Podstawowa dokumentacja git jest tak trudna do przeanalizowania dla nowych użytkowników. (Chociaż twierdzę, że jeśli Google zadaje prawie każde pytanie git, w dzisiejszych czasach pojawiają się pomocne materiały instruktażowe (lub odpowiedzi dotyczące przepełnienia stosu :)).)
• Istnieje kilka dziwnych zachowań w git, które trudno teraz zmienić, ponieważ wiele skryptów może na nich polegać, ale są mylące dla ludzi.

Spójrz na składnię dodawania zdalnego repo.

git remote add origin <url_of_remote repository>

Przykład:

git remote add origin git@github.com:peter/first_app.git

Przeanalizujmy polecenie:

git remote służy do zarządzania centralnymi serwerami do obsługi repozytoriów git.

Być może używasz Github do centralnego repozytorium. Podam wam przykład i wyjaśnienie git remote add origin polecenia

Załóżmy, że współpracuję z GitHub i BitBucket dla serwerów centralnych dla repozytoriów git i utworzyłem repozytoria na obu stronach dla mojego projektu pierwszej aplikacji .

Teraz, jeśli chcę przekazać moje zmiany obu serwerom git, będę musiał powiedzieć git, jak dotrzeć do tych centralnych repozytoriów. Będę musiał dodać te,

Dla GitHub

git remote add gh_origin https://github.com/user/first-app-git.git

I dla BitBucket

git remote add bb_origin https://user@bitbucket.org/user/first-app-git.git

Użyłem dwóch zmiennych (o ile łatwo nazwać je zmiennymi) gh_origin (gh FOR GITHUB) i bb_origin (bb dla BITBUCKET) tylko po to, aby wyjaśnić, że możemy nazywać pochodzenie dowolnie.

Teraz po wprowadzeniu pewnych zmian będę musiał wysłać (push) wszystkie te zmiany do centralnych repozytoriów, aby inni użytkownicy mogli je zobaczyć. Więc dzwonię

Przesyłanie do GitHub

git push gh_origin master

Pchanie do BitBucket

git push bb_origin master

gh_origin trzyma wartość https://github.com/user/first-app-git.git, a bb_origin trzyma wartość https: //user@bitbucket.org/user/first-app-git.git

Te dwie zmienne ułatwiają mi życie

ponieważ za każdym razem, gdy muszę wysłać zmiany w kodzie, muszę używać tych słów zamiast zapamiętywać lub wpisywać adres URL tego samego.

W większości przypadków nie widzisz niczego poza pochodzeniem, ponieważ w większości przypadków masz do czynienia tylko z jednym centralnym repozytorium, takim jak na przykład Github lub BitBucket.

1. Na .gitkońcu nazwy repozytorium jest tylko konwencja. Zazwyczaj na serwerach git repozytoria są przechowywane w nazwanych katalogach project.git. Klient i protokół git honoruje tę konwencję, testując, project.gitkiedy tylko projectjest określony.

2. git://git@github.com/peter/first_app.gitnie jest prawidłowym adresem git. repozytoria git można zidentyfikować i uzyskać do nich dostęp za pomocą różnych schematów URL określonych tutaj . git@github.com:peter/first_app.git to sshadres URL wymieniony na tej stronie.

3. gitjest elastyczny. Umożliwia śledzenie lokalnego oddziału w prawie każdym oddziale dowolnego repozytorium. Chociaż masterśledzenie origin/master( lokalna gałąź domyślna) (zdalna gałąź domyślna) jest popularną sytuacją, nie jest uniwersalne. Wiele razy możesz tego nie chcieć. Właśnie dlatego pierwszy git pushjest tak pełny. Mówi git, co zrobić z lokalnym masteroddziałem, gdy wykonujesz a git pulllub a git push.

4. Domyślnie git pushi git pulldziała z pilotem bieżącego oddziału. Jest to lepsze ustawienie domyślne niż wzorzec źródłowy. Sposób, w jaki git push określa to, jest wyjaśniony tutaj .

git jest dość elegancki i zrozumiały, ale istnieje krzywa uczenia się do przejścia.

Zdalne dodanie pochodzenia Git:

Centralizuje kod źródłowy w stosunku do innych projektów. Został opracowany w oparciu o system Linux, kompletne oprogramowanie open source i sprawia, że ​​kod jest użyteczny dla innych użytkowników git. Nazywamy go jako odniesienie

Pcha kod do repozytorium git przy użyciu zdalnego adresu URL centrum git.