星田さんの記事に対するコメント。
> 2022/10/31
で、早速ヤッてみたんだけど・・プッシュで絶対にエラーが出るんですよね。エラーメッセージで調べて色々と試すけど駄目。うーん？判明、サーバーって自分で用意しないといけないのかｗ
うん、まずgit pushはいらない(笑)。多分、個人でGitを使うならそもそもサーバーを使う必要がない。
う〜ん・・・どうしよう。
ちと説明しよっか。そうしないと何故にGitを薦めた、ってのも意味が分からなくなるかもしれんし。
Version Control System(VCS: ヴァージョン管理システム)ってのは歴史がそこそこあるんだけど。
元々、会社とかで開発に使われる前提で開発されたんで、確かにサーバーがあって、子機があって、って言うモデルが最初に出てきたのよ。言い換えると「開発されたコードを纏める」主があって、他の実際にプログラムを書く「子機」が従、ってシステムだな。
このモデルを集中型ヴァージョン管理、と呼ぶ。そして「レポジトリ」と言う履歴管理の仕組みは絶対的にサーバーしか持ってない。
このテのシステムで、オープンソースでGit以前に人気があったのがSVN(Subversion)ってソフトだな。
ところが、特にオープンソースのソフトだと世界中に散らばった開発参加者がいて、特に時間が決まってないのに任意の時間に中央サーバーに「書いたコードを上げる」となると色々と問題が生じたわけよ。どれが最新の、しかも「正しく」動くブツなのかパッとは分からん、と。そうすると、「管理の方法を考えなアカンな」って状態になってきたわけ。
一番深刻な事態に陥ったのがご存知、Linuxのカーネル開発だ。「集中型ヴァージョン管理じゃアカン」って事がかなり早い時期に分かってて、多分総初期の商用分散型ヴァージョン管理ソフトのウチの1つ、BitKeeperってのを使ってた。
ところが、ここが、フリー版提供を止めたんだよ。「これからBitKeeperを使うなら金払え」ってなったワケだ。
ここでアタマに北半球だったのがリーナス・トーバルズだ。
「この野郎、じゃあ、BitKeeperを超える分散型ヴァージョン管理システムを作ったろうじゃねぇか。」
ってぇんで一時期Linuxカーネルの開発をストップして、作り上げたのがgitと言うワケだ。言い換えるとLinuxカーネル作成にどうしても必要なシステムとして作ったのがgitって事だな。
さて、この分散型ヴァージョン管理と言うシステム。概念的には次のような図になる。
主である筈のサーバーが消えてしまった。そして全ての開発用コンピュータがレポジトリを抱えていて、言わば全部の開発用コンピュータが主であり、それらがネットワークになっている。
つまり、言い換えると、ある種、全部のPCが集中型ヴァージョン管理のシステムを独自に持ってて、それらが全部お互いにネットワークでつながってる、ってのが分散型ヴァージョン管理システム、ってモデルなんだ。
実際は、自分の持ってるリポジトリを、例えばインターネット上に敢えて公開しなければネットワークにはならないわけだけれども、言い換えると自分で開発するコードに関するヴァージョン管理機能は自分のローカルリポジトリだけで完結出来ると言う事だ。だからこそ個人開発に向いてもいる、ってわけ。
もう一つ、実際の会社での開発ではサーバーに開発結果を上げなければならないだろう。しかし、それは主だから、じゃなくって基本的にはサーバーでさえ分散型ヴァージョン管理システム内での1つのリポジトリ以上の意味がない、って事だ。
また、おなじみのgithubでさえ集中型ヴァージョン管理システムのサーバーと言う意味ではなく、やっぱり数多くあるリポジトリの内の1つでしかない、ってわけだ。分散型ヴァージョン管理システム、ってのはそういうモデルなわけ。
言い換えると、例えばgithubをサーバー扱いしたとしても、それはシステム上は便宜上って言う意味以上じゃないのね。
そしてその便宜上、で使う目的なのがgit pushなワケなの。だからサーバーを用意する必要もないし、無理に使うコマンドではないわけだ。だって自分のPCの開発用フォルダにリポジトリを設定しておけばそれ以上求める必要がない、ってばないわけだからね。それだけで個人ユースでは完結してるわけ。
だから入門Gitだと6章くらいまでの知識でイイの。それ以降になると会社で使ったりする人向け。つまり、大勢で開発する際のノウハウになる。
言い換えると必須コマンドは
- git init
- git add
- git commit
- git branch
- git checkout
- git merge
の6つくらいしかねぇんじゃねぇかな。もちろん他にも使えるコマンドはあるけど、必須、って言えばこれくらいで、かつこれくらいはtortoiseGitの右クリックでほぼカヴァーしてる筈だ。
そして開発用フォルダに作ったローカルリポジトリのmasterからガンガンbranchを切って開発していく。上手く行ったヤツだけmasterにmergeする。それだけで充分なんじゃないかな?
とにかく「多人数で開発する」スタイルは取らんでエエ。従ってサーバーを求める必要も全然無いんだ(そんなメンドくせぇシステムは紹介したくない・笑・※)。
> 2022/11/01
早速まずはラベル方式レコード型方式を写経して動かしてみる・・・が・・あれ？Nodeの引数の数が合わないが？
そうね、プログラミングの基礎の演習問題17-10がそこにあたる。
そしてもう一回タグ付きデータ方式のファイル構成を見てほしい。最短経路問題での木のデータ構造(つまり演習問題17-10)がまるっと消えてるのが分かるだろう。
タグ付きデータ方式ならこのテの形式的なデータ設定は全く必要がなくなる、からだ。
※: なお、分散型ヴァージョン管理システムでgitと人気を二分するフリーソフトウェアにMercurialがある。
表面的には、オープンソースソフト開発者に人気のgit、企業での商用ソフト開発に人気のMercurialってカンジになってるんじゃないか。
参考資料: => 分散バージョン管理で間違いないって、ベイビー
