「git remote add…」および「git push origin master」とは何ですか?


288

かなり頻繁に、GitのとRailsが魔法のように見える...などのようにRailsの3チュートリアルの本の最初の章は、Gitリポジトリを語ります:

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

そして、それは彼らが何であるかについてあまり言い過ぎずに分岐について話し始め、「それはちょうどうまくいく」とほとんど言っています。ネットで検索するとgit remote add、などの「短い名前」を追加するoriginことがわかります。これは、URLのエイリアスのような任意の名前にすることもできます。そしてorigin、リモートリポジトリが指す通常のパスです。(http://git-scm.com/book/en/Git-Basics-Working-with-Remotesの「リモートリポジトリの追加」の下)

では、なぜURL git://git@github.com/peter/first_app.gitが他の構文ではなく 、どのような構文なのでしょうか。なぜそれで終わらなければならないの.gitですか?.git最後に使わないようにしてみたところ、うまくいきました。そうでない場合.git、それ以外に何ができますか?git中には、git@github.comgitのサーバー上のユーザーアカウントのようですか?

また、なぜそれを使用するのに冗長にする必要があるのgit push origin masterですか?デフォルトをオリジンとマスターにできませんか?私は初めて、origin masterが必要であることがわかりましたが、小さな編集とコミットの後、必要なのgit pushはそれだけです(必要ありませんorigin master)。何が起こっているのかを知っている誰かが詳細を教えてもらえますか?

時にはそれは説明なしでは多くの魔法のように感じます...そして時にはそれを使用する人はとても自信があり、理由を尋ねられたときにそれを説明できず、「それがそうである」のようなもので応答できます。時々非常に実用的で実用的。実用的であることは悪くありませんが、何が起こっているのか分からないほどには実用的ではないでしょう。

回答:


344

gitUNIXのようなものです。ユーザーフレンドリーですが、その友達にうるさいです。シェルパイプラインと同じくらい強力でユーザーフレンドリーです。

そうは言っても、そのパラダイムと概念を理解すると、UNIXコマンドラインツールに期待するのと同じ禅のような明快さになります。オンラインで入手できる多くの優れたgitチュートリアルの1つを読むために、少し時間をとることを検討する必要があります。Pro Gitブックは、始めるのに適した場所です。

最初の質問に答えます。

  1. とは git remote add ...

    おそらくご存知のとおり、gitは分散バージョン管理システムです。ほとんどの操作はローカルで行われます。外の世界と通信するには、gitと呼ばれるものを使用しますremotes。これらは、ローカルディスク上のリポジトリとは別のリポジトリであり、push(他の人がそれを見るpullことができるように)変更したり、他の変更を取得したりできるように、変更を加えることができます。コマンドgit remote add origin git@github.com:peter/first_app.gitは、にあるという新しいリモートを作成origingit@github.com:peter/first_app.gitます。これを行うと、プッシュコマンドで、originURL全体を入力する代わりににプッシュできます。

  2. とは git push origin master

    これは、「ローカルブランチのコミットをmasterリモートネームドにプッシュする」と言うコマンドですorigin。これが実行されると、最後にoriginと同期したすべてのものがリモートリポジトリに送信され、他の人がそこで見ることができます。

次に、トランスポート(つまりgit://)について説明します。リモートリポジトリのURLは多くの種類(のものとすることができるfile://https://など)。Gitは、トランスポートによって提供される認証メカニズムに単純に依存して、アクセス許可などを処理します。これは、file://URLの場合、UNIXファイルのアクセス権などになることを意味します。このgit://スキームでは、gitチェンジセットの送信に最適化された独自の内部トランスポートプロトコルを使用するようgitに要求しています。正確なURLについては、githubがgitサーバーをセットアップした方法が原因です。

今度は冗長です。入力したコマンドは一般的なものです。「masterここで呼び出さfooれたブランチは、リモートで呼び出されたブランチのローカルミラーです」などのようにgitに伝えることができbarます。Git Speakでは、これはmaster トラックを 意味しますbar/foo。初めてクローンを作成するとき、ブランチが呼び出さmasterれ、リモートが呼び出されorigin(クローン元)、ローカルマスターセットを使用して、マスターを起点で追跡します。これが設定されたら、簡単に言うことができgit pushます。必要な場合に備えて、より長いコマンドを使用できます(たとえばgit push、公式の公開リポジトリgit push review masterにプッシュすることができ、チームがコードを確認するために使用する別のリモートにプッシュするために使用できます)。を使用して、ブランチを追跡ブランチに設定できます。--set-upstreamgit branchコマンドのオプション。

私が使用した他のほとんどのアプリとは異なり、gitは完全に理解されていると感じています。リポジトリ内でデータがどのように保存および維持されるかを理解すると、コマンドとその機能が明確になります。多くのgitユーザーの間でエリートが存在することはあなたにも同意しますが、UNIXユーザーの場合は、たまにそれを見つけました。システムを学ぶために、彼らを追い越してみる価値はありました。幸運を!


8
あなたはそれが説明するトランスポートについてのあなたの段落にメモを追加したい場合がありますgit@github.com:peter/first_app.gitですscpのgitでsshのURLのスタイルの構文。もう一つのポイントは、それは、デフォルトでは、上流の設定があるmasterの動作には影響しませんgit push しない限り、あなたがしているpush.defaultに設定tracking(またはupstreamそれ以降のバージョンでは) -私は混乱のこのソースに関するブログ記事をした:longair.net/blog/2011 /
02/27

1
そのコメントへの小さな修正- push.defaultアップストリーム設定なしでは、を使用するときにデフォルトのリモートを見つけるために使用されますgit pushが、参照のマッピングには影響しません。
Mark Longair 2011

1
「インサイドアウト」、通常の「ブラックボックス」は非常に簡単に学習できるのはなぜでしょうか。トップダウンアプローチのようなもので、トップ-インターフェース-入力内容と取得内容、非常によく定義されていて、うまくいけばシンプルでもあります。ユーザーが気にする必要があるのは「インターフェース」だけであり、実際には何が入っているかを知る必要はありません。ユーザーが詳細な実装方法を知りたい場合は、知っておくと便利ですが、通常はオプションです。
非極性

3
適切な黒ボクセン対裏返し。Gitは私が最初に遭遇したものであり、実際には「インターフェース」からよりも裏返しに学ぶ方が簡単でした。それが正しい方法かどうかは議論の余地があります。gitに関しては、裏返しの方が効果的だと言っています。
Noufal Ibrahim

9
「gitはUNIXのようなものです。ユーザーフレンドリーですが、友だちにこだわっています。」Tシャツにプリントしたいです。
proflux 2013

41

更新:現在受け入れられている回答は、の動作に関する一般的な誤解を永続させることに注意してくださいgit push。コメントはそれを指摘しているにもかかわらず修正されていません。

リモートが何であるかについてのあなたの要約-リポジトリのURLのニックネームのように-は正しいです。

それでは、なぜURLがgit://git@github.com/peter/first_app.gitではなく、他の構文で-何の構文ですか?なぜ.gitで終わる必要があるのですか?私は最後に.gitを使わないようにしてみましたが、それもうまくいきます。.gitでない場合、他に何ができますか?初心者のgitはgitサーバーのユーザーアカウントのようですか?

前述の2つのURLは、2つの異なるトランスポートプロトコルを使用する必要があることを示しています。で始まるgit://ものは、通常はリポジトリへの読み取り専用アクセスにのみ使用されるgitプロトコル用です。もう1つはgit@github.com:peter/first_app.git、SSH経由でリポジトリへのアクセスを指定するさまざまな方法の1つです。これは、ドキュメントで説明されいる「scpスタイルの構文」です。scpスタイルの構文でのユーザー名は、gitGitHubがユーザーの識別を処理する方法が原因です。基本的にそのユーザー名は無視され、ユーザーは認証に使用したSSHキーペアに基づいて識別されます。

の冗長性についてはgit push origin master、最初のプッシュの後で、すぐに実行できることがわかりましたgit push。これは、覚えにくいが一般的に役立つ一連のデフォルトのためです:)

  • リモートが指定されていない場合、現在のブランチに設定されているリモート(remote.master.url使用している場合)が使用されます。それoriginが設定されていない場合は、が使用されます。
  • 何の「refspec」(例えばがない場合はmastermaster:my-experimentリモートのブランチと同じ名前を持つすべてのローカルブランチをプッシュするには、gitのデフォルトは、など)を指定しました。masterリポジトリとリモートのブランチの間で共通に呼び出されるブランチがある場合、それはmasterリモートにpushするのと同じmasterです。

個人的には、私は多くのトピックブランチ(そして多くの場合いくつかのリモート)を持っている傾向があるため、常に次の形式を使用します。

git push origin master

...誤って他のブランチを押してしまうのを防ぎます。


他の回答の一つ上のあなたのコメントへの返信では、それがあるかのように私に聞こえるされている非常に効果的にトップダウンの方法でのgitについて学ぶ-あなたはデフォルトで動作することを発見した、とあなたの質問は、理由について尋ねている;)へのより深刻な、gitのこと本質的にはSVNと同じくらい簡単に使用できますが、リモートとブランチについて少し知っていれば、より柔軟に使用でき、これにより作業方法をより良いものに変えることができます。学期コースについてのあなたの発言は、スコットチャコンがポッドキャストインタビューで言った何かを思い起こさせます-学生はコンピューターサイエンスとソフトウェアエンジニアリングのあらゆる種類の基本的なツールについて教えられますが、バージョン管理はめったにありません。gitやMercurialなどの分散バージョン管理システムは、非常に重要で柔軟性が高いため、人々に十分な基礎を提供するためのコースを教える価値はあります。

私の見解ではgit、この学習曲線は絶対に価値があります-多くのトピックブランチで作業し、それらを簡単にマージし、異なるリポジトリ間でそれらをプッシュおよびプルすることは、システムに自信を持つと非常に便利です。それはただ残念なことです:

  • gitの主要なドキュメントは、初心者のために解析するのがとても難しいです。(私があなたがほとんどすべてのgit質問のためにあなたがグーグルであるなら、役に立つチュートリアル資料(またはスタックオーバーフローの回答:))が今日登場することを主張しますが。)
  • gitにはいくつかの奇妙な動作があり、多くのスクリプトはそれらに依存している可能性がありますが、人々を混乱させているため、現在変更するのは困難です。

pro git bookは優れたリソースであり、初心者にもわかりやすいと思います。学習曲線をかなり滑らかにします。また、SVNやその他の集中化された概念をgitに「マッピング」しようとすると、道がスムーズではなく難しくなると思います。完全なリセットは、私の経験ではより速く簡単な方法です。
Noufal Ibrahim

@Noufal Ibrahim:私はあなたのすべての点に同意します。私はSVNの概念をgitの概念に "マッピング"することを提案していませんでした。なぜなら、恐ろしい混乱を引き起こしている可能性があることを知っているからです。
Mark Longair、2011

9

リモートリポジトリを追加するための構文を確認してください。

git remote add origin <url_of_remote repository>

例:

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

コマンドを分析してみましょう:

git remoteこれは、gitリポジトリをホストするためのCentralサーバーの管理に使用されます。

セントラルリポジトリ用にGithubを使用している可能性があります。例を挙げ、git remote add originコマンドを説明します

gitリポジトリの中央サーバーとしてGitHubBitBucketを使用していて、最初のアプリプロジェクトの両方のWebサイトにリポジトリを作成したとします。

これらのgitサーバーの両方に変更をプッシュしたい場合は、これらの中央リポジトリに到達する方法をgitに指示する必要があります。これらを追加する必要があります

GitHubの場合

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

そして、BitBucket

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

私は2つの変数を使用しました(それらを変数と呼ぶのが簡単である限り)gh_origin(gh FOR GITHUB)とbb_origin(BITBUCKETの場合はbb)。

いくつかの変更を行った後、他のユーザーがこれらの変更を確認できるように、すべての変更を中央リポジトリに送信(プッシュ)する必要があります。だから私は電話します

GitHubへのプッシュ

git push gh_origin master

BitBucketへのプッシュ

git push bb_origin master

gh_originhttps://github.com/user/first-app-git.gitの値を保持しており、bb_originhttps://user@bitbucket.org/user/first-app-git.gitの値を保持しています

この2つの変数は私の人生を楽にしています

コードの変更を送信する必要があるときはいつでも、同じURLを覚えたり入力したりする代わりに、この単語を使用する必要があります。

ほとんどの場合、たとえばGithubやBitBucketなどの1つの中央リポジトリのみを処理するため、オリジン以外は何も表示されません。


5
  1. .gitリポジトリ名の末尾には、単に慣例です。通常、gitサーバーでは、リポジトリはという名前のディレクトリに保存されますproject.git。gitクライアントとプロトコルは、指定されたproject.git場合のみをテストすることにより、この規則を尊重しprojectます。

  2. git://git@github.com/peter/first_app.gitは有効なgit urlではありません。gitリポジトリは、指定されたさまざまなURLスキームを介して識別およびアクセスできますここでたます。 そのページに記載されてgit@github.com:peter/first_app.git いるsshURLです。

  3. git柔軟です。リポジトリのほとんどすべてのブランチに対してローカルブランチを追跡できます。一方でmaster(ローカルのデフォルトブランチ)追跡origin/master(リモートデフォルトのブランチ)が人気な状況で、それは普遍的ではありません。多くの場合、あなたはそれをしたくないかもしれません。これが最初の理由ですgit pushが非常に冗長であるです。mastera git pullまたはa を実行したときに、ローカルブランチをどうするかをgitに指示しますgit push

  4. git pushおよびのデフォルトgit pullは、現在のブランチのリモートで動作します。これは、オリジンマスターよりも優れたデフォルトです。git pushがこれを決定する方法は、ここで説明されています

git はかなりエレガントでわかりやすいですが、学習曲線があります。


1
他の回答にコメントしたように、gitのデフォルト構成でgit pushは、で設定された構成変数を使用して、git branch/checkout --trackプッシュするリモート参照を決定していません。ただし、git pullがこれらを使用することは正しいです。
Mark Longair、2011

0

Gitリモート追加元:

ソースコードを他のプロジェクトに一元化します。Linuxに基づいて開発されており、完全なオープンソースであり、他のgitユーザーがコードを利用できるようにします。

gitハブのリモートURLを使用して、コードをgitリポジトリにプッシュします。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.