プログラミングを学ぶとき、Git の学習を勧められることがよくあります。理論的には簡単に思えます。コードの変更を追跡し、必要なときに以前のバージョンのコードを復元するのに役立つプログラムです。それに加えて、業界のほぼすべての場所で使用されているツールです。実際には… Git は控えめに言っても混乱を招く可能性があります。 なぜこのようにしなければならないのですか？ コマンドライン インターフェイス — CLI コンピュータを日常的に使用するほとんどのユーザーは、テキストベースのインターフェイスの贅沢さに慣れていません。 に書いたように、いくつかの大きな利点があるため、贅沢と呼んでいますが、ユーザー エクスペリエンスに慣れるまでには時間がかかる場合があります。したがって、関連付けがリストの関連付けと一致する場合: 以前    — ふわふわした動物 cat  —人々が音楽を聴いていた方法 cd  - いくつかのオノマトペ、 grep その場合、Git を初めて使用する場合、コマンド ラインの基本を学習するのがさらに難しくなる可能性があります。 Windows 95 とその同類があなたから奪った何か。  Git の設計目標 Git は、単純であることを意図したものではありませんでした。さまざまな目標を念頭に置いて作成されました。より重要で、より挑戦的な目標も含まれています。 セーブデータを安全に保管 Git は、常に保存されたとおりのデータを返すか、リポジトリが破損していることを知らせることを目的としています。コミットをチェックアウトしたときに得られる状態が、作成者が意図したとおりであることを確信できます。もちろん、これは彼らが何をしているかを知っていることを前提としています。  Git はどのようにして優れたデータ セキュリティを実現するのでしょうか?コミット、フォルダー、ファイルなど、 する巧妙な方法でこれを行います。各オブジェクトは、そのコンテンツの暗号化ハッシュ (オブジェクトのコンテンツに基づいて生成される数値) によって識別されます。この数値は、ファイル内の何かが変更されると変更されます。オブジェクト間の参照もハッシュされるため、Git が異常に気付かない限り、リポジトリ内を改ざんする方法はほとんどありません。そのような場合でも、意味のあるコードは意味不明な長いテキストに置き換えられます。 すべてを保存 セキュリティで保護されていないネットワークや、信頼されていない参加者との作業 すべてが暗号化ハッシュによって識別されるため、Git はデータを完全な状態に保つためにネットワークの大部分を信頼する必要はありません。 Git は中間者攻撃から保護されています。Git の 2 つのノード間に意味のあるコードを挿入することはできません。もちろん、意図されていないコミットを誰かが読み取ることができる場合、これも問題ですが、攻撃者がコードベースにコードを挿入するよりも危険な結果は少なくなります。 セキュリティをさらに強化するために、Git はサインアップ コミットを提供しています。これは、コミットがその作成者として設定されている人物によって作成されたことを保証する追加の手段です。 下位互換性の維持 Git インターフェースは、ユーザーの古い習慣を尊重しているため、必要以上に複雑になっています。私は 2011 年に Git を学びましたが、先週まで、ブランチを変更するために推奨される新しい コマンドがあることに気づきませんでした。私が慣れている方法（   +さまざまなフラグ）は、まだ正常に機能しています。 Git は、新しいユーザーのシンプルさよりも古いユーザーとその習慣を優先します。これは次のポイントにつながります。 git switch git checkout スーパー ユーザーのユーザー エクスペリエンス Git は、スーパーユーザーを念頭に置いて作成されたツールです。これは Linux のコード ベースを管理するために Linus Torvalds によって作成されたものであり、初心者の作業ではありません。 Git の主なユーザーは、オペレーティング システムを開発し、数十年にわたるプログラミングの経験を持ち、コマンド ライン内で生活しています。それ以外の使用はすべて偶発的なものであり、Git を開発する人々にとって主な関心事ではありません。 シンプルさのトレードオフ システムを設計するとき、無料のものは何もありません。ユーザーにとってのシンプルさも含まれています。 複雑さを隠す 本質的に複雑な問題を扱っている場合、複雑さを抽象化することで解決策を簡単にします。なくなった？いいえ、ユーザーから隠されているだけです。たとえば、インターネット接続の場合、私とほとんどの人は接続品質を 📶 のバーの数としてのみ理解しています。 少ないは悪い もっといい これは、インターネットを使用するのに十分ですが、接続の問題を理解してトラブルシューティングするのが難しくなります.  Git は、並行してファイルを変更し、非同期で同期することに伴うすべての複雑さを明らかにすることに重点を置いています。反対側では、共有ディスクに直接アクセスできます。使い方は簡単ですが、2 人が同時に同じファイルを編集しようとするとどうなりますか?一方は幸運で変更を保持し、もう一方はすべてを失います。特に失われた変更が何時間もの高価な労働に値する場合は、良いワークフローではありません。 Git は、このような状況で発生する可能性のあるすべての問題をユーザーに公開するため、ファイル内の競合をインテリジェントな方法で解決できます (場合によってはユーザーが手動で行う必要があります)。 簡単 vs 安全 ユーザーを混乱させる Git のもう 1 つの部分は、コミット ID が非常に長く、数字を覚えることができないことです。ユーザーフレンドリーな省略形でも、  のように見えます。完全な ID は です。代わりに数字だけを順番に並べたり、ブランチ名だけを使用したりできますか?問題は、コミット ID がデータの整合性を保証するハッシュであることです。つまり、私のマシンのコミット X が、リモートまたはあなたのマシンのコミット X と同じであることを保証します。そして、それらの間の不一致は、さまざまな理由で発生する可能性があります。 0828ae1 0828ae10b20500fbc777cc40aa88feefd123ea5e 意図的 - リベース、修正、スカッシュ、または履歴を変更するその他の操作 意図的でない - コードベースへのミスまたは攻撃 インターフェイスを簡素化し、ユーザーからコミット ID を非表示にすると、ユーザーが自分のマシンで実行しているコードベースで何が起こっているかを理解する可能性がなくなります。また、コードは定義上マシン上で されるため、セキュリティの悪用は非常に危険です。 実行 これは正しいアプローチですか？ 私が Git を学んでいたとき、それはまだ目新しいものでした — 私は 2011 年に学び、Git は 2005 年に作成されました (最初のコミットは からです)。当時、私は仕事で を使用していましたが、  は Git よりもユーザーフレンドリーな代替手段と見なされることがよくありました。最近、それらの名前を聞いたことがありますか? Git は、バージョン管理市場をほぼ完全に支配しました。 GitHub の台頭で人気を博しましたが、初心者にとっては大雑把ではありますが、非常に効率的なツールであり、定着しています。 Thu Apr 7 15:13:13 2005 -0700 SVN Mercurial 初心者プログラマーとして何をすべきか? 私のアドバイスは、遅かれ早かれそれを学ぶことです。 Git がすぐにシンプルになる可能性はほとんどありません。または今まで。一般に、バージョン管理システムは、プログラミング中の頭痛の種を大幅に軽減します。コードベースのバージョンを移動するのに苦労している場合、コードを効率的に操作できるとは思えません。 Git をよく学ぶことで、失われたファイルに苦労したり、いわゆる「Git の問題」を修正したりする代わりに、コードの課題に集中することができます。これらの問題はほとんどの場合、自分でリポジトリを台無しにするだけです。 それに加えて、Git を学ぶことは、新しい開発者にとって通過儀礼になりました。開発者としては、Git を使用する必要があり、Git をよく理解せずに使用しようとすると、人生が悲惨になります。賢明な選択は、レビュアーからのフィードバックやコードの問題によって強制的に学習させられるまで待つのではなく、他の責任を同時に処理しながら、自分の条件で学習することです。 詳細を知るには？  Git について詳しく知りたい場合は、 からサインアップして、Git に焦点を当てた私のコンテンツに関する最新情報を入手してください。 こちら も掲載されています。 ここに

Different

Keep

Mind

Super

2022 - HackerNoon Contributor of the Year - Beginners Guide

2022 - HackerNoon Contributor of the Year - Code Quality

2022 - HackerNoon Contributor of the Year - Learning

2022 - the Greatest Storyteller

Newsletter

Senior JS developer

このオーディオは、ストーリーの元の言語で制作されています。

長すぎる; 読むには

Git はなぜ複雑なのか

Git はなぜ複雑なのか

About Author

コメント

ラベル

この記事は

Related Stories

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Claude Sonnet 3.5 システムプロンプトの漏洩: 法医学的分析

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps