1. おなじみのシーンから始めましょう
コードを書いたことのあるほぼすべての人が、プロジェクト フォルダーに一連のファイルが存在するという経験をしたことがあるでしょう。项目.zip、项目-最终版.zip、项目-最终版-真的最终版.zip。変更を加えた後、ロールバックしたいのですが、どのバージョンにロールバックすればよいかわかりません。 2 人が共同作業するためにファイルを転送すると、A の変更が B の変更を上書きし、どちらのバージョンが正しいのか誰も分からないことがわかりました。
これらの問題の根本的な原因は、手動によるバージョン管理が信頼できないことと、Git が「アーカイブ」タスクをプログラムに任せるように設計されていることです。
多くの人は Git と GitHub の関係を区別できません。まず正確な理解を確立しましょう。
シート
| 道具 | 自然 | 効果 |
|---|---|---|
| Git | ローカルにインストールされたソフトウェア | コードのすべてのバージョン変更を記録し、ロールバックをサポートします |
| GitHub | インターネットのウェブサイト | ローカルバージョンのライブラリをクラウドにバックアップし、複数人でのコラボレーションをサポートします |
一文で言うと：Git はローカル バージョン管理を担当し、GitHub はクラウド ストレージと共有バージョンを担当します。
ある日コンピューターが故障したとしても、GitHub にプッシュしておけば、コードとすべての履歴記録が失われることはありません。 AI 支援プログラミングの時代においても、このシステムは依然としてコードを記述するためのインフラストラクチャです。AI はコードの作成を支援しますが、依然としてバージョン管理の規律を自分で習得する必要があります。
2. Git のインストール: さまざまなシステムのパス
Windowsユーザー: Git 公式 Web サイトにアクセスし、Windows インストール パッケージをダウンロードし、通常のソフトウェアをインストールするのと同じように[次へ]をクリックします。インストールが完了すると、右クリックでフォルダーメニューが表示されますGit Bash Hereこれは Git に付属するコマンド ライン環境です。 Git Bashを開いて入力します
git --version
バージョン番号が表示されれば、インストールは成功しています。
macOS ユーザー: まずターミナルに入力します
git --version
多くの Mac の Git は他の開発ツールとともにプリインストールされており、バージョン番号が直接表示されます。最初にインストールする必要があるというプロンプトが表示された場合Xcode Command Line Tools(Xcode コマンド ライン開発者ツール)、プロンプトに従ってインストールするだけです。このツール セットには、Git に加えて、コンパイラーやデバッガーなどの重要な開発コンポーネントの完全なセットも含まれています。遅かれ早かれインストールする必要があるので、心配しないでください。
上級プレイヤー向けの遅延メソッド: Claude Code や CodeBuddy などのプログラミング エージェントを使用している場合は、AI に直接 Git を検出してインストールさせることができます。
インストール後、最初に「署名」を設定します。これは、各送信の作成者をマークするために使用されます (これは GitHub ログイン アカウントではないことに注意してください)。
3. コアメンタルモデル: 3 つの領域
Git を使用する前に、まず正しいイメージを確立してください。そうしないと、いくらコマンドを覚えても、丸暗記になってしまいます。埋め込む git init その後、プロジェクト フォルダーは実際には 3 つの領域に分割されます。
- 作業ディレクトリ: これは、すべてのコード変更が行われる「自分のデスク」に似た、目に見えるプロジェクト ファイルです。
- ステージングエリア：「ショッピングカート」のたとえ。今回アーカイブしたい変更を 1 つずつ選択します。選択されていない変更はアーカイブに含まれません。
- コミット履歴: に保存されています
.git隠しフォルダー内の「アーカイブ」。すべてのアーカイブ (コミット) はここに永続的に保存され、いつでも確認できます。
git init それが行うことは、 .git フォルダーを作成し、空のウェアハウスを初期化します。今後、このプロジェクトにはバージョン管理機能が追加されます。
⚠️ 注: このフォルダーはすべての Git シークレットが存在する場所です。手動で変更または削除しないでください。
なぜステージングエリアが必要なのでしょうか?
これは初心者にとって最も一般的な質問です。なぜファイルをバージョンとして直接保存できないのですか?また、なぜ途中に「一時保存」を追加する必要があるのですか?
答えは次のとおりです。ステージング領域を使用すると、次のコミットに何を含めるかを微調整できます。
大規模なリファクタリングが完了したと想像してください。index.html を変更し、3 つの新しい JS ファイルを追加し、実験用コードの半分を作成しました。まず、index.html と関連ファイルのみを選択して一時記憶領域に保存し、それをクリーンなコミットとして送信し、書きかけの部分を作業領域に残すことができます。一時ストレージ領域がなければ、すべてのアーカイブは「1 つのポット」になります。一時ストレージ領域を使用すると、すべての送信を論理的に完全なスナップショットにすることができます。
4. ローカル ワークフロー: 変更 → 追加 → コミット
まだ作成されていない、index.html と README.md を含む To Do アイテムがあるとします。最初のバージョンを保存するには:
git status
git status どのファイルが現在追跡されていないのかが表示されます。Git はこれらのファイルを検出しましたが、まだその内容の記録を開始していません。このコマンドは、「その場で確認する」という習慣を身につけるべきです。これは、Git と通信する主な方法です。
次の 2 つのステップ:
後ですべてのファイルを保存したい場合は、次のコマンドを使用して、ワンクリックですべての変更を現在のディレクトリに追加できます。
git add .
いくつかの重要なポイント:
- commitは「バージョン」の正式名称です。 Git の文脈では、「バージョンを保存する」とは言いませんが、「コミットを送信する」とは言いません。送信履歴はコミット履歴とも呼ばれます。
- 情報の送信
-m慎重に書いてください。半年後にコードを見返してみると、"第一次提交"、"修改"この種の情報は書き込まれていないのと同じです。"完成顺序表代码"、"修复分页越界 bug"貴重な道路標識です。
コアループは次のとおりです。コードを変更 → git add → git commit毎日の現地業務の 90% をカバーします。
Time Machine: 表示と巻き戻し
各コミットには一意の ID があります。変更された場合はどうすればよいですか?
git checkout -- <文件名>
安全かつ正確。
git reset --hard
⚠️これは破壊的な操作です。このコミット後の変更は永久に破棄されます。実行前に必ずご確認ください。
これがそもそもアーカイブの意味です。コードが認識できないほど変更されたり、ファイルが削除されたりした場合でも、コミットから復元することができます。
5. GitHub: アーカイブをクラウドに移動する
ゼロから: 既存のプロジェクトをプッシュする
まず、GitHub Web サイトをクリックします。 New Repository 空のウェアハウスを作成し (競合を避けるため、初心者は初期化 README を確認しないことをお勧めします)、ウェアハウスのアドレスを取得します。それから：
originこれはリモート ウェアハウスに与えられた別名であり、慣例によるデフォルト名です。branch -M main現在のブランチの名前をメインブランチ main に変更します。push -u origin mainまず一押し、-uローカル ブランチとリモート ブランチの間で追跡関係を確立し、直接git pushそれでおしまい。
初めてプッシュすると、Git によってブラウザがポップアップ表示され、ログインして GitHub を認証できるようになります。認証が成功したら、ターミナルに戻り、完了するまで待ちます。
ゼロから: 既存のプロジェクトのクローンを作成する
他の人のプロジェクトで作業したい場合、または別のコンピュータで作業を続けたい場合は、次の手順を実行します。
git clone 仓库地址
クローンは、コードを自動的にダウンロードし、履歴を完了し、発信元のリモート アドレスを 1 ステップで構成します。
毎日の同期
複数人でのコラボレーション (1 人でも複数のデバイスを使用する場合) の鉄則:毎日仕事を始める前に git pull を実行する最新のリモート変更を取得し、競合の可能性を減らします。
よくあるエラーを簡単にチェック
remote origin already exists: リモート アドレスが最初に追加されました。git remote remove origin再度追加します。- プッシュが拒否されました: まず、リモートにはあなたが持っていないコミットがあります
git pull origin main結合後にプッシュします。 - GitHub ページが更新されていない: を使用してください
git status追加、コミット、またはプッシュのリンクが抜けていないかどうかを自己検査してください。
6. 高度なトピック: SSH と複数のアカウント管理
HTTPS プッシュに加えて、より専門的な接続方法として SSH キー認証があります。原則は非対称暗号化です。秘密鍵と公開鍵のペアがローカルで生成され、公開鍵は GitHub の SSH 鍵設定に入力されます。プッシュするとき、秘密キーはローカルで「署名」に使用され、GitHub はアップロードした公開キーを使用して「署名を検証」します。合格すると公開されます。秘密キーはコンピュータから離れることはなく、安全でパスワードもありません。
会社の GitLab と個人の GitHub を同時に使用する場合、複数のキーのセットを生成できます。 ~/.ssh/config ホストごとに異なる秘密キーを指定します。同じプロジェクト内のユーザー名メールも使用できます git config --local グローバル構成を個別にオーバーライドします。
注: GitHub では、2 つのアカウントが同じ公開キーを共有することは許可されていません。マルチアカウントのシナリオでは、アカウントごとに独立したキーを生成し、構成で異なるホスト エイリアスを構成する必要があります。クローンを作成するときは、ウェアハウス アドレスの github.com を対応するエイリアスに置き換えるだけです。
7.最後に書く
振り返ってみると、Git と GitHub のナレッジ システムはパイプラインに圧縮できます。
ワークスペース (コードの作成) → ステージング領域への追加 (コンテンツの選択) → ローカル履歴へのコミット (アーカイブ) → GitHub へのプッシュ (クラウド バックアップ) → クローン/プルによる他のデバイスや他のデバイスとの同期
このパイプラインを理解すると、残りのコマンドはパイプライン上の単なるバルブになります。まずはマスター変更-追加-コミット-プッシュこの最小限のサイクル、次にログ/リセットを使用してタイム トラベルを学習し、最終的には分岐とマージ (次の段階の高度なコンテンツ) を通じて真のチーム コラボレーションに移行します。その時点で、あなたが手に持っているものは、もはやバックアップ ツールではなく、完全なプロジェクト タイム マシンになります。
