Git は分散バージョン管理システムです。 Git は、Linux カーネル開発の管理を支援するために Linus Torvalds によって開発されたオープン ソースの分散バージョン管理ソフトウェアで、小規模なプロジェクトから非常に大規模なプロジェクトまで、プロジェクトのバージョン管理を効果的かつ迅速に処理するために使用されます。
このチュートリアルの動作環境: Windows 7 システム、mysql8.0.22 バージョン、Dell G3 コンピューター。
git はどのバージョン管理システムに属しますか?
Git は分散バージョン管理システムです。
Git には次のような特徴があります :
Git 内の各クローン (クローン) のバージョン ライブラリは同じです。任意のリポジトリをクローンして独自のリポジトリを作成でき、必要に応じて自分のリポジトリを他の人のソースとして使用することもできます。
Git のすべての抽出操作は、実際にはコード リポジトリの完全なバックアップです。
送信はローカルで完全に完了します。他の人があなたに承認を与える必要はありません。あなたはリポジトリのマスターであり、送信は常に成功します。
古いバージョンに基づいた変更でも正常に送信でき、送信すると古いバージョンに基づいて新しいブランチが作成されます。
Git の送信は、作業に完全に満足するまで中断されません。他の人に PUSH するか、他の人にリポジトリを PULL してください。PULL プロセスと PUSH プロセス中にマージが発生します。不可能な競合自動的に解決されない場合は、手動で完了するように求められます。
競合の解決は、SVN のような提出コンテストのようなものではなくなりましたが、マージと競合の解決は必要に応じて実行されます。
Git は集中作業モードをシミュレートすることもできます
Git バージョン ライブラリはサーバー上で統合されています
Git リポジトリを承認できます。誰がリポジトリを作成できるか、誰がリポジトリに PUSH できるか、誰がリポジトリを読み取る (クローンできる)
チームのメンバーが最初にクローンを作成しますサーバーのリポジトリをローカルに配置し、サーバーのリポジトリから最新の更新を頻繁にプル (PULL) します。
チーム メンバーは、他のメンバーが同期するときに、リポジトリ内で変更をサーバーのリポジトリにプッシュ (PUSH) します。リポジトリ (PULL) を使用すると、変更が自動的に取得されます。
Git の一元化された作業モデルは非常に柔軟です。
「バージョン管理」とは何ですか?
バージョン管理は、1 つまたは複数のファイルの内容の変更を記録するシステムです。これにより、特定のバージョンのリビジョン ステータスを確認し、後で遡ることができます。あらゆる種類のファイルをバージョン管理できます。 あなたがグラフィック デザイナーまたは Web デザイナーの場合、バージョン管理システム ( VCS) ) は賢明な選択です。 これを使用すると、特定のファイルを以前の状態にロールバックしたり、プロジェクト全体を過去のある時点の状態にロールバックしたりすることができ、ファイル内の変更の詳細を比較できます。そして、最後に何を変更したか、誰がどの部分を変更したかを調べて、奇妙な問題の原因、機能上の欠陥をいつ誰が報告したかなどを調べます。 バージョン管理システムを使用すると、通常、プロジェクト全体のファイルを一度に変更、削除、または削除した場合でも、元の外観に簡単に復元できることも意味します。ただし、追加の作業負荷は最小限です。ローカル バージョン管理システム
多くの人は、プロジェクト ディレクトリ全体をコピーしてさまざまなバージョンを保存することに慣れており、名前を変更したり、表示するバックアップ時間を追加したりすることもあります。違い。これを行う唯一の利点は、シンプルであることですが、間違いを犯しやすいことでもあります。作業ディレクトリが混乱し、誤って間違ったファイルが書き込まれたり、予期しないファイルが上書きされたりすることがあります。 この問題を解決するために、人々はずっと前に多くのローカル バージョン管理システムを開発してきました。そのほとんどは、単純なデータベースを使用して、ファイルの以前の更新の差異を記録します。図 1. ローカル バージョン管理。
最も人気のあるものは RCS と呼ばれるもので、現在でも多くのコンピュータ システムで使用されています。 rcs コマンドは、一般的な Mac OS X システムに開発者ツールキットをインストールした後でも使用できます。これは、一連のパッチ (パッチとはファイルの改訂前後の変更です) をハードディスクに保存することで機能し、すべてのパッチを適用することで、ファイルの各バージョンの内容を再計算できます。
集中バージョン管理システム
次に、人々は別の問題に直面しました。それは、異なるシステム上の開発者がどのように共同作業できるようにするかということでした。
そこで、集中バージョン管理システム (集中バージョン管理システム、略して CVCS) が登場しました。 CVS、Subversion、Perforce などのこのようなシステムには、すべてのファイルのリビジョンを保存する単一の集中管理サーバーがあり、共同作業する人々はクライアントを通じてこのサーバーに接続して、最新のファイルを取得したり、更新をコミットしたりします。これは、長年にわたってバージョン管理システムの標準的な慣行となってきました。
図 2. 一元化されたバージョン管理。
このアプローチは、特に昔ながらのローカルなバージョン管理と比較して、多くの利点をもたらします。 VCS。今では、プロジェクト内の他のメンバーが何に取り組んでいるのかを誰もがある程度見ることができます。管理者は各開発者の権限を簡単に制御することもでき、CVCS の管理は各クライアントでローカル データベースを維持するよりもはるかに簡単です。
物事には良い面と悪い面の 2 つの側面があります。これを行うことの最も明白な欠点は、中央サーバーが単一障害点になることです。 1 時間ダウンした場合、その 1 時間は誰も更新を送信できず、誰も共同作業できません。中央データベースが存在するディスクが破損し、適切にバックアップしなかった場合、プロジェクトの変更履歴全体を含むすべてのデータが間違いなく失われ、各自のマシンに保存されている個々のスナップショットだけが残されます。ローカル バージョン管理システムにも同様の問題があり、プロジェクト全体の履歴が 1 つの場所に保存されている限り、更新履歴のすべての記録が失われるリスクがあります。
分散バージョン管理システム
そこで、分散バージョン管理システム (分散バージョン管理システム、DVCS と呼ばれます) が登場しました。 Git、Mercurial、Bazaar、Darcs などのシステムでは、クライアントはファイル スナップショットの最新バージョンを抽出するだけでなく、コード リポジトリを完全にミラーリングします。このようにして、共同作業に使用されているサーバーに障害が発生した場合でも、ミラー化されたローカル ウェアハウスを使用して後で回復できます。すべてのクローン作成操作は実際にはコード リポジトリの完全なバックアップであるためです。
図 3. 分散バージョン管理。
さらに、これらのシステムの多くは、複数の異なるリモートで動作するように指定できます。エンドコードリポジトリと対話します。こうすることで、同じプロジェクトで異なる作業グループの人々と共同作業することができます。以前の集中型システムでは不可能だった階層モデルベースのワークフローなど、ニーズに応じてさまざまなコラボレーション プロセスをセットアップできます。
以上がgit はどのバージョン管理システムに属しますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。