⇧ amazing...
Gitとは？
Wikipediaさんによりますと、
Git (/ɡɪt/) is a distributed version control system that tracks changes in any set of computer files, usually used for coordinating work among programmers who are collaboratively developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows (thousands of parallel branches running on different computers).
Git was originally authored by Linus Torvalds in 2005 for development of the Linux kernel, with other kernel developers contributing to its initial development.
⇧ コンピュータ上のファイルのバージョン管理ができるシステムで、分散バージョン管理システムの1つですと。
Since 2005, Junio Hamano has been the core maintainer. As with most other distributed version control systems, and unlike most client–server systems, every Git directory on every computer is a full-fledged repository with complete history and full version-tracking abilities, independent of network access or a central server.
Git is free and open-source software shared under the GPL-2.0-only license.
⇧ 多くの「client-server systems」とは異なりますと。後述しますが、Gitは「スナップショット」という仕組みを利用している点が特異らしい、たぶん。
Gitでファイルをバージョン管理する流れは、
⇧ 上図がイメージし易いかと。
「Remote repository」を元に「Local repository」を各々のパソコンに構築して、最終的な成果物を「Remote repository」に配置することで、複数の作業者で状態を共有して作業できますと。
Wikipediaさんによりますと、
広い意味でクライアント・サーバと呼ばれる場合、前述のようにクライアントとサーバと処理を役割分担している分散コンピューティングのことを意味することがある。この場合、サーバがさらに数層分けられる多層アーキテクチャを含める場合がある。
⇧ とのことらしいので、
上図の黒い太線の左側（「Local repository」ある方）がclientで、右側（「Remote repository」がある方）がserverと見なして良いとすると、Gitも「client-server model」と言えるのだと思う。
git checkout コマンドの役割多過ぎ問題
git checkout コマンドの役割多過ぎ問題の前に、GitHubの公式のブログによると、
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません!
https://github.blog/jp/2021-01-06-commits-are-snapshots-not-diffs/
⇧ とのこと。なるほど、Gitに対する妙な違和感のようなものは周知の事実であったと。
「スナップショット」はと言うと、
あるファイル・ディレクトリ群をバックアップする際に、対象中のファイルがバックアップ処理中に更新されると、ファイル・ディレクトリ相互の整合性が合わなくなる可能性がある。バックアップ処理開始近辺にバックアップされるファイルと、処理終了近辺にバックアップされるファイルとでは、各々がバックアップされる時刻が異なっているためである。更新のかかるデータベースファイルや、メールサーバのスプールフォルダなどのバックアップでは、このような時刻のずれに対処しないと不整合が起きやすい例である。
そこで、ある一時点のファイル・ディレクトリの状態を統一的に保持してその内容（またはその内容から得たスナップショットデータ）をバックアップすることで、ファイル・ディレクトリ相互の時間的整合性を保つために導入される仕組みの一種が「スナップショット」である。
⇧ とありますと。
⇧ 「スナップショット」には、2種類あると言っており、Gitの「スナップショット」はどっちに当てはまるのかね？
Gitの「スナップショット」については、
⇧ 上記サイト様が、詳しいです。
git commit コマンドの説明によると、
git commit
The git commit command takes all the file contents that have been staged with git add and records a new permanent snapshot in the database and then moves the branch pointer on the current branch up to it.
⇧「スナップショット」は何某かのデータベースに保存されるとありますな。
話が脱線しましたが、で、Gitには、git checkout ってコマンドが用意されているようなのだけど、
⇧ 上記サイト様によりますと、大きく分けて、4つの使い方に分かれるんかな。
- ブランチ切り替え
- ブランチ作成もする
- ブランチ作成はしない
- 過去のファイルの状態を復元する
- 状態の変更を取り消す
そもそも、Gitの公式のgit checkoutのコマンドのドキュメントだと、7つの用法があるらしいので、初見殺しにも程があるかと。
曖昧な理解でコマンドを利用すると漏れなく憤死するパターンですな...
おそらく、要望が多かったんだとは思うけども、git checkoutの一部の役割を担う目的で、
- git switch
→ブランチ切り替え - git restore
→状態の変更を取り消す
ってコマンドが、Gitのバージョン2.2.3から試験的に導入されてるらしい。
まぁ、何が言いたいかと言うと、
単一責任の原則 (たんいつせきにんのげんそく、英: single-responsibility principle) は、プログラミングに関する原則であり、モジュール、クラスまたは関数は、単一の機能について責任を持ち、その機能をカプセル化するべきであるという原則である。モジュール、クラスまたは関数が提供するサービスは、その責任と一致している必要がある。
⇧ って大事かなと。
まぁ、コンポーネントとして複数の処理をまとめて提供したいこともあると思うので、どこまで機能を盛り込むべきかの判断は難しいのだけど...
けれども、ソースコードを読む部分で認知負荷を減らせるところは極力減らしていきたいかな、人間だもの。
変更容易性の低いソースコードだと、結局のところ、保守・運用や追加開発でコストが嵩むことになるものね...
このあたりは、開発工数とのトレードオフになるとは思うけども...
ちなみに、Javaだと、
1つのメソッドの中でいろんな処理を行っているため、メソッドが長くなっています。きちんと役割分割されたプログラムのメソッドは、10行程になるといわれています。
1メソッドの行数はコメントを含めて20行以下にするのが望ましいです。1メソッドの行数が20行を超えるようであれば、他に分割すべき点がないか、もう一度コードを読み直してみて下さい。
メソッドの役割を1つにすれば、必然的にメソッドは短くなります。メソッドが短くなればソースコードを見て理解することも簡単になります。理解することが容易になれば、修正箇所をすぐに把握することができ、ソースコードの保守性が向上します。
⇧ だそうです。
ちょっと、20行以下はシビア過ぎる気がするけども、基本的には、メソッドは、小さく分割していくのが良さそうです。
話が脱線しましたが、Gitの紛らわしさと向き合わねばですが、う～ん、ソースコードの管理とかに労力をかけたくないんだけどな...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
