幼い頃、私は偶然 C++ の世界に足を踏み入れ、長年愛されている「Hello World」プログラムを作り上げました。それをコンパイルして実行すると、「プログラミング」への進出が成功したことを確認するポップアップが表示されました。
しかし、私はそれ以上のことはしませんでした。12 歳の私にはバージョン管理のプロセスが... 最悪だったからです。ソース コードを紛失し、1 週間後にまた戻ってきて、新しいファイルを最初から作り直すという作業を繰り返していました。C++ でちょっとした作業をして遊んで進歩はしましたが、ソース コードの管理が下手だったため、そのたびに基本的にゼロからやり直す羽目になりました。
ビルドするたびに進捗がすべて失われることほど、コードで作業したいという意欲をすぐに殺してしまうものはありません。この問題の解決策は Git、つまりこの場合は GitHub です。パート 3 のこの小さな Terraform デプロイを、VSCode の組み込みターミナルでいくつかの基本的な Git コマンドを使用して GitHub に配置します (これを行うための VSCode Github 拡張機能がありますが、拡張機能に頼る前に、このタイプのタスクを実行するために使用される Git コマンドを理解しておくことをお勧めします)。
これらの手順では、OS のネイティブ ターミナル (CMD、Powershell、ZSH など) を使用することもできます。
「CTRL + `」(バックティック、つまり「1」の左側にある小さなキー)を押して、VSCode でターミナルを開きます。
この新しいターミナルで、正しいファイル ディレクトリにいることを確認します (デフォルトで正しいディレクトリになっているはずです)。次の手順では、このフォルダーで Git リポジトリを初期化し、コードの変更の追跡を開始します。これがコードがあるディレクトリでない場合は、正しいディレクトリに変更します。
ここでGitを初期化します。これを行うには、 git init
。
Git は現在このディレクトリで実行されていますが、ファイル (またはそれらのファイル内のコード) は追跡されていません。
Git は、ローカル コード リポジトリだけでなく、リモート コード リポジトリ (「リポジトリ」) も使用できます。ほとんどのプロフェッショナルな設定では、Github、Gitlab、Bitbucket などのサービスでリモート リポジトリを使用します。追跡するコードをどこに送信するかを Git に指示する必要があります。そのためには、 git remote add
使用します。
構文は次のようになります: git remote add origin https://github.com/owner/repo_name.git
これを分解すると、 git remote add origin
gitに「origin」という名前のリモートリポジトリを追加し、その後のURLをこのリモートリポジトリの宛先として使用するように指示します。
私の場合は、自分のアカウントで GitHub に新しい (空の) リポジトリを作成したので、次のようになります: git remote add origin https://github.com/wellmadeoldfashioned/YT-single-server-arch-AWS.git
ここで、git にファイルを「追跡」するように指示します。特定のファイルを追跡するには、 git add [filename]
実行します。または、現在のリポジトリ内のすべてのファイルを追跡するには、 git add .
実行します。通常は、明示的に個々のファイルを追加し、ローカル ディレクトリ内のすべてのファイルを追跡しないのが最適です。
では、Terraform ファイルを追加しましょう。そのためには、以下のコマンドを実行します: git add main.tf
この時点で、前の手順で追加したファイルは「ステージング」されています。これは、Git に「これらのファイルのコピーを現状のまま取得し、そのコピーをリポジトリ (この場合はリモート リポジトリ: Github) に送信する準備をする」ように指示したことを意味します。
ファイルがステージングされたら、コミットを作成する必要があります。これは、開発の進行状況におけるチェックポイントのようなもので、チェックポイントを説明する短いメッセージを追加できます。
コミットをステージングするには、 git commit -m “[message_goes_here]”
を使用します。最初のコミットでは、"initial commit" のような内容を使用するのが慣例ですが、メッセージに何を入れるかというルールはありません。一般的に言えば、簡潔で説明的な内容にする必要があります。たとえば、変数名を更新するコミットの場合は、 git commit -m “updated AMI variable to XYZ”
とだけ記述します。
ここで、 git commit -m “initial commit”
実行します。次のような Git からのフィードバックが数行返されます。
これはほぼ完了ですが、まだ完了ではありません。Git を初期化し、リモート リポジトリを追加し、Git に特定のファイルを追跡するように指示し、リモート リポジトリへのコミットをステージングしましたが、コミットをリモート リポジトリにまだ送信していません。
コミット(上記でGit commitコマンドを使用して作成した「チェックポイント」)を送信するには、 git push [remote-repo-name] [local-branch-name]
を発行する必要があります。
リモート リポジトリ名を確認するには、手順 4 に戻って、どのような名前を付けたかを確認する必要があります。この場合は、「origin」です。ローカル ブランチ名を確認するには、 git branch
を発行するか、デフォルト設定を変更していない場合は、マスター ブランチの場合は「master」になります。
ご覧のとおり、私たちは実際にローカルのマスターブランチで作業しています。したがって、コードをGithubにプッシュするには、 git push origin master
を発行する必要があります。
GitHub 側で確認すると、先ほど送信したコミットを確認できます。
実際のコミットの変更も同様です:
これが Git と GitHub を使い始めるのに役立つことを願っています。この実用的なデモでは、単純化のためにいくつかのショートカットが使用されています (マスター ブランチを保持するために新しいブランチを作成しない、変更をマージしない、フォークするなど)。ただし、この知識は、それらのことを学ぶための基礎となります。
このように Git を使いこなせるようになったら、さまざまなブランチでの作業に移り、「HEAD」とは何か、それをどのように操作するか、リポジトリをフォークするか、変更をマージするかなどを理解していく必要があります。