Was ist "Git Remote Add ..." und "Git Push Origin Master"?

Sehr oft sehen Git und Rails wie Magie aus ... wie im ersten Kapitel des Rails 3 Tutorial-Buches geht es um Git:

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

und es sagt so ziemlich "es funktioniert einfach", ohne zu viel darüber zu sagen, was sie sind, und fängt an, über Verzweigung zu sprechen. Die Suche im Internet zeigt, dass git remote addein "Kurzname" hinzugefügt werden muss, z. B. origin, und es kann sich auch um einen beliebigen Namen handeln, der einem Alias ​​für eine URL ähnelt. Und originist der übliche Weg, auf den das Remote-Repo zeigt. (in http://git-scm.com/book/en/Git-Basics-Working-with-Remotes unter "Hinzufügen von Remote-Repositorys")

Warum ist die URL nicht anders git://git@github.com/peter/first_app.gitals in der anderen Syntax - welche Syntax ist das? Warum muss es damit enden .git? Ich habe versucht, .gitam Ende nicht zu verwenden und es funktioniert auch. Wenn nicht .git, was kann es sonst sein? Das gitin git@github.comscheint ein Benutzerkonto auf dem Git-Server zu sein?

Warum muss es auch so ausführlich sein, um es zu benutzen git push origin master? Kann die Standardeinstellung nicht Ursprung und Master sein? Ich fand, dass das erste Mal das origin masterbenötigt wird, aber nach einer kleinen Bearbeitung und einem Commit git pushist es alles, was es braucht (keine Notwendigkeit origin master). Kann jemand, der weiß, was los ist, einige Details geben?

Manchmal fühlt es sich wie viel Magie ohne Erklärung an ... und manchmal ist die Person, die es benutzt, so zuversichtlich und wenn sie gefragt wird, warum, kann sie es nicht erklären und antwortet mit etwas wie "so ist es". Manchmal sehr praktisch und pragmatisch. Es ist nicht schlecht, praktisch zu sein, aber wahrscheinlich nicht so praktisch, dass man nicht weiß, was los ist.

gitist wie UNIX. Benutzerfreundlich, aber wählerisch gegenüber seinen Freunden. Es ist ungefähr so ​​leistungsfähig und benutzerfreundlich wie eine Shell-Pipeline.

Abgesehen davon hat es, sobald Sie seine Paradigmen und Konzepte verstanden haben, dieselbe zenartige Klarheit, die ich von UNIX-Befehlszeilentools erwartet habe. Sie sollten sich eine Auszeit nehmen, um eines der vielen guten Git-Tutorials zu lesen, die online verfügbar sind. Das Pro Git-Buch ist ein guter Anfang.

Um Ihre erste Frage zu beantworten.

1. Was ist git remote add ...

   Wie Sie wahrscheinlich wissen, githandelt es sich um ein verteiltes Versionskontrollsystem. Die meisten Operationen werden lokal durchgeführt. Um mit der Außenwelt zu kommunizieren, gitwird das verwendet, was genannt wird remotes. Hierbei handelt es sich um andere Repositorys als das auf Ihrer lokalen Festplatte, in die Sie pushIhre Änderungen vornehmen können (damit andere Personen sie sehen können) oder pullvon denen aus (damit Sie andere Änderungen erhalten können). Der Befehl git remote add origin git@github.com:peter/first_app.giterstellt eine neue Fernbedienung mit dem Namen originat git@github.com:peter/first_app.git. Sobald Sie dies getan haben, können Sie in Ihren Push-Befehlen auf pushen, originanstatt die gesamte URL einzugeben.

2. Was ist git push origin master

   Dies ist ein Befehl, der besagt, dass "die Commits in dem benannten lokalen Zweig masteran die entfernte Fernbedienung gesendet werden origin". Sobald dies ausgeführt wurde, werden alle Inhalte, die Sie zuletzt mit origin synchronisiert haben, an das Remote-Repository gesendet, und andere Personen können sie dort sehen.

Nun zu Transporten (dh was git://) bedeutet. Remote - Repository - URLs kann von vielen Arten sein ( file://, https://etc.). Git verlässt sich einfach auf den Authentifizierungsmechanismus, der vom Transport bereitgestellt wird, um sich um Berechtigungen und andere Dinge zu kümmern. Dies bedeutet, dass es sich bei file://URLs um UNIX-Dateiberechtigungen usw. handelt. Das git://Schema fordert git auf, ein eigenes internes Transportprotokoll zu verwenden, das für das Senden von Git-Änderungssätzen optimiert ist. Die genaue URL ist so, wie sie ist, weil Github seinen gitServer eingerichtet hat.

Nun die Ausführlichkeit. Der Befehl, den Sie eingegeben haben, ist der allgemeine. Es ist möglich, git so etwas wie "Der masterhier aufgerufene Zweig ist ein lokaler Spiegel des fooauf der Fernbedienung aufgerufenen Zweigs " zu sagen bar. In git speak bedeutet dies, dass master Tracks bar/foo . Wenn Sie zum ersten Mal klonen, wird ein Zweig aufgerufen masterund eine Fernbedienung aufgerufen origin(von der aus Sie geklont haben), wobei der lokale Master so eingestellt ist, dass der Master beim Ursprung verfolgt wird. Sobald dies eingerichtet ist, können Sie einfach sagen git pushund es wird es tun. Der längere Befehl ist verfügbar, falls Sie ihn benötigen (z. B. git pushauf das offizielle öffentliche Repo und git push review masterkann auf eine separate Fernbedienung übertragen werden, mit der Ihr Team den Code überprüft). Sie können Ihren Zweig als Tracking-Zweig festlegen, indem Sie die Option verwenden--set-upstreamOption des git branchBefehls.

Ich habe das Gefühl, dass Git (im Gegensatz zu den meisten anderen Apps, die ich verwendet habe) von innen nach außen besser verstanden wird. Sobald Sie verstanden haben, wie Daten im Repository gespeichert und verwaltet werden, werden die Befehle und ihre Funktionen kristallklar. Ich stimme Ihnen zu, dass es unter vielen gitBenutzern einen gewissen Elitismus gibt, aber ich fand auch, dass es bei UNIX-Benutzern einmal war, und es hat sich gelohnt, an ihnen vorbei zu pflügen, um das System zu lernen. Viel Glück!

Update: Beachten Sie, dass die derzeit akzeptierte Antwort ein häufiges Missverständnis über das Verhalten von darstellt git push, das trotz eines Kommentars, der darauf hinweist, nicht korrigiert wurde.

Ihre Zusammenfassung der Fernbedienungen - wie ein Spitzname für die URL eines Repositorys - ist korrekt.

Warum also git die URL nicht git: //git@github.com/peter/first_app.git, sondern in der anderen Syntax - welche Syntax ist das? Warum muss es mit .git enden? Ich habe am Ende versucht, .git nicht zu verwenden und es funktioniert auch. Wenn nicht .git, was kann es sonst sein? Der Git am Anfänger scheint ein Benutzerkonto auf dem Git-Server zu sein?

Die beiden von Ihnen erwähnten URLs geben an, dass zwei verschiedene Transportprotokolle verwendet werden sollten. Der erste beginnt mit git://dem Git-Protokoll, das normalerweise nur für den schreibgeschützten Zugriff auf Repositorys verwendet wird. Die andere git@github.com:peter/first_app.gitist eine der verschiedenen Möglichkeiten, den Zugriff auf ein Repository über SSH festzulegen - dies ist die in der Dokumentation beschriebene "scp-artige Syntax" . Der Benutzername in der Syntax im scp-Stil beruht gitauf der Art und Weise, wie GitHub mit der Identifizierung von Benutzern umgeht. Im Wesentlichen wird dieser Benutzername ignoriert und der Benutzer wird anhand des SSH-Schlüsselpaars identifiziert, das er zur Authentifizierung verwendet hat.

Was die Ausführlichkeit von betrifft git push origin master, haben Sie bemerkt, dass Sie dies nach dem ersten Druck einfach tun können git push. Dies liegt an einer Reihe von schwer zu merkenden, aber allgemein hilfreichen Standardeinstellungen :)

• Wenn keine Fernbedienung angegeben ist, wird die für den aktuellen Zweig ( remote.master.urlin Ihrem Fall) konfigurierte Fernbedienung verwendet. Wenn das nicht eingerichtet ist, originwird es verwendet.
• Wenn es keine „Refspec“ (zB master, master:my-experimentusw.) angegeben, dann git standardmäßig alle lokalen Zweig drängen, die den gleichen Namen wie ein Zweig auf der Fernbedienung hat. Wenn Sie nur einen Zweig haben, der masterzwischen Ihrem Repository und dem Remote-Repository gemeinsam aufgerufen wird, entspricht dies dem Verschieben Ihres Zweigs masteran die Remote master.

Persönlich benutze ich immer das Formular, da ich dazu neige, viele Themenbereiche (und oft mehrere Fernbedienungen) zu haben:

git push origin master

... um ein versehentliches Drücken anderer Zweige zu vermeiden.

In der Antwort auf Ihre Kommentare zu einem der anderen Antworten, klingt es mir , als ob ich sehr effektiv in einem Top-down - Weg über git Lernen - Sie haben entdeckt , dass die Standardeinstellungen arbeiten, und Ihre Frage zu fragen , warum;) Zur Ernsthafter sein, kann GitIm Wesentlichen so einfach wie SVN verwendet werden, aber wenn Sie ein wenig über Fernbedienungen und Zweige wissen, können Sie es viel flexibler verwenden, und dies kann Ihre Arbeitsweise wirklich zum Besseren verändern. Ihre Bemerkung zu einem Semesterkurs lässt mich an etwas denken, das Scott Chacon in einem Podcast-Interview gesagt hat - die Schüler werden über alle Arten grundlegender Werkzeuge in der Informatik und Softwareentwicklung unterrichtet, aber sehr selten über die Versionskontrolle. Verteilte Versionskontrollsysteme wie git und Mercurial sind jetzt so wichtig und flexibel, dass es sich lohnt, Kurse darüber zu unterrichten, um den Menschen eine gute Grundlage zu geben.

Ich bin der Meinung, dass sich gitdiese Lernkurve absolut lohnt - mit vielen Themenzweigen zu arbeiten, sie einfach zusammenzuführen und zwischen verschiedenen Repositorys zu verschieben und zu ziehen, ist fantastisch nützlich, wenn Sie sich mit dem System vertraut gemacht haben. Es ist nur bedauerlich, dass:

• Die primäre Dokumentation für Git ist für Neulinge so schwer zu analysieren. (Obwohl ich behaupten würde, dass, wenn Sie für fast jede Git-Frage googeln, heutzutage hilfreiches Tutorial-Material (oder Stack Overflow-Antworten :)) auftaucht.)
• Es gibt ein paar seltsame Verhaltensweisen in Git, die derzeit schwer zu ändern sind, da viele Skripte möglicherweise auf ihnen basieren, aber für die Leute verwirrend sind.

Schauen Sie sich die Syntax zum Hinzufügen eines Remote-Repos an.

git remote add origin <url_of_remote repository>

Beispiel:

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

Lassen Sie uns den Befehl zerlegen:

Git Remote Hiermit werden Ihre zentralen Server für das Hosting Ihrer Git-Repositorys verwaltet.

Möglicherweise verwenden Sie Github für Ihr zentrales Repository. Ich werde Ihnen ein Beispiel geben und den Befehl git remote add origin erklären

Angenommen, ich arbeite mit GitHub und BitBucket für die zentralen Server für die Git-Repositorys und habe auf beiden Websites Repositorys für mein Erst-App- Projekt erstellt.

Wenn ich nun meine Änderungen auf diese beiden Git-Server übertragen möchte, muss ich git mitteilen, wie diese zentralen Repositorys erreicht werden sollen. Also muss ich diese hinzufügen,

Für GitHub

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

Und für BitBucket

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

Ich habe zwei Variablen verwendet (soweit es mir leicht fällt, sie als Variablen zu bezeichnen) gh_origin (gh FOR GITHUB) und bb_origin (bb für BITBUCKET), um Ihnen zu erklären, dass wir origin alles nennen können, was wir wollen.

Nachdem ich einige Änderungen vorgenommen habe, muss ich alle diese Änderungen an zentrale Repositorys senden (pushen), damit andere Benutzer diese Änderungen sehen können. Also rufe ich an

Pushing zu GitHub

git push gh_origin master

Pushing zu BitBucket

git push bb_origin master

gh_origin hält den Wert von https://github.com/user/first-app-git.git und bb_origin hält den Wert von https://user@bitbucket.org/user/first-app-git.git

Diese beiden Variablen erleichtern mir das Leben

Wie immer, wenn ich meine Codeänderungen senden muss, muss ich diese Wörter verwenden, anstatt die URL dafür zu speichern oder einzugeben.

In den meisten Fällen sehen Sie nur den Ursprung, da Sie in den meisten Fällen nur mit einem zentralen Repository wie beispielsweise Github oder BitBucket arbeiten.

1. Der .gitName am Ende des Repositorys ist nur eine Konvention. In der Regel werden Repositorys auf Git-Servern in benannten Verzeichnissen gespeichert project.git. Der Git-Client und das Protokoll berücksichtigen diese Konvention, indem sie testen, project.gitwann nur projectangegeben wird.

2. git://git@github.com/peter/first_app.gitist keine gültige Git-URL. Git-Repositorys können über verschiedene hier angegebene URL-Schemata identifiziert und aufgerufen werden . git@github.com:peter/first_app.git ist die sshauf dieser Seite erwähnte URL.

3. gitist flexibel. Sie können Ihren lokalen Zweig mit nahezu jedem Zweig eines Repositorys verfolgen. Das masterTracking (Ihr lokaler Standardzweig) origin/master(der Remote-Standardzweig) ist zwar eine beliebte Situation, aber nicht universell. Oft möchten Sie das vielleicht nicht. Deshalb ist der erste git pushso ausführlich. Es sagt git, was mit dem lokalen masterZweig zu tun ist, wenn Sie a git pulloder a tun git push.

4. Die Standardeinstellung für git pushund git pullist die Arbeit mit der Fernbedienung des aktuellen Zweigs. Dies ist eine bessere Standardeinstellung als der Ursprungsmaster. Die Art und Weise, wie Git Push dies bestimmt, wird hier erläutert .

git ist ziemlich elegant und verständlich, aber es gibt eine Lernkurve, durch die man gehen muss.

Git Remote Add Origin:

Es zentralisiert Ihren Quellcode für die anderen Projekte. Es basiert auf Linux, vervollständigt Open Source und macht Ihren Code für die anderen Git-Benutzer nützlich. Wir nennen ihn als Referenz

Überträgt Ihren Code mithilfe der Remote-URL des Git-Hubs in das Git-Repository.