このREADME.mdファイルは、Railsチュートリアルのテンプレートからcodespacesで環境構築した時に自動生成されました。ファイル名の拡張子が「.md」となっているファイルは、Markdownという人間にとって読みやすい記法を使って書きます35。Markdownは簡単にHTMLに変換できるため、GitHubでもMarkdownで書かれたREADME.mdファイルをHTMLで表示してくれます。Railsが自動生成したREADMEをそのまま使ってもよいですし、プロジェクトに合わせて内容を書き換えても構いません。いえ良い練習になるので、今回はREADMEを書き換えながらGitの使い方に慣れてみましょう。具体的には、Gitの基本的なコマンドであるブランチ(branch)、編集(edit)、コミット(commit)、マージ(merge)の4つを紹介します36。CodespacesテンプレートのデフォルトREADMEの表示Gitのブランチ(Branch)Gitはブランチ(branch)を簡単かつ高速に作成できます。ブランチとは基本的にはコード全体のコピーで、元のコードにいつでも戻れる状態を維持しながら、新しくコードを追加したり変更したいときに便利です。通常、大元のコードがあるリポジトリはmainブランチと呼ばれ、ブランチを新たに作りたいときはswitchと-cオプションで作成できます37。branch)は、ローカルブランチの一覧を表示します。「*」は現在使用中のブランチを表しています。modify-READMEコマンドで、新しいブランチの作成と、そのブランチへの切り替えが同時に行われている点にご注目ください。modify-READMEブランチに「*」が付いているので、現在はmodify-READMEブランチにいることが分かります。以後、このような新たに作成したブランチを本書ではトピックブランチと呼びます。トピックブランチは他の開発者と共同作業するときにその真価を発揮しますが38、本チュートリアルのように1人で作業するときでも有用です。modify-READMEブランチで行った変更はmainブランチに影響しないため、たとえば試行錯誤を繰り返してコードがめちゃくちゃになってしまってもmainブランチに戻れればいつでも元の状態に戻せますし、もしもう一度書き直したい場合はmodify-READMEブランチごと削除することもできます(具体的な方法は本章の最後で説明します)。ちなみに、通常このような小さな変更のためにわざわざブランチを作成する必要はありませんが、「よい習慣を身につけるのは早ければ早いほど望ましい」ので、今のうちに少しでも練習して慣れておきましょう。GitHubのデフォルトブランチ名について2020年10月、GitHubからアナウンスがありました。それは新規作成されるリポジトリのデフォルトのブランチ名が、従来のmasterからmainに変更されたというものです。デフォルトブランチ名が変更された理由についてはWikipediaに譲りますが、masterもまだ広く使われているため、皆さんが今後ドキュメントや書籍などでmasterというブランチ名を見かけることもあるかもしれません。その場合は適宜mainに読み替えて理解すると良いでしょう。Tutorial(英語)」をご参照ください。statusコマンドで現在の状態を確認してみましょう。mvで作成したファイルも含む)をまとめてコミットする-aオプションもあります。このオプションを使うと、以下のようにコミットすることもできます。-Aでは、意図していないファイルを誤ってコミットしてしまう可能性もあるため注意が必要です。commitでコミットしましょう。commitのコミットメッセージを英語で書く場合は現在形かつ命令形で書くようにしましょう39。いうのも、コミットメッセージではそのコミットが「何をした」のかを書くよりも、「何をする」ためのものなのかを書く方が後から見返したときに分かりやすくなるからです。)とも時制が一致します。「Gitにコミットするとは」をご覧ください。Gitのマージ(Merge)ファイルの変更をコミットし終えたら、mainブランチにこの変更をマージ(merge)します。deletions(-)上の例では015008cと表示されていますが、これはGitが生成するランダムな文字列(ハッシュ)のため、一致しなくても大丈夫です。ハッシュの値は環境によって多少異なりますが、他の部分はほとんど同じように表示されるはずです。-dを実行してトピックブランチを削除しましょう。015008c).なお、トピックブランチの削除は必須ではありません。実際、トピックブランチを削除せず、そのままにしておくケースもあります。トピックブランチを削除せずに残しておけば、トピックブランチとmasterブランチを交互に行き来して、キリの良い所で変更をマージすることもできます。branchの-Dオプションを使った、マージ前のトピックブランチを破棄する方法も紹介します。これはあくまで例です。誤ってブランチを作ったとき以外は実行しないでください。topic-branch-dオプションと異なり、-Dオプションは変更をマージしていなくてもブランチを削除できます。Push(プッシュ)READMEファイルの更新が終わったので、プッシュ(push)コマンドでGitHubに変更をアップロードしてみましょう。pushでも実行できるはずです。push無事にアップロードできたら、GitHub上にあるhello_appのページを確認してみましょう。デプロイする1.4で学んだGit/GitHubの使い方を応用すると、作ったRailsアプリを本番環境のサーバーへアップロードし、世界中に公開できます。そこで本セクションでは、この一連の作業「デプロイ」を体験してみましょう。デプロイがうまくいかなくても次の章に進めるのでご安心ください。いえこまめにデプロイすることで得られるメリットもあります。10,000行のコード変更をまとめてデプロイして失敗すると、10,000行の変更の中からバグを見つけなければいけません。10行のコード変更のデプロイであれば、その10行を確認するだけで済みます。なって思わぬトラブルに遭わないためにも、本チュートリアルではこまめにデプロイする方針を採っています。本チュートリアルではRenderを採用しています40。Renderはソースコードのバージョン管理にGitを使っていれば、作ったアプリを簡単にデプロイできるサービスです。本チュートリアルではPostgreSQLなどの本番環境用のデータベースを使わなくても学べるようになっていますが、RenderにはPostgreSQLを無料で一定期間使える機能も付いているため、完走後に本格的なプロダクトを作りたい場面でもスムーズに移行できるようになっています。41さて、それでは早速「Helloアプリ」をRenderにデプロイしてみましょう。初めに、デプロイに必要なファイルを準備します。Codespacesで進めている場合はセキュリティ上の理由からconfig/master.keyファイルが削除されているため、以下のコマンドを実行してconfig/master.keyとcredentials.yml.encを作成しましょう。コマンドを実行するとcredentials.yml.encファイルが開きますが、変更を加えずにそのまま閉じてしまって大丈夫です。ファイルが開きますが、変更せずに閉じてください。credentials.yml.encとconfig/master.keyの役割、および各ファイルのセキュリティ上の注意点などについてはRailsガイドまたは解説動画をご参照ください。ファイルを作成/変更したら、Gitコマンドでコミットし、GitHubにプッシュしましょう。mainこれでデプロイの準備は完了です。次に、デプロイで使うRenderのユーザー登録をしましょう。