こんにちは。
Flutter でアプリを開発していると、時々「これから大きな変更を加えるぞ」というタイミングがやってきます。既存のコードを大幅に書き換える、複数のファイルを触る、複雑なリファクタリング…。
そんな時、私が必ず実行するのが「バックアップファイル(.bak)の作成」です。
一見、地味で古臭い作業に見えますが、これが実に奥深い。個人開発者として、Gitを使っていても .bak を使う理由、コマンドの実際、そしてリリース後の処理まで含めて、まとめてみようと思います。
なぜ Git だけじゃなくて .bak も使うのか
「Git でバージョン管理してるんだから、.bak なんて必要ないでしょ」と思うかもしれません。
正直、私も最初はそう思っていました。でも、大きな作業に取り掛かる直前の「精神的な安心感」という点で、.bak は絶大な効果があるんです。
Git は素晴らしいツールですが、「今の作業中の状態に、いつでも即座に戻す」という用途では、少し操作に手間がかかります。git stash や git checkout を使うことになりますが、慣れていないと「あれ?変更が消えた?」と焦る場面も。
一方 .bak なら、目に見える形でファイルが同じフォルダに残っている。「もし失敗しても、これに戻せば元通り」という視覚的な安心感が、思い切った作業を可能にしてくれます。
つまり Git は「時間をまたいだ厳密な履歴管理」、.bak は「今この瞬間の即席セーフティネット」。役割が違うんです。
いつバックアップを取るか
私の個人的な基準は、こんな感じです:
- 1つのファイルに 50 行以上のコードを追加する
- 既存のコードを削除する(追加より削除の方がリスクが高い)
- 複数の場所を編集する(部分的にミスしても気づきにくい)
- リファクタリング(構造そのものを変える)
- 不慣れなライブラリを使う
要は「もし失敗したら、頭の中で復元するのが面倒だな」と感じたら、迷わず取る、というルールです。
ターミナルでバックアップを作るコマンド
Mac(Linux も同じ)なら、cp コマンド一発です。
cp /path/to/original_file.dart /path/to/original_file.bak例えば、私が月謝袋アプリで使っているファイルなら:
cp /Users/xxx/flutter_projects/monthly_fee_stamp/lib/pages/create_post/create_post_widget.dart \
/Users/xxx/flutter_projects/monthly_fee_stamp/lib/pages/create_post/create_post_widget.bak.dart を .bak にリネームしたコピーが同じフォルダに作られます。
これで元のファイルを思い切って編集できます。もし何かおかしくなったら:
cp /path/to/original_file.bak /path/to/original_file.dartで復元できます。
複数回バックアップを取りたい時のちょっとした工夫
同じファイルを複数の段階でバックアップしたくなることがあります。例えば「機能A実装前」「機能B実装前」など。
そんな時は、名前にバージョンをつけるのがおすすめ:
cp create_post_widget.dart create_post_widget_v3.bak私は月謝袋アプリの開発で、v1.12 対応前は _v3.bak、v1.13 対応前は _v4.bak、と進化のマイルストーンごとに残していました。
こうすると、「あの段階まで戻したい」という時に選択肢がある安心感があります。
作業が完了した後の話 — ここが実は大事
さて、無事に作業が終わって、動作確認も済んで、コミットもできた。じゃあ .bak はどうするのか?
ここで大事なポイントが 2 つあります。
1. Git に .bak をコミットしない
.bak ファイルは、あくまで自分のマシンでの一時的なセーフティネットです。Git リポジトリには含めるべきではありません。理由:
- 開発中の作業用ファイルなので、他の人には意味がない
- リポジトリのサイズが無駄に大きくなる
- 「.bak が残っている」= 「作業が中途半端に見える」ので信頼性が下がる
そのため、.gitignore に *.bak を追加しておくのがおすすめです:
# バックアップファイル
*.bakこれを 1 度書いておけば、以後 .bak ファイルは Git に検出されなくなります。
もし .gitignore の設定なしで作業する場合は、git add の時に明示的に .dart だけを指定するのが安全です:
git add lib/pages/create_post/create_post_widget.dart
# .bak は含めない2. 作業完了後は .bak を削除する
コミットして動作確認も済んだら、.bak は削除します:
rm /path/to/original_file.bak理由:
- Git 履歴の方が信頼できる履歴なので、.bak を残す意味がない
- ワークスペースをクリーンに保つ
- Dropbox などクラウド同期の対象になっていると、無駄な同期時間がかかる
- 削除は勇気がいるが、Git があるから安心
私は毎回、コミットが完了したタイミングで .bak を削除する習慣にしています。「削除できる」ということは「作業が完全に完了した」という自分への合図でもあります。
Dropbox バックアップとの使い分け
.bak と別に、私は Flutter プロジェクト全体を Dropbox にも同期しています。これは全く別の目的です:
- .bak: 今作業中の 1 ファイルへの、短期的なセーフティネット
- Dropbox: プロジェクト全体を、別のマシン・別の日時に復元できるアーカイブ
- Git: すべての変更履歴を厳密に追跡できるバージョン管理
3 つが役割分担していて、それぞれ違うシーンで助けてくれます。
まとめ
.bak ファイルはたった 3 文字の拡張子ですが、そこには「大胆に挑む勇気」と「後始末の丁寧さ」という、開発者としての姿勢が凝縮されています。
私は 30 年近く Web デザインの仕事をしていて、その頃から「作業前のバックアップ」は染み付いた習慣でした。ツールが Git やクラウドに進化しても、「触る前に、目の前で確実にコピーを取る」という古典的な安心感は、今でも変わらず大切だと感じています。
もしまだ .bak を使ったことがなければ、次に何か大きな変更を加える時、試してみてください。「もし失敗しても大丈夫」という安心感が、思い切った実装を可能にしてくれるはずです ✨
リンク
