Armin Ronacherブログの短い記事 （Flask、Jinja2などの著者）の翻訳に注目してください。 今回は、分散ファイルバージョン管理システムであるGitについての考えを共有します。
Gitは私にとって興味深いトピックです。 コマンドシステムがまったくないときに最初にGitを使用してみましたが、 Cogitoは有望なプロジェクトと見なされていました。 気に入ったとは言えませんが、当時は主にSVNを使用していましたが、すべての問題を完全に解決しました。 すぐにMercurialに出会い、一目loveれし、このVCS（バージョン管理システム）を使用することで長く肯定的な経験をする基礎を築きました。 Gitに切り替えたのは2008年になってからでした。リポジトリを移行する時期だと気付くまでに数回の試行が必要でした。
巨大なGitコマンドシステム
他のバージョン管理システムからGitに切り替えた開発者は、チームの整合性の欠如に不愉快な驚きを覚えるでしょう。 スティーブ・ロスは彼の「 Git Koans 」でこれを打ち負かすほど面倒ではなかった 。
ただし、このトピックについて再度議論するたびに、毎日の作業でGitコマンドの問題を思い出せないため、少し混乱します。 もちろん、「git remove」の構文は「git branch」や「git tag」とは異なりますが、矛盾を考えずにさまざまなタスクに使用しています。 私が覚えている唯一の奇妙なコマンドはgit showです。オブジェクトの内容を表示するための構文は毎回不可解です。
しかし、MercurialとPerforceについては、Gitについては言えない、通常の日常的な操作の実行中に頻繁に発生する苦労を簡単に思い出すことができます。 なぜGitコマンドシステムがそんなに嫌悪感を抱かないのですか？
学習チームvs. 学習のアイデア
この質問を考えて、Git構文のこのような簡単な採用の理由は、プログラマーによる研究の原則であるという結論に達しました。 MercurialとPerforceの場合、開発者は特定のタスクを解決するための一連のコマンドラインスペルを習得し、「内部」にあるものはすべて省略されます。
また、Gitの場合、逆のことが言えます。導入部の最初のページから、読者はこのVCSの内部の説明を参照します。
このトレーニング方法は、Gitにコマンドシステムがまったくなかった時代から存在していました。 開発者が「.git」ディレクトリ内のファイルを手動で編集することが期待されていました！ 私はこのシステムでの最初の実験を覚えています。コミットさえありませんでした。
echo "Commit message" | git-commit-tree $(git-write-tree) > .git/HEAD
しばらくしてから、コマンド「commit」がコマンドに割り当てられましたが、それでもその使用のための指示は... このようになりました 。
GitはもともとVCSとして設計されたのではなく、他のプログラムがVCSを作成するために使用できるアイデアとして作成されました。 そしてそれは、Git開発プロセスと他のすべてのバージョン管理システムの開発方法を根本的に区別します。
もちろん、過去10年間で、Gitは大きく変化し、Gitの基本的な考え方の一部は変化しましたが、主な本質はあまり変化していません。 また、Git 2005を使用してリポジトリを作成し、同じバージョンを使用してコミットし、Git 2015を使用してログを監視することには、いくつかの美しさがあります。
もちろん、Gitを使用するには、最も単純なコマンドシステムを学ぶ必要はありませんが、このVCSの根底にある基本的なアイデアには価値があります。
良好なデフォルト動作
確かに、Gitコマンドシステムは最良の方法ではありませんが、優れたデフォルトの動作を備えており、毎年改善されています。 「すぐに使える」Gitの動作は適切であり、最も一般的な作業方法はチームの設定に対応しています。そうでない場合は、オープンな議論を期待できます。 ほとんどのタスクには、Gitを使用してそれらを達成する「承認された」方法があり、この方法は通常簡単に習得できます。 Gitのブランチでの作業は当初から変更されておらず、10年前に得られた知識は依然として関連しています。
良い建築
Linusは、Gitを作成したときに、彼にとって非常に優れたアーキテクチャを考え出したと考えています。 時間が経つにつれて、コミットとオブジェクトの処理は正しく実装され、ブランチを処理するメカニズムも実装されました。 Mercurialでさえあきらめ、名前付きブランチを作成するのは得策ではないとユーザーに警告します。
Gitの基礎となる基本概念を研究したので、そのツールの全機能を安全に使用できます。 もちろん、まれなチームを更新するためにGoogleに登らなければならない場合もありますが、日常業務ではそのようなニーズはほとんど発生しません。 リポジトリを壊したことは一度もないので、すべてを修正することはできませんでした。
Gitコマンドシステムには整合性とシンプルさが欠けていますが、そのアーキテクチャにはこれらの両方の品質があり、その点でGitに感謝しています。
私のそばのGit
Gitが彼のコマンドシステムと時には不快な振る舞いを許す理由の1つは、Gitが常に私の側でプレイすることです。 多くの場合、リポジトリを巨大な方法で壊し、誤ったマージを行い、間違ったデータを消去しましたが、データが失われたり、VCSが私を台無しにしたりすることはありませんでした。
問題が発生した場合は、「。git」ディレクトリのコピーを作成し、振り返ってみて、間違ったことを調べます。 リカバリーが不可能な状況は非常にまれです。これは、Gitがその可能性を完全に明らかにするオプションの1つです。 リポジトリを爆破し、これらのVCSの開発者の参加なしにそれを復元することを不可能にした他のバージョン管理システムのミスを今でも覚えています。
私の記憶では、Gitの誤った使用または内部作業のために破損したリポジトリの単一のケースはありませんでしたが、他のVCSでは、Subversionの破損した作業コピー、破損したサーバー、破損したPerforceワークスペースおよびMercurialリポジトリ、破損したという悲しい経験があります私の手で。
Gitで私に起こった最悪の事態は、GitHubのバグのために発生したFlaskリポジトリ内のいくつかのファイルに対する不正なアクセス許可でした。
おわりに
Gitのようなソフトウェアを追加することを拒否しないと思います。 作業の内部ロジックがユーザーとの対話の重要な部分であり、ユーザーインターフェイスがブラックボックスの実装から分離されていないソフトウェア。
そのようなソフトウェアの反例は、私とAppleの最新のソフトウェアソリューションとの間に生じる認知的分離です。 「名前を付けて保存」ウィンドウはなくなり、ファイルシステムに何も保存されていない場合でも、「保存」ダイアログに削除ボタンが表示されるようになりました。 ファイルシステムのロジックとユーザーインターフェイスのロジックが根本的に異なるため、Keynoteのプレゼンテーションを頻繁に書き直しました。 根本的に異なる操作（まだ保存されていないデータの破棄と、ファイルシステムに既に保存されているファイルの消去）が名前を付けられ、同じように見えることに非常に怒っています。
翻訳者から
3月20日金曜日にサンクトペテルブルクで開催されたPiterPyカンファレンスで、この記事の著者やその他の著名なパイオニストと話をすることができます。 KoshkinとIvan Tsyganov、およびその主任開発者であるSergey Matveenkoは、いずれかのストリームのリーダーになります。
翻訳：グリゴリーペトロフ（@eyeofhell）