Git はなぜ複雑なのか

プログラミングを学ぶとき、Git の学習を勧められることがよくあります。理論的には簡単に思えます。コードの変更を追跡し、必要なときに以前のバージョンのコードを復元するのに役立つプログラムです。それに加えて、業界のほぼすべての場所で使用されているツールです。実際には… Git は控えめに言っても混乱を招く可能性があります。

なぜこのようにしなければならないのですか？

コマンドライン インターフェイス — CLI

コンピュータを日常的に使用するほとんどのユーザーは、テキストベースのインターフェイスの贅沢さに慣れていません。以前に書いたように、いくつかの大きな利点があるため、贅沢と呼んでいますが、ユーザー エクスペリエンスに慣れるまでには時間がかかる場合があります。したがって、関連付けがリストの関連付けと一致する場合:

• cat — ふわふわした動物
• cd —人々が音楽を聴いていた方法
• grep - いくつかのオノマトペ、

その場合、Git を初めて使用する場合、コマンド ラインの基本を学習するのがさらに難しくなる可能性があります。 Windows 95 とその同類があなたから奪った何か。

Git の設計目標

Git は、単純であることを意図したものではありませんでした。さまざまな目標を念頭に置いて作成されました。より重要で、より挑戦的な目標も含まれています。

セーブデータを安全に保管

Git は、常に保存されたとおりのデータを返すか、リポジトリが破損していることを知らせることを目的としています。コミットをチェックアウトしたときに得られる状態が、作成者が意図したとおりであることを確信できます。もちろん、これは彼らが何をしているかを知っていることを前提としています。

Git はどのようにして優れたデータ セキュリティを実現するのでしょうか?コミット、フォルダー、ファイルなど、すべてを保存する巧妙な方法でこれを行います。各オブジェクトは、そのコンテンツの暗号化ハッシュ (オブジェクトのコンテンツに基づいて生成される数値) によって識別されます。この数値は、ファイル内の何かが変更されると変更されます。オブジェクト間の参照もハッシュされるため、Git が異常に気付かない限り、リポジトリ内を改ざんする方法はほとんどありません。そのような場合でも、意味のあるコードは意味不明な長いテキストに置き換えられます。

セキュリティで保護されていないネットワークや、信頼されていない参加者との作業

すべてが暗号化ハッシュによって識別されるため、Git はデータを完全な状態に保つためにネットワークの大部分を信頼する必要はありません。 Git は中間者攻撃から保護されています。Git の 2 つのノード間に意味のあるコードを挿入することはできません。もちろん、意図されていないコミットを誰かが読み取ることができる場合、これも問題ですが、攻撃者がコードベースにコードを挿入するよりも危険な結果は少なくなります。

セキュリティをさらに強化するために、Git はサインアップ コミットを提供しています。これは、コミットがその作成者として設定されている人物によって作成されたことを保証する追加の手段です。

下位互換性の維持

Git インターフェースは、ユーザーの古い習慣を尊重しているため、必要以上に複雑になっています。私は 2011 年に Git を学びましたが、先週まで、ブランチを変更するために推奨される新しいgit switchコマンドがあることに気づきませんでした。私が慣れている方法（ git checkout +さまざまなフラグ）は、まだ正常に機能しています。 Git は、新しいユーザーのシンプルさよりも古いユーザーとその習慣を優先します。これは次のポイントにつながります。

スーパー ユーザーのユーザー エクスペリエンス

Git は、スーパーユーザーを念頭に置いて作成されたツールです。これは Linux のコード ベースを管理するために Linus Torvalds によって作成されたものであり、初心者の作業ではありません。 Git の主なユーザーは、オペレーティング システムを開発し、数十年にわたるプログラミングの経験を持ち、コマンド ライン内で生活しています。それ以外の使用はすべて偶発的なものであり、Git を開発する人々にとって主な関心事ではありません。

シンプルさのトレードオフ

システムを設計するとき、無料のものは何もありません。ユーザーにとってのシンプルさも含まれています。

複雑さを隠す

本質的に複雑な問題を扱っている場合、複雑さを抽象化することで解決策を簡単にします。なくなった？いいえ、ユーザーから隠されているだけです。たとえば、インターネット接続の場合、私とほとんどの人は接続品質を 📶 のバーの数としてのみ理解しています。

• 少ないは悪い
• もっといい

これは、インターネットを使用するのに十分ですが、接続の問題を理解してトラブルシューティングするのが難しくなります.

Git は、並行してファイルを変更し、非同期で同期することに伴うすべての複雑さを明らかにすることに重点を置いています。反対側では、共有ディスクに直接アクセスできます。使い方は簡単ですが、2 人が同時に同じファイルを編集しようとするとどうなりますか?一方は幸運で変更を保持し、もう一方はすべてを失います。特に失われた変更が何時間もの高価な労働に値する場合は、良いワークフローではありません。 Git は、このような状況で発生する可能性のあるすべての問題をユーザーに公開するため、ファイル内の競合をインテリジェントな方法で解決できます (場合によってはユーザーが手動で行う必要があります)。

簡単 vs 安全

ユーザーを混乱させる Git のもう 1 つの部分は、コミット ID が非常に長く、数字を覚えることができないことです。ユーザーフレンドリーな省略形でも、 0828ae1のように見えます。完全な ID は0828ae10b20500fbc777cc40aa88feefd123ea5eです。代わりに数字だけを順番に並べたり、ブランチ名だけを使用したりできますか?問題は、コミット ID がデータの整合性を保証するハッシュであることです。つまり、私のマシンのコミット X が、リモートまたはあなたのマシンのコミット X と同じであることを保証します。そして、それらの間の不一致は、さまざまな理由で発生する可能性があります。

• 意図的 - リベース、修正、スカッシュ、または履歴を変更するその他の操作
• 意図的でない - コードベースへのミスまたは攻撃

インターフェイスを簡素化し、ユーザーからコミット ID を非表示にすると、ユーザーが自分のマシンで実行しているコードベースで何が起こっているかを理解する可能性がなくなります。また、コードは定義上マシン上で実行されるため、セキュリティの悪用は非常に危険です。

これは正しいアプローチですか？

私が Git を学んでいたとき、それはまだ目新しいものでした — 私は 2011 年に学び、Git は 2005 年に作成されました (最初のコミットはThu Apr 7 15:13:13 2005 -0700からです)。当時、私は仕事でSVNを使用していましたが、 Mercurialは Git よりもユーザーフレンドリーな代替手段と見なされることがよくありました。最近、それらの名前を聞いたことがありますか? Git は、バージョン管理市場をほぼ完全に支配しました。 GitHub の台頭で人気を博しましたが、初心者にとっては大雑把ではありますが、非常に効率的なツールであり、定着しています。

初心者プログラマーとして何をすべきか?

私のアドバイスは、遅かれ早かれそれを学ぶことです。 Git がすぐにシンプルになる可能性はほとんどありません。または今まで。一般に、バージョン管理システムは、プログラミング中の頭痛の種を大幅に軽減します。コードベースのバージョンを移動するのに苦労している場合、コードを効率的に操作できるとは思えません。 Git をよく学ぶことで、失われたファイルに苦労したり、いわゆる「Git の問題」を修正したりする代わりに、コードの課題に集中することができます。これらの問題はほとんどの場合、自分でリポジトリを台無しにするだけです。

それに加えて、Git を学ぶことは、新しい開発者にとって通過儀礼になりました。開発者としては、Git を使用する必要があり、Git をよく理解せずに使用しようとすると、人生が悲惨になります。賢明な選択は、レビュアーからのフィードバックやコードの問題によって強制的に学習させられるまで待つのではなく、他の責任を同時に処理しながら、自分の条件で学習することです。

詳細を知るには？

Git について詳しく知りたい場合は、こちらからサインアップして、Git に焦点を当てた私のコンテンツに関する最新情報を入手してください。