この記事は、SearchBank アドベントカレンダー 3日目の記事です。
あなたは新しい開発プロジェクトが始まったら、最初に何をしますか?
チームメンバーとの挨拶、クライアントとのミーテイングの設定、事前資料の整理。。。
どれも必要な事ですが、僕の場合はGitリポジトリを作成するところからはじめます。
GitLab や GitHub といった Git リポジトリのホスティングサービスには、イシューチケットの管理やコミュニケーション、wikiによるドキュメンテーションなど、プロジェクト管理において有用な機能がそろっています。
そのため、円滑なプロジェクトマネジメントをするためにも、Gitリポジトリの作成は、ほかの何より優先しておくことが望ましいと考えます。
Git リポジトリを作成する際には、最初のコミットが肝心です。
README ファイルを作成してコミットするのも悪くないのですが、どうせならまっさらなコミットからはじめてみませんか?
というわけで、Gitリポジトリを「空コミット」で始める方法をご紹介します。
新しいリポジトリを空コミットで始める場合は、次のコマンドを実行します。
$ git init
$ git commit --allow-empty -m "first commit"
git init は、Git に慣れている人にはおなじみの、新しい Git リポジトリを作成するコマンドですね。
続く、git commit --allow-empty -m "first commit" が今回のポイントです。
git commit でコミットする際には、通常はファイルがステージングされている(addされている)必要があり、何もなければ警告が表示されてコミットできません。
しかし、 --allow-empty オプションを付けることで、空のコミットが実現できます。
上記のコマンドでは、最初のコミットを意味するコメント "first commit" を -m オプションで、コミットのメッセージに付けています。
「空コミット」で始める理由は、不要なトラブルを避けるためです。
「最初のコミットは編集しづらい」という問題点があり、これを回避することができます。
もちろんほかにも回避策はあるのですが、たとえば最初のコミットにファイルを追加したい場合は、 git commit --amend で、最初のコミットも内容を書き換える等、ユースケースに応じて凝った解決方法が必要になります。
git rm 最初にコミットしたもの
git add 本当に追加したかったもの
git commit --amend -m "最初のコミット"
空コミットをファーストコミットにした場合は、実質的なコミットは2番目のコミットからになるため、一般的なGitコマンドでの修正がしやすくなります。
ほかにジョーク的なメリットとして、テンションがあがるという効果もあります。
「またゼロからやり直そう」「次はうまくやってみせます」なんて、異世界転生小説のようなセリフが開発現場で飛び交うのはクールでしょう(まあ、そんな場面があったら炎上してそうですが)。
注意点があるとすれば、空コミットを「意味のないコミット」と嫌う人が存在します。
(空コミット派からすると)あえて不便になるように感じますが、rebaseコマンドは破壊的なコマンドなので使用を控えるべきというのも一理あります。
そのため、プロジェクトに導入するかどうかは、開発チームによって判断すべきでしょう。