皆さんはGitシステムを知っています。 少なくとも彼らは聞いた-それは確かだ。 このシステムを使用する開発者は、複雑なインターフェースとバグのためにそれを気に入ったり、scったりします。 Gitのバージョン管理システムは、事実上の業界標準です。 開発者はMercurialの利点について意見があるかもしれませんが、ほとんどの場合、Gitを使用できるようにするための要件に我慢する必要があります。 複雑なシステムと同様に、多くの便利で必要な機能があります。 ただし、誰もが非常にシンプルになるわけではないため、既存の実装には改善の余地がありました。
簡単に言えば、トリッキーなアプリケーションの使用は困難でした。 そのため、マサチューセッツ工科大学の研究室では、改善点を取り上げて、すべての「問題のある要素」を断ち切りました（結局、ある問題にとっては別の問題にとっては簡単に有利になるという事実です）。 改善および簡素化されたバージョンはGitlessと呼ばれていました。 Gitに関連する2400の質問を考慮して開発され、StackOverflow開発者サイトから取得されました。
著者のチームは、ステージングとスタッシングの2つの概念を含む、Gitで最も問題のある場所を特定しました。 次に、既知の問題を解決するために設計された変更を提案しました。
gitの何が問題なのか
多くのユーザーは 、Gitには新しいインターフェースが必要だと不満を述べています。 専門家はドキュメントを作成しましたが、Gitの何が問題になっていますか？ 概念設計分析。 著者：S.ペレスデロッソおよびD.ジャクソン。
例
git checkout < file > // git reset --hard //
これらの2行は、Gitが改善されたインターフェースを必要としていたことの一例です。 1つの機能に対して2つの異なるコマンドがありますが、1つは1つのファイル用で、もう1つは複数のファイル用です。 問題の一部は、2つのチームが実際にまったく同じことをしていないことです。
ほとんどのGitユーザーは少数のチームで使用し、残りのユニットはより深いレベルでプラットフォームを知っています。 基本的には、基本的な機能にはプラットフォームが必要であり、円を狭くするための大きな層が残っていることがわかります。 これは、Gitが正しく機能していないことを示しています。
基本機能と以前のバージョンとの簡単な比較
Gitlessの顕著な特徴の1つは、このバージョンではステージングと呼ばれる機能が無視されることです。 ファイルの個々の部分を保存できます。 便利ですが、問題が発生する可能性があります。 この機能とスタッシング機能の主な違いは、2番目の機能がワークスペースから変更を隠すことです。
スタッシング機能は、作業ディレクトリ内の大まかな作業を隠します-変更された監視対象ファイルと、変更が不完全な状態でスタック上のすべてを保存します。 必要に応じて、すべての変更を後で適用できます。 これは、あるブランチで作業していて、すべてが不安定な状態にあり、緊急に別のブランチに切り替える必要がある場合に必要です。 しばらくの間、最初のブランチで部分的に実行された作業でコードをアンロードする必要はありません。
ステージング機能は、ファイルに加えられた変更のインデックスを作成します。 ステージングされたファイルにタグを付けた場合、Gitはアップロード用に準備したことを理解します。
Gitlessにはスタッシングの概念はありません。 次の状況を想像してください。 プロジェクトの開発中のため、別のブランチに切り替える必要がありますが、まだ完了していない作業をシステムにアップロードしていません。 スタッシング機能は、行った変更を取得し、後で復元できる未完了の変更とともにスタックに保存します。
Gitlessマニュアルの著者は、ブランチを切り替えるときに問題が発生すると報告しています。 どの隠し場所がどこにあるかを覚えるのは難しい場合があります。 まあ、すべての一番上は、競合するファイルを含むマージのプロセスにいる場合、関数は役に立たないということでした。 これはペレスデデロッソの意見です。
Gitlessのおかげで、この問題は解決されました。 ブランチは相互に完全に独立しています。 これにより、作業が非常に簡単になり、開発者はタスクを絶えず切り替える必要があるときに混乱を避けることができます。
変更を保存する
Gitlessはステージ領域全体を非表示にします。これにより、ユーザーにとってプロセスがより透明になり、複雑さが軽減されます。 問題を解決するための、より柔軟なコミットコマンドがあります。 また、コミットのコードセグメントを強調表示するなどのアクションを実行できます。
さらに、ファイルの分類を値に変更できます：追跡、追跡なし、または無視。 このファイルがヘッダーに存在するかどうかは関係ありません。
開発プロセスの分岐
新しいバージョンを理解するために必要な主なアイデアは、Gitlessのブランチが完全に独立した開発ラインになったことです。 それらのそれぞれは、その作業バージョンのファイルを使用して、他のものとは別個のままです。 交差点や問題はありません。 別のブランチに切り替えるといつでも、ワークスペースの内容が保存され、宛先ブランチに関連するファイルが復元されます。 ファイルの分類も保持されます。 ファイルが2つの別々のブランチに別々に分類されている場合、Gitlessはこれを考慮します。
簡単に言えば、Gitlessバージョンでは、システムにロードされていない、変更先のブランチの変更と競合する変更を覚えておく必要はありません。
また、マージ中またはフューズがある場合は、競合状況の解決を延期できます。 競合は、元に戻すまで残ります。
リモートリポジトリを操作する
ここでは、他のリポジトリとの同期は両方のプログラムで同じように発生します。
新しいバージョンのもう1つの利点は、コードを失うことなく古いバージョンに切り替えることができることです。 同時に、あなたの同僚は、あなたが他のソフトウェアを使用していることに気付かないかもしれません。
アプリケーションの公式WebサイトでGitlessを操作するためのマニュアルを学習できます。 このドキュメントでは、以下について説明しています。リポジトリの作成方法、変更の保存方法。 ブランチの操作方法。 タグの使用方法、リモートリポジトリの操作。
結果は何ですか
Gitの機能を保持するアプリケーションであることが判明しましたが、同時に開発チームによる学習と使用が容易になりました。 実際、Gitlessの前にGitを改善する試みが既にありました。 しかし、Philip Guo（彼はカリフォルニア大学サンディエゴ校の認知科学の助教授）によると、このバージョンは初めてインターフェースを変換し、主要な問題を本当に解決するという目標を達成しました。
このプロジェクトでは、厳密なソフトウェア開発手法を使用しました。 これは、世界中で最も広く使用されているソフトウェアプロジェクトの1つで欠点を切り分けるために必要です。 過去には、多くのユーザーがGitに対して賛否両論を唱えてきましたが、それらはすべて科学的なアプローチに基づいているわけではありませんでした。
Gitlessの例を使用すると、単純化のアプローチを他の複雑なシステムに適用できることが明らかになります。 たとえば、Google InboxおよびDropbox。