リモートと GitHub

docs.scrimba.com

このハンドブックのこれまでのすべてのリポジトリは、1 つの場所、つまり自分のマシンに置かれていました。これはデッドノートパソコンを乗り越えるバックアップが必要になるまで、2 番目のコンピュータからプロジェクトをピックアップしたい、または誰かが他のコードに触れたいという時点まで、うまく機能します。必要なのは、関連するすべてのマシンがアクセスできる場所に置かれたリポジトリのコピーです。そのコピーはリモートと呼ばれ、GitHubはほとんどの開発者がそれを置く場所です。

リモートとは何か (GitHub がどこに適合するか)

**リモート**は、自分のマシン以外の場所でホストされているリポジトリのコピーで、ほとんどの場合 GitHub にあります。リポジトリをクローンすると、Git は既にデフォルトで origin という名前で 1 つを設定しています。git remote -v を実行します (実行すると、-v は名前と URL の両方が必要です):

$ git remote -v
origin  https://github.com/tanaka-hanako/weather-app.git (fetch)
origin  https://github.com/tanaka-hanako/weather-app.git (push)

Git が知っているすべてのリモートがリストされます。1 つはフェッチ用、1 つはプッシュ用です。理論的には、2 つは異なるアドレスを指す可能性があるためです。実際には、ほぼ常に同じものです。origin は、クローンで自動的に割り当てられるニックネームです。名前を変更するか、別のリモートを追加して別の場所を指すことができますが、ほぼすべてのプロジェクトがメインリモートを origin と呼びます。

これは、ほぼすべての初心者を混乱させる区別を再度述べるのに適切な時期です: Git と GitHub は同じものではありません。Git は、接続されているかどうかに関わらず、マシンで実行されているバージョン管理ツールであり、コミットを記録します。GitHub は、リポジトリのコピーをホストし、プッシュおよびプルするリモートを提供する Web サイトです。git remote、git push、git pull は 2 つを接続するコマンドです。ラップトップで実行している Git が GitHub のサーバー上にあるリポジトリと通信する方法です。

リモートは、リポジトリの設定に格納される URL にマップされた名前にすぎません。その横に、Git は**リモート追跡ブランチ**を保持します。マシンが最後にチェックインしたときのリモート上のブランチの位置を記録するローカルブックマーク。origin/main はまさにそれです。これは、GitHub に座っている実際の main ブランチではありません。これはあなたのリポジトリの記憶で、GitHub の main が最後にフェッチまたはプルされたときにどこにいたかです。Git が現在保持しているリモート追跡ブランチをリストします。git branch -r は:

$ git branch -r
origin/main

リモートが実行するすべてのものは、その設定エントリと、これらの追跡ブックマークを通じて実行されます。バックグラウンド接続はなく、変更を監視するものもありません。Git は、fetch または pull を使用して自分で指示した場合にのみ、リモートの画像を更新します。これは、このチャプターの残りの部分で正確にカバーされているものです。

Junoリモートとは何か リモートは通常 GitHub でホストされているリポジトリのコピーであり、Git はデフォルトの origin と呼びます。いつでも git remote -v を実行して、リポジトリが知っているリモートを確認します。Git と GitHub は同じものではありません。Git はマシン上のツールであり、GitHub はリモートが多くの場合生きている場所です。その分割をすぐに理解すると、後で多くの混乱が保存されます。

Junoリモートとは何かorigin は、クローン時に設定されたリモートに Git が与えるデフォルト名にすぎないため、名前を変更することも、プロジェクトが必要とする場合は複数のリモートを追加することもできます。git remote -v は、フェッチとプッシュの両方に対して、すべてのリモートの URL を表示します。Git と GitHub の分割を念頭に置いてください。ローカルで実行するコマンドは Git であり、GitHub はこれらのコマンドが到達できる複数の宛先の 1 つです。

Junoリモートとは何か リモートは、設定内の URL にマップされた名前であり、origin/main などのリモート追跡ブランチと組み合わされています。これはマシンの記憶で、そのブランチが最後のフェッチまたはプルで立っていた場所です。何も自動的に更新されません。Git はリクエストされた場合のみ、リモートをチェックします。GitHub が実際に持っているもの、およびリモート追跡ブランチが覚えているもの、の間のギャップは、ほぼすべてのフェッチ対プルのサプライズの背後にあります。

リモートをホストする場所: GitHub と代替案

リモートが実行するすべてのことはプレーン Git です。これは結果を伴います。知っておく価値がある: 反対側のホストは交換可能です。Git にとって、すべてのホストは設定内の URL であり、git push、git pull、git fetch はすべてのホストに対して同じように動作します。ホストが追加する内容は 1 層上にあります: コードの Web ビュー、レビュー フロー、問題の追跡、およびアクセス制御。以下は、トレードオフを明確に述べた風景です:

• GitHub は圧倒的に最大であり、オープンソース作業の大多数をホストしています。その強みはネットワークです。貢献したいプロジェクトはすでにそこにあり、チュートリアルがそれを想定し、雇用主はそのプロファイルを探しています。トレードオフは、それが閉じたプラットフォーム (Microsoft が所有する) であり、Git ホスティング以上のその余分なものに依存するほど、それにより多く結びついてしまうということです。
• GitLab は最も近い完全な代替案であり、わずかに異なる名前で同じコア機能を備えています (プルリクエストは「マージリクエスト」です)。その成果は、自分のサーバーで実行できるセルフマネージド版です。これが、コードを社内に保つ企業がそれを選択する理由です。トレードオフは、それが多くをバンドルすることであり、プラットフォームは、あなたが来たコード ホスティングよりも重く感じることができます。
• Bitbucket は Atlassian からのホストで、プロジェクト追跡および文書ツール、Jira および Confluence の横に座るように構築されています。チームが既にそれらのツールに住んでいる場合、それは直接スロットします。そのエコシステム外では、それは大きな 3 つの中で最も小さなコミュニティを持っており、オープンソースの存在はほとんどありません。
• Codeberg はオープンソース プロジェクト用の非営利ホストであり、オープンソース プラットフォーム Forgejo で実行されています。その魅力は、どの会社もホストを所有しておらず、プラットフォーム自体がオープン ソースであるということです。トレードオフはスケールです。統合が少なく、コミュニティが小さく、プライベート チーム ワークではなくオープン ソースに焦点を当てています。
• セルフホスティング はこれらすべての基礎にあります: Forgejo または Gitea を実行します。どちらも無料でオープン ソースであるか、制御されたハードウェアで GitLab の自己管理版を実行してください。完全な制御とプライバシーが得られます。トレードオフは、それを実行し続けることがあなたの仕事になるということです。

このハンドブックはその例で GitHub を使用しています。これは、ほとんどのオープン ソース作業をホストしており、最初に協力する可能性が最も高い場所です。このチャプターのすべてのコマンドは、他のホストに変わらずに転送されます: URL をスワップして、日次ループは同じままです。違いは 1 層上に住んでいます。各サイトの Web インターフェースで、作業をレビューおよびマージするため、次のチャプターの pull request flow がそこに入ります。

選択があなたのものである場合、それはめったに Git 機能についてではありません。コア セット (ホストされたリポジトリ、レビュー、問題、CI パイプライン) はどこにでも存在します。それはコンテキストに帰結します。オープン ソースに貢献するか、公開プロフィールを構築すること、GitHub を指します。Atlassian ツールで実行されている企業は Bitbucket を指します。コードが独自のインフラストラクチャに留まる必要があります。GitLab セルフマネージド版または Forgejo を指します。価値主導のオープン ソース プロジェクトは、Codeberg で最も自宅にいることを感じる可能性があります。選択はまた永遠ではありません。ホスト間でリポジトリ自体を移動すること、1 つの git remote set-url とプッシュです。移行の高価な部分は Git の上のレイヤー、問題、ウィキ、CI 構成です。コミットで移動しません。

セルフホスティングは、それにコミットする前に、明確な目を持った外観に値します。Forgejo と Gitea は小さなサーバーで快適に実行されますが、運用上の負荷は実数です: セキュリティ更新、リポジトリとプラットフォーム独自のデータベースの両方のバックアップ、アカウントおよび SSH キー管理、ならびにアップタイム。フォージが下がるとチームプッシュとプルをブロックするためです。コンプライアンス ルールがコードをサードパーティ インフラストラクチャから除外し、エア ギャップ環境で、または組織がツールを独自の管理下に置きたい場合、それは獲得に値します。Web レイヤー下では何も変わりません: これらのホストのそれぞれは同じ Git プロトコルを話すため、プッシュとフェッチはそれらを区別することができません。

Junoリモートをホストする場所 GitHub はほとんどのプロジェクトが住んでいる場所であり、あなたが始める時点で最も安全なデフォルトですが、それは複数のホストの 1 つです: GitLab、Bitbucket、および非営利の Codeberg はすべて同じ Git リポジトリを保存します。プッシュとプルは、リモートがどこに住んでいるかに関わらず同じように機能するため、プロジェクトが他の場所に住んでいる場合、ここで学んだことは何も無駄になりません。

Junoリモートをホストする場所 ホストは Git から 1 層上で異なります: GitLab はプルリクエストをマージリクエストと呼び、セルフマネージド版を提供します。Bitbucket は Atlassian のツールにプラグインし、Codeberg はオープンソース Forgejo で実行されます。協力者とツールが既にいるところに基づいて選択し、後で移動は Git 側では安いことを忘れずに。問題と CI は移動しません。

Junoリモートをホストする場所 リモートは URL にマップされた名前であるため、ホスト間でプロジェクトを移動すること git remote set-url と 1 つのプッシュです。セルフホスティング Forgejo または Gitea は、制御とプライバシーを購入し、パッチ、バックアップ、アップタイムを費用がかかります。ポリシーが要求するとき、楽しみのためにではなく、その取引を取ります。1 つのためにポケットベル を携わった人によって言われています。すべてのホスト固有のものは、Git プロトコルの上の Web レイヤーに住んでいます。

作業を送受信する: git push と git pull

リモートが設定されたら、2 つのコマンドがほぼすべての日常業務をカバーします。git push はローカル コミットをリモートに送信します。git pull は他の場所で作成されたコミットをダウンロードして、作成されているブランチにマージします。

$ git push origin main
Enumerating objects: 5, done.
Writing objects: 100% (3/3), 312 bytes | 312.00 KiB/s, done.
To https://github.com/tanaka-hanako/weather-app.git
   9f8e7d6..a1b2c3d  main -> main

origin はリモート、main は送信しているブランチです。最後の行は読む価値のある部分です: リモート上の main が 1 つのコミットから次のコミットに移動することを示します。

プルは同じように機能し、逆に:

$ git pull origin main
remote: Enumerating objects: 4, done.
Unpacking objects: 100% (4/4), done.
Updating a1b2c3d..b7c9e21
Fast-forward
 src/index.js | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

これはプロジェクト上の他の人と一緒に働くための全体のループです: 始める前に変更がダウンしたものをプルしてください。自分の仕事を行い、コミットしてください。それを戻してプッシュしてください。ブランチを他の人と共有するときは常に、プッシュする前にプルしてください。プルをスキップし、プッシュは見たことがないコミットの上に着陸することができます。Git はそれを拒否します。誰かの仕事を失うリスク。

新しいブランチを初めてプッシュするときは、-u を追加します (--set-upstream の短縮形):

$ git push -u origin feature/add-forecast-icons
Enumerating objects: 5, done.
Writing objects: 100% (5/5), 412 bytes | 412.00 KiB/s, done.
To https://github.com/tanaka-hanako/weather-app.git
 * [new branch]      feature/add-forecast-icons -> feature/add-forecast-icons
branch 'feature/add-forecast-icons' set up to track 'origin/feature/add-forecast-icons'.

これは feature/add-forecast-icons をトラッキング origin/feature/add-forecast-icons として記録します。**上流**と呼ばれるリンク。それが設定されたら、その後のすべてのプッシュとプルは、リモートとブランチ名をドロップし、ブランチで簡単な git push または git pull を実行できます。ブランチにまだ上流が設定されていない場合、Git はそれを言い、それを修正するための正確なコマンドを出力するため、フラグを覚える必要はめったにありません。メッセージが表示されたら、メッセージを認識するだけです。

その上流リンクは、-u が実行される瞬間にリポジトリの設定に書き込まれた 2 つのプレーン ラインとして生存します: branch.feature/add-forecast-icons.remote がリモート、branch.feature/add-forecast-icons.merge を名付けます。リポジトリの設定に書き込まれた 2 つのプレーン ラインとしてブランチ上にあります。以前にプッシュしたブランチで git config --get branch.main.remote を実行し、正確にその値が返されるのを確認します。これらの 2 つの行も git status が読み込みます。ブランチが origin/main より 2 つ前にあるか、2 つが異なる方向に漂流していることを伝えます: 比較は完全にリモート追跡ブランチに対して実行され、GitHub からフェッチされたローカル チェックは何もありません。上流を 1 回設定し、それ以降のすべての前後のカウント Git が表示するのは、設定ラインの同じペアを読んでいます。

Juno作業を送受信するgit push はコミットをリモートに送信し、git pull はコミットをダウンロードし、他の場所で作成されたコミットをブランチにマージします。開始する前にプルして、完了したときにプッシュすると、プロジェクトに他の人がいるか、プロジェクトに触れると、その人と同期しているままになります。プルをスキップすることは、プッシュが拒否される最も一般的な理由です。

Juno作業を送受信するgit push origin main はコミットを送信し、git pull origin main はフェッチしてマージし、ブランチに git push -u で設定された上流があると、両方のコマンドはリモートまたはブランチを再度命名することなく機能します。共有ブランチ上でプッシュする前にプルするか、プッシュが拒否されます。リモートが既にローカルの履歴を超えて移動しているためです。

Juno作業を送受信するgit push -u で設定した上流は 2 つの設定ラインにまで comes down、branch.<name>.remote および branch.<name>.merge。フラグが実行される瞬間に書き込まれます。git status はそれと同じペアを読み取り、ブランチが origin/main より前後にあるかを伝えます。完全にローカル リモート追跡ブランチに対して比較を実行します。ブランチごとに 1 回それを設定し、すべてのショートハンド プッシュまたはプル、およびすべての前後のカウント、無料で来ます。

git fetch と git pull

git pull は 1 つのステップで 2 つのことを行います。リモートで変更されたものをダウンロードしてから、すぐにそれらの変更を作成されているブランチにマージします。git fetch は前半のみを行います。新しいコミットをダウンロードしますが、ブランチにマージしません。現在のブランチとワーキング ファイルは、Git をマージまたはプルするように指示するまで、正確にそこにあります。

これはほぼすべての人がすくなくとも1回ヒットする trip-up です: git fetch を実行して、どこでも目に見える変化がなく、リモートで何も起こっていないと想定してください。何か起こりました: フェッチはまだワーキング ブランチに触れていません。ダウンしたものを確認するには、このチャプターの前半のリモート追跡ブランチを見てください: git log origin/main は、ローカル main に到達していないリモートに座っているコミットを表示します。それらを持ってくる準備ができたら、git merge origin/main がそれを行います。または git pull は、フェッチとそのマージを 1 つのコマンドで実行します。

マージする前に見たいときに、フェッチ自体に到達してください。同僚のプリヤが main に何かをプッシュしたことを言及しているとしましょう: git fetch の後に git log origin/main または git diff main origin/main が、それがワーキング ブランチに着地する前に、変更内容が正確に読むことができます。満足したら、git merge origin/main がそれを持ってきます。毎日、ほとんどの人は git pull に直接到達します。見たこと、マージを 1 つのステップで行うことは、彼らが望むことです。フェッチは、共有ブランチで着地する前に、着信作業を最初に読む方が良い場合、またはマージする今良い時期かどうかを判断する前に独自のものを獲得します。

フェッチが実際に更新するのは、refspec によって管理されます: リモート上のどのブランチをダウンロードするか、どのローカル名をそれらの下に格納するかを Git に伝える、リモートの設定に格納されるマッピング。通常のクローンのデフォルト refspec は +refs/heads/*:refs/remotes/origin/* のようなものを読み込み、「リモートの heads の下のすべてのブランチを取得し、それが何をしたのか書き直してまでそれを書き直したリモート追跡ブランチにミラーリングする」を意味します。これは、origin/main がフェッチを読んでいるリモートのブランチが何かが読んでいるほぼ、あなたのリモート追跡ブランチが一致するように書き直す全体的なメカニズムです。その後、停止します。自分の main については何も変更されません。分割されたマージ、リベース、またはプル フェッチが下してきたものに作用するまで。

Junogit fetch と git pullgit pull は新しいコミットをダウンロードし、1 つのステップでブランチにマージします。git fetch は、それらをダウンロードし、Git のメモリー、リモートがどこに立っているかを更新するだけです。ブランチは、マージするまでは残ります。フェッチ直後にファイル内に何も変わるのは予想通りですが、新しいコミットはリモート追跡ブランチで待機しています。

Junogit fetch と git pullgit fetch はマージなしでダウンロードし、git pull は 1 つのステップでダウンロードしてマージします。プレーン フェッチに到達して、git log origin/main で着信コミットを読みたい場合は、ブランチに着地する前に、プル準備ができて、それらを直ちにマージしたい場合は、プルしてください。2 つを混ぜることは、チーム上の最も一般的な Git ミックスアップの 1 つです。

Junogit fetch と git pull refspec は、フェッチをプルダウンするもの、origin/main を含むどのリモート追跡ブランチを更新するかを正確に決定し、デフォルト値はリモートの heads の下のすべてのブランチをミラーリングします。フェッチは、リモート追跡ブランチのみを移動し、チェックアウトされたブランチを移動しないため、マージまたはプルは別個の意図的なステップのままです。

ここであなたはどこに着地するか

プッシュ、プル、フェッチは、共有リモートの上下でコミットを取得します。これは、Git での日常的なコラボレーションがほぼ必要とするものをカバーしています。ここのすべては、commit loop の上に構築されます: あなたはまだ最初にローカルでステージングしてコミットしています。リモートは、それらのコミットが移動できる場所のみを変更します。次の部分は、GitHub 自体を通じてそのコラボレーションを行い、変更を提案し、マージする前にレビューすることです。pull request flow は正確にそこで拾われます。このチャプターの用語がまだぐらついている場合、リモート追跡ブランチ、refspec、上流、Glossary は各項目のプレーン定義を持っています。What is Git は独自に Git vs GitHub の区別を見直す価値があります。