SCCS → RCS → CVS → subversion (+ VSS, Perforce) → git と使ってきましたが、確かにgitの手前のギャップは他の移行よりも大きかったです。その理由は、背後にあるモデルが大きく変わったからです。

subversionまでは「履歴管理」ですが、gitは「パッチの有向グラフ」なんです。ただ、最初にこれだけ聞いてもわからないんじゃないかと思います。私はわかりませんでした。2000年代初めに分散バージョン管理システムのarchを設計していたTom Lordが「分散バージョン管理システムをちゃんと動かすには履歴管理でなくパッチの依存管理にしないとだめだ」と言ってて、でも私はパッチの管理って履歴管理と同じことじゃないの、と思ってたんですね。

gitを使い始めてしばらくはそれまでのチェックアウト/チェックイン/マージをgitのワークフローに当てはめようとして、なんだかよくわからないなあ、と思ってたんですがある時「ああ、単にパッチの有向グラフがあって、ブランチやタグはグラフのノードについたラベルにすぎないんだ」と気づいたらなぜgitのコマンド体系がああなっているのかすっきりわかりました。そこでやっとTom Lordが言ってた意味もわかったんです。

今はgitがとりわけ難しいとは思わないんですが、「有向グラフの操作だよ」というのを読んだり聞いたりするだけじゃなく、自分で操作して腑に落ちないと、とても取っつき辛いだろうと思います。敢えて言えば、履歴を記録しているのではなく、履歴を作っているのだ、という発想の転換でしょうか。

Subversionを10年近く利用してからGitに移行し、散々苦労しました。

その理由は、なまじSubversionと似ている用語があるにも関わらず、根本的な考え方が異なるからだと今は考えています。

いえ、私は分散リポジトリの話がしたいのではありません。それはMercurialやBitkeeperなども使っています。私は何度も同僚から、Gitが難しいのは分散リポジトリだからだと聞かされました。

違います。

Gitの最も大きな特徴だと私が感じるのは、その管理対象が伝統的なソースコード管理と異なる点です。

私が親しんできたSubversionは、ソースコードを変更してコミットすると、以前のバージョンからの差分をデータベースに保存します。これは合理的で自然な考えだと思います。巨大なシステムでも、バグ修正や機能変更は多くの場合ソースコードの一部を書き換えるだけで終わるからです。変更していない残りのソースコードまで保存するのは全くの無駄です。

しかしGitでは、全てのソースコードを保存します。私が数千行あるソースコードの中で2〜3行変えただけでも、Gitは全く新しい、元のファイルと2〜3行しか違いのない数千行のファイルを作成して保存します。これはデータ量の観点からは非常にナンセンスな、非合理的な動きに見えます。

これに何の意味があるのでしょうか？

それは、1つのコミット情報さえ有れば全てのソースコードが復元できると言う点にあると思います。個々のコミット履歴は自分だけで完全なソースコード一式を復元できるので、お互いに独立した、粗な関係を維持しています。

Subversionでは差分を管理し、あるコミット時点での完全なソースコードを得るには最初のコミットから全ての差分を適用するという考えでした。Gitはその逆で、完全なソースコードを管理し、変更差分を得るには直前のコミットと比較して得ています。発想がSubversionやMercurialとは真逆なのです。

全てのコミット履歴が自分だけで完全なソースコードを再現できる、コミット間の連結は単に変更差分を計算するだけ…となると、コミット履歴の操作は随分と自由になります。

私の作業ブランチのベースとなったmasterブランチに、同僚が不具合修正をコミットしたとします。私はrebaseにより、自分の作業開始があたかも同僚のコミットの後から始まったかのように操作することができます。

せっかく自分の修正をコミットしたのに、1ファイルだけコミットが漏れていることもあります。commit --amendで、私は先ほどのコミットに最初からそのファイルが含まれていたかのように操作できます。

関連した修正が連続するよう、コミットの順番を操作することもできます。

Subversionでは、コミット履歴は決して揺るがない不変の厳然たるまさに歴史そのものでした。しかしGitではその歴史を変えることができるようなデータ構造になっており、私も同僚も好きなタイミングで自由に各々の歴史を書き変えることができます。

それが良い場合もあるでしょうが、共通リポジトリの歴史を勝手に書き換えられるとトラブルの元になります。rebaseをすると、コミットメッセージは同じでも40桁のハッシュ値は変わりますよね。それは似てはいるけれども実は改変された新たな歴史であるからです。もしコマンドラインにrebase前のハッシュ値が残っていたら、checkoutしてみて下さい。まるで平行宇宙のように、以前のコミットが取得できるはずです。rebaseは新たな歴史を作るので、不用意に共通リポジトリで行ってしまうと、運の悪い同僚の誰かがそのまま平行宇宙から合流できなくなるかもしれません。

最後に、もう一度Gitのロゴを見てみてください。点が線で繋がれていると思います。これはGitが点=個々のコミット履歴を独立したデータとして扱っており、コミット間の関係は単にその前後関係でしかない、ということを表しているのだと思います。

あえて一石を投じてみます。

私は機械系の学科で流体力学をやった後、修士でとある総合電気メーカーに入りました。本当はタービンの開発をやるのが志望だったのですが、 私の就職した1980年代は半導体がちょうど日本の主力産業になる時代で、圧倒的に電子工学科の卒業生が足らず、そのため中央研究所内のシステムLSI関係の研究開発をやる研究所に配属されました。なんで俺が、と当時思いました。ところが、そのシステムLSI関係の研究所に背足された同期は、私以外には、数学、原子力、強電、化学などで、その中で本来の電子工学科の卒業生は東北大の修士のやつ一人だけでした。やれやれこれは困ったぞ、ということでそいつにリーダーをやらせ、先輩から言われたLSI設計やそのほかの基本的な電子回路の輪講を終業後毎日やっていました。多分当時の日本中の電気会社は同じような状況だったのだと思います。今考えると無茶苦茶です。でもそのうちみんな格好がついてきて、数学専攻だった奴らはLSI CADの研究開発に、その他の我々は映像、通信などそれぞれの分野での専門家に段々なっていきました。当時の半導体の研究所は、まさに今のダイバーシティ的な梁山泊的な雰囲気のところでした。その後日本の半導体はご存知のように一度世界を席巻していきますが（その後没落しますが）、とにかく一度天下をとったその時の馬力は、当時まるで違う背景の人間が集まっていたからこそだからという解釈もできるような気もします。

翻って、現在のIT業界の人手不足と情報工学科の関係を見るとき、同じ情報工学を学んだ学生が多量に産業界にいることが果たして将来の日本のIT産業の隆盛につながるか、という点に一考の価値があると思います。材料、機械、化学、電気、などの他分野の工学部の卒業生が、情報工学を再勉強しながら産業を引っ張っていくという方にレジリエンスがあるのでは、とも思います。

Git誕生10周年を記念した開発者のリーナス・トーバルズ氏のインタビュー

（あちこちで言われている事ですが）リーナスの知識ベースが凡人と乖離している事が一因ではないかと思います。足りないものは自分で足せば良いと思っていた以上に、使う側と前提知識を共有していなかったと。

ユーザーがGitを通じてやりたい事とGitが実現している事が違うのが見えづらい上、CUIベースで概念をすぐに理解出来る人があまりいないのが要因ではないでしょうか。

また、GitHub等のホスティングサービスの機能とGitの機能の違いを理解しないまま、手順としてなぞってしまう為に、混乱してしまうのではないでしょうか。

そしてGit本体のインストール方法が、Windowsベースだと、Git for Windowsが一般的だと思うのですが、そのままだと使いづらい面が多く、SVN慣れした人ならTortoisegitと併用する事を勧めるのですが、結構あるパターンとして、GUI以外使わないようになってしまい、かえってGitの仕組みを知らなくなってしまう。Tortoisegitの吐いたコマンドを見ると、純粋にGitコマンド叩くのと違うオプションだったりして、理解するには、結局コマンドを覚えるほうが楽だと気づくのに時間がかかると。ホスティングサービスのツールだと、複雑すぎて、面食らうんじゃないでしょうか。（少なくとも私はそう思いました）

これも良く言われる事ですが通過儀礼がキツいので、SVNからの翻訳は最初だけにして、なるべく早くGitという文化を理解する事をお勧めするのですが、現世利益的に？実務を優先する為、SVN同様、「ソース」を「格納」する「手順」になってしまう為、なんでこんなにまどろっこしいの？となってしまうのかなと思います。

この辺りは語学に近いですね。SVNでいうところのブランチはGitのブランチには翻訳不能だって事になかなか気づかないと言うか。

まぁ慣れればどうってこともないです。

Gitを理解するにはローカルから始めるのが一番だと私は思っています。リーナスがGitを作った時のように。日々の作業をなるべくGitコマンドを駆使してやってみる。作る、コミットする、作りかける、スタッシュする、チェックアウトする、diffとってチェリーピックする。スタッシュ戻す、続きやる、コミットする、タグ付けするなどは、リモートを使わないという感覚を覚える。

それから次に、pull（fetch +merge)と、fetch —rebaseの違いを理解する。対応するのはpushだけで良いとか。

ステージング（git add ）については、実際のところIDEのgitプラグインやtortoise gitなんかでも、チェックボックスだけだったりするので、後から覚えても良い気がしています。

forkとプルリクエストはホスティングサービスの機能なので、コードレビューの文化として、またOSS活動の知識として理解することが肝心だと思います。

私がとある情報科学科を卒業したのは25年以上前になりますが、コンピューターが使える実習室がほぼ24時間アクセス可能で、大学院生のタコ部屋がすぐ上の階にあってもうちょっと経験を積んだ先輩方が何をしているか様子を見ることができ、また話がしたければ気軽にできる、という環境でした。

今や50歳を目前にしたその同期グループの中で、現在でもプログラミング書きをメインの仕事としているのは、当時から実習室に常に顔を出していて、学校の課題として与えられたものだけではなく、その他興味の向くままに大学院生の先輩と話をしたり、プログラムを書いたりということを日常的に楽しみとしてやっていた人が多いように思います。

ですので、少なくとも私が行ったところでは「実践ができない」ということはなく、「やりたければいくらでもやったらよい」という感じではありました。大学に行って職業とすることを考えるのであれば、課題をやっているだけでは残念ながら足らず、それ以上のこともやらないといけないとは思います。大学の良いところはそこにより知識を持った人がおり、また同好の士として気軽に情報交換ができる人がいるということで、そのような環境を利用しない手はないと思います。

大学外でももちろんできるとは思いますが、ある程度の系統だった知識を持った人、あるいは持った人々との触れ合いが持つ効果については過小評価してはならないでしょう。独学でやろうとすることの困難はプログラミングに限らず何にでも付きまといますし、では「実践」ということで業務べったりの開発をアルバイトのような感じで始めたとしても、長期的に向上し続けるためには「認知マップ」が十分広がらないことが多いのではないかとは思います。

ですので、「実践」と「幅広さの」両方を求めるべく、授業や課題もやり、そして自分で作りたいものを見つけてどんどん作ってみる、ということができる貴重な時間を得られる大学を有効活用するのが良いのではないかと思います。

答えは、『 未経験でとってくれる会社の研修で勉強しながら働き、その会社で3-5年ぐらいしたら、働きながら勉強してある程度実力が付いたら転職』が正解の道です。

あるいは、『スクールや専門学校に勉強してから、卒業した！という新卒カードを使って、なおかつ未経験でとってくれる会社の研修で勉強しながら働き、その会社で3-5年ぐらいしたら、働きながら勉強してある程度実力が付いたら転職』

なども正解だと思います。

まずWebエンジニアなどＩＴ業界に入る際、未経験の人が、いくらパソコンスクールに行こうが、専門学校にいって勉強しょうが、それは経験としてカウントできません。

経験としてカウントしていいのは、現場で仕事した時のみです。

授業料を払っているにもかかわらず、勉強してスキル？資格？を身につけたと言っても関わらず、業界では経験ありとならず未経験となります。

考えても見てください、スクールに行って色々な料理を作れるようになったが、生まれてこの方、客に料理を出したことの無く、スクールに行って調理師資格をとったからと言って、じぁ現場に放り込んでみょうかーって放り込んで、実際に仕事を出来るのかは、別問題な訳です。

特にＩＴ業界は、この資格があれば仕事が出来る。このスキルを知っていれば現場で働ける。そういう類のものではありません。逆に言えば、この資格が無いと働けない。このスキルを持っていなけとれば働いては駄目という類でもないのです。

知ってない(素人)人より、知っている人がいいよね！という、未経験よりパソコンスクールや専門学校出た人がいいかもね？という優位性はありますが、入社したらそんなことは些細な差です。

考えても見てください、プログラムやＷｅｂエンジニアの素養の無い人が、人事総務の採用窓口になっていた所で、その人は専門的なことは分かりませんし、勿論、最終審査で社長が出てきたとしても、Ｗｅｂエンジニアの素養として、貴方をどうこうは見れません。

その人の受け答えや、考え方、仕事の意気込みから、会社の風土にあうかあわないか、一緒に働きたいかどうかしか見てないのです。

実践の現場に試用期間に放り込んで、実際の仕事で、そして使ってみて耐えれるか、やれるかでしかないからです。

経験も無く採用してくれる会社があるのなら、業界の入り口としては入ったほうがいいです。

ただ先輩が手取り足取り色々ちゃんと教えてくれるとか、制度が整っているとか、そういうのは期待しないほうがいいです。

普通ならコストが高くても経験者ありで雇います。大手企業であれば、教育にコストを入れているケースもあり未経験で雇う可能性もありますが、その場合は大学の新卒のみかもしれません。

要は、業界未経験でもＯＫというケースは、それほど手が足りないケースで、お金も出せない場合の会社が多いです。

つまり給料の安く仕事利の多い会社(要はブラック体質)かもしれない訳ですから。。

しかしその会社で職務経歴書(履歴書ではない)を充実できるようにしてください。また仕事に関わるエピソードを充実できるようにしてください。

仕事でお金貰いながら勉強できる状態で実績もつくれる会社なので、多少は眼をつぶる必要があります。

もしかしたら納期や見積もりが矛盾して苦労したり、見積もりしなおしたり、納期の調整を行ってみたり、無茶振りで一人でやれっていわれたりして、なんとかやって行くうちに一人でWebエンジニアの仕事ができるようになれば、

今度は、良い職場環境を求めて転職することになります。実績＝職務経歴書を携えてね。

こんな案件を見積もりして、自分でこういことやって、納期までに仕事を終えましたとか。。。それを何人月で何日で終えましたとかです。

こういう実績って、捏造も出来ますし、結局な所で面接官が、人事総務や社長など技術のすりあわせが出来ない人が多いと思いますので、

仮採用で試用期間させてみて・・・というパターンになります。はいったら実力を示してください。

いま高校生ということは、１年生から３年生まで幅があるわけですが、４年制の大学に進むと仮定して、あと５〜7年後の時点の出来事を、見ず知らずの人間に未来予測をしてほしいと言っているわけですね。

それは、無理ですよ〜。2025年の状況を占うなんてできませんって。１年後だってわからないのに。

一応、自分の関心のあるジャンルについては、こんな風に（↑）予測はしてきたんですが、コンピュータの世界もSteve Jobsというわかりやすい人間が亡くなってから、１年後の姿が「読み」にくくなってきました。進化のスピードが落ちたエリアと、日々進化している分野が入れ替わりつつあるのだろう、とは感じています。

プログラミングについては、まったくやっていないよりは、何かやっておいたほうがいいということは言えます。ただ、趣味として行うプログラムと、仕事で行うプログラムは別物です（自分で作りたくもないプログラムを組む必要があるので、取り組み方が全然違うと思いますよ）。

また、うまく就職できていたとしても、職場との折り合いがつかなくてやめてしまっているかもしれませんし、ひとことに「エンジニア」といっても職種はさまざまです。

５〜８年後の心配をするよりは、「いましかできないこと」をやっておいたほうが建設的だと思いませんか？

まず、学校の勉強はやっておきましょうよ。そして、友達といろいろ話をしましょう。

部活をされているかどうかはこの一言ではわかりませんが、体力づくりはしておきましょう。

そうした活動の中で、自分はどういう人間かを知る努力をしましょう。

「自分のことは自分が一番よくわかっている」なんて言葉がありますが、自分のことが自分で一番よくわからないはずです。他人は「どうして？」と聞けば答えてくれますが、自分は聞いても答えてくれません。

自分にはどういう癖があって、どういうものの考え方をして、どういうことが好きで、どういうことが嫌いなのか。記憶力はいいほうか？　よくないほうか？　短期的な記憶力と長期的な記憶力で差はないか？　自分が関心をもっていることは何か？　関心を持っていることに対して自分でアクションを起こせるのか、他人からのアクションを待ってしまうほうか？

高校時代は人間観察のためのものすごく貴重なチャンスなんです。一生のうちで、こんなに能力差が小さい集団にいられる機会なんて、もうないんです。

まわりの同級生がどういう人なのか、何が得意で、何が不得意なのか。自分よりも成績のいい人間が、どういう努力をしてどんなことに関心があって、その人が行なっている日常的な習慣をいくつか取り入れたら自分も同じレベルに並べるんじゃないかといった、試行錯誤を行えるまたとない時期なんです。

そうしていろいろ努力を行なっていけば、１年後にはいま予想もできなかった「自分」に出会えるはずです。そういう努力のほうが建設的だと思いますよ！

転職を考えるときに履歴書に書けます。取っておいて損はないでしょう。

何しろ国が認定しているわけですから。

私は初級シスアドと二種と一種を持ってます。今でいう所のITパスポートと基本と応用ですね。

俺の実力は国が認めてるんだぜ！となんか自信がつきます😊

そもそも、大学の情報工学科は情報工学を学ぶ学部であり、プログラミングを学ぶための学部ではないのです。必須単位表を見れば明白でしょう。

プログラミングの実践は学外でやるのが基本だと思います。大学ではプログラミングよりも「情報工学」を学ぶのに集中しましょう。プログラミングにおいてそれは強みになるはずです。

私の母校の情報工学科の科目系統図を載せておきます

有名大学のCSで、実務で役に立つようなテクニックや技術ばかりを学べると思わないほうがいいですよ。

CSってコンピューター・サイエンス（計算機科学）のことですよね？

だったら学ぶのはまず離散数学や論理回路やデジタル回路の基礎、計算機科学の基礎です。

Dラッチって何？JKフリップフロップって何？RSフリップフロップで両方の入力をオンにしたらどうしていけないのか量子論の面から説明して。Equivalence relationが成り立たないものの例を挙げてみて。コーシー分布の期待値を求めようとしてみて。Quicksortのスードコードを書いて、その欠点を指摘して。フィボナッチ数列を計算するこの再帰アルゴリズムの[math]\mathit{O}[/math]（複雑性）を求めて。このFPGAとXilinxのアプリを使ってCPUを作って。Turing machineのモデルを使ってhalting problemを証明して。Journaling file systemを説明して。。。等々。

これらがエンジニア（飽くまでも一般的なソフトウェア・エンジニア）として、求められる設計書やコードを書くのにどれだけ「直接的」に役に立つかは謎です。

もちろん大学でも年次が上がってくれば実践的なコードを書いたり、OSやコンパイラーを作るプロジェクトをやったりしますが、それでも現場で毎日大小問わずコードを書いている現役エンジニアと比べた時、どちらが即戦力として見られるかは何となく分かるんじゃないかと思います。

ただし、、ただし、コンピューターや「計算」の基礎を、OSやデータベースや計算複雑性の基礎を、知っているのと知らないのとでは、書いたコードの質や効率に差が出たり、与えられた課題を理解してコードにできるかどうかの能力に違いがでてきたりはするかもしれません。

もちろん、それはあなたがどういう方面のどういうエンジニアを目指そうとしているかに大きく依存します。

OSの開発に携わりたいのなら有名大学で学べることは思いっきり学んでおかないと、後でめちゃめちゃ苦労するか、そもそもその方面のエンジニアになれないでしょう。

逆にPHPやCSSを専らの武器にしてWordPressの保守、開発を行っていくのなら大学で学ぶことは決して無駄とは言いませんが、その時間を現場で実践でコードをたくさん書いている人のほうが向いているかと思います。

何かを差別しているわけではありませんが、漠然と「エンジニアとしての実力」と言われても、回答を得られる前にまず質問攻めに遭うんじゃないでしょうか。

何をするソフトウェア・エンジニアになりたいの？エンジニアになって何がしたいの？そもそもどうしてエンジニアになりたいと思ったの？エンジニアとしてやっていける資質ってなんだと考えてます？

スタンフォードとか実務でとかいう前に、できるだけ現場（エンジニアとしての職種）を広く、できるだけ深く研究して、自分のやりたいこと、なりたいものと比較し、ある程度の方向性を見定めてからこういう質問をしたほうが実りが大きいと思いますよ。