こんにちは、ペンすけです！
今回はJavaじゃなく、Gitのお話です！
バージョン管理のためのGit！？
クラウドのファイル共有システムでよくない？
この記事では、 Gitで最低限これだけ使えればOK ということを、筆者の経験をもとにお伝えしていきます！
注意
個人の見解を整理したもので、実際のGitの処理と厳密には異なる部分があります。
Gitのイメージを掴むためのものとして参照ください。
Gitの基本はpull/commit/pushの3ステップ
ちなみに、筆者はgitを約6年間利用しているよ！
1. pull = 誰かの編集を自分のPCに取り込む
他の人が更新したファイルを、自身のPCに取り込む処理のこと！
自分のPC上のファイルが最新版の場合や、他の誰もpush(後述)していない場合は、pullは行われません。
最新状態のファイルを持っていたのに、1週間前のファイルを誤ってpullしてしまった、みたいなことは起こりえません！
2. commit = 自分の編集を記録する
「どのファイルのどの部分をどう更新した」という情報を記録する処理！
普段ファイルの編集をする際に行う「保存」を、1つの大きなまとまりとして集めた更新情報 と捉えるイメージしやすいと思います。
詳細な説明はこちら
例えば、「データベースにデータを追加する処理」を実装するとします。この実装プロセスを細かく分けると、「1.クラスの定義」「2. データベース接続処理」「3. INSERT文の発行処理」等、いくつかの機能に分けられます。
更に、「1.クラスの定義」の実装プロセスには「1-1. メンバ変数定義」「1-2. メソッド定義」等のプロセスが含まれています。更に、「1-1.メンバ変数定義」の実装プロセスには「1-1-1. ファイル作成」「1-1-2. 型宣言」….。
と、1つの処理を実装するのに膨大な編集とファイル保存を繰り返しているはずです。これらの膨大な保存処理を、「更新のチェックポイント」としてcommit処理でまとめているわけです。
3. push = 更新したファイルをアップロード
更新したファイルを他の人が参照してpullできるように、Githubにアップロードする処理！
pushされた「更新の記録」をもとに、Github上でファイルの更新が行われます。
他の人がその更新後のファイルをpullすることで、他の人のPC上に変更が反映されます。
Gitを使うことで、ファイルの復元が容易になる
結局Gitを使うメリットって何なのさ！
次のシチュエーションを仮定してみましょう。枠内は1commitで行った更新内容が記載されています。
ポリモーフィズムまで実装できたはずなのに、エラーが多発している。。。
…あ！！！
変更したクラス構造に致命的なミスがあるじゃん！
9/3以降のクラス構造の変更はなしにします！！！
この場合、2通りの修復方法が考えられます。
- 9/12時点の最新ファイルを編集して、クラス構造変更前の状態にする。ただし、少なくとも変更対象ファイル数は10個以上。
- Gitの機能を使って、クラス構造を変更する前の9/3時点の状態にファイルを戻す。
前者の場合、変更し忘れのファイルが出てきたり、、、、
何より前の状態にちゃんと戻せるか不安。。。
Gitを使っていると、ものの数秒で9/3の状態に戻すことができます。
9/3のファイル状態から再度、編集が可能となります。
当時は良かれと思って更新したけど、途中で不具合が発生してある時点のファイル状態に戻したい、という状況は開発していると起こり得るものです。
仮に2,3ファイルの数行の変更に対するコミットであっても、手動で更新してファイル状態を元に戻すのは経験上オススメしません。理由は「記憶にないほど小さな変更を見落とす恐れがある」「完璧に元に戻ったどうかの確認が困難」からです。
筆者は過去に手動で更新した結果、見事にプログラムを壊してしまいました。ついには修復不能なまでになってしまったので、最終的にはGitの機能を使って過去の時点に戻しました。
コメント