git入門チュートリアルの初識git
2973 ワード
初識git
背景
Linusは1991年にオープンソース
Linusは
実際、2002年以前には、世界各地のボランティアが直接ソースコードを
...
Linusは2週間かけて自分で
1ヶ月以内にLinuxシステムのソースコードはGitによって管理されました!牛はどのように定義されていますか?皆さん、体験してみてください.
分散と集中
まず、集中型バージョン制御システムについて言えば、バージョンライブラリは専門の中央サーバに集中的に格納されているが、普段の使用中に中央サーバと連絡を取るには常にネットワーク状態にある必要がある.日常の仕事の流れはこのようにして、出勤する前にまず中央サーバーから最新の仕事の内容を引き出して、現地の修正が終わってから中央サーバーに送って、翌日出勤してから最新の内容を引き出して、修正してから中央サーバーに送ります...
集中式バージョン制御システムの特徴は、専用の中央サーバが必要で、仕事中にネットワークを接続しなければバージョン制御ができないことです.もし地方出張中やネットワークの条件がなければ、どのようにバージョン制御を行うかを考えてみてください.また元の時代に戻ったのではないでしょうか.
分散バージョン制御システムといえば、バージョンライブラリはそれぞれの使用者のコンピュータに格納されており、専門の中央サーバは必要ない.一人一人のコンピュータには完全なバージョンライブラリであるため、ネットワークを必要とせずに作業することができ、ワークフローは他のバージョン制御とほぼ同じである.
このように、集中型のバージョン制御システムは中央サーバに依存し、使用者に通信を継続することを要求するが、分散型のバージョン制御システムは中央サーバに依存せず、強制的にネットワークを接続する必要はない.
万一事故が発生した場合、集中型バージョン制御システムで
分散バージョン制御システムでは誰もが完全なバージョンライブラリを持っている以上、二人はいったい誰のバージョンを基準にしてどのように交流しているのか疑問に思うかもしれません.1つのバージョン、2つのバージョンはまあまあですが、100のバージョンライブラリがあるとしますか?
実際には、これは重要ではありません.100人が協力してプロジェクトを開発していると仮定します.プロジェクトの責任者として、100人のすべての仕事の詳細に関心を持っていないかもしれません.気にしているのは最終的な成果だけです.これらの成果は10人のプロジェクトチーム長が提出して維持しているので、あなたが関心を持っているのは10バージョンだけです.集中的な中央サーバの役割がないと仮定します.では、10のバージョンライブラリを手動で統合し、最終的にプロジェクトを完了する必要があります.
このように中央サーバは確かに存在する必要があるように見えますが、異なるバージョンのライブラリ間のコミュニケーションを容易にするために、通常、分散バージョン制御システムにも中央サーバの役割を果たすコンピュータがあります.ただお互いに交換して修正するのは不便です!
分布式であろうと集中式であろうと、存在は合理的であり、どのように取捨選択するかはそれぞれの応用シーンがあり、民主と専制を代表している.
gitとsvn
分布式であろうと集中式であろうと、無料であろうと有料であろうと、最良のものを追求するのではなく、自分に最適なものだけを必要とする.
小結
原文アクセスしてくださいhttps://snowdreams1006.github.io/git/base/about.html
git
は、任意の小さいまたは大きいプロジェクトを迅速かつ効率的に処理するためのオープンソースの分散バージョン制御システムである.背景
Linusは1991年にオープンソース
linux
システムを作成し、絶えず発展するにつれて、現在最大のサーバーシステムソフトウェアに発展していることを知っています.Linusは
linux
を作成したが、linux
の発展は世界中の熱心なボランティアの参加によって貢献され、こんなに多くの人が世界各地でlinux
システムのためにコードを作成しているのに、linux
のコードはどのように管理されているのだろうか.実際、2002年以前には、世界各地のボランティアが直接ソースコードを
diff
でLinusに送信し、Linus本人が手動でコードを統合した....
Linusは2週間かけて自分で
C
で分布式バージョン制御システムを書いた.これがGitだ.1ヶ月以内にLinuxシステムのソースコードはGitによって管理されました!牛はどのように定義されていますか?皆さん、体験してみてください.
分散と集中
まず、集中型バージョン制御システムについて言えば、バージョンライブラリは専門の中央サーバに集中的に格納されているが、普段の使用中に中央サーバと連絡を取るには常にネットワーク状態にある必要がある.日常の仕事の流れはこのようにして、出勤する前にまず中央サーバーから最新の仕事の内容を引き出して、現地の修正が終わってから中央サーバーに送って、翌日出勤してから最新の内容を引き出して、修正してから中央サーバーに送ります...
集中式バージョン制御システムの特徴は、専用の中央サーバが必要で、仕事中にネットワークを接続しなければバージョン制御ができないことです.もし地方出張中やネットワークの条件がなければ、どのようにバージョン制御を行うかを考えてみてください.また元の時代に戻ったのではないでしょうか.
分散バージョン制御システムといえば、バージョンライブラリはそれぞれの使用者のコンピュータに格納されており、専門の中央サーバは必要ない.一人一人のコンピュータには完全なバージョンライブラリであるため、ネットワークを必要とせずに作業することができ、ワークフローは他のバージョン制御とほぼ同じである.
このように、集中型のバージョン制御システムは中央サーバに依存し、使用者に通信を継続することを要求するが、分散型のバージョン制御システムは中央サーバに依存せず、強制的にネットワークを接続する必要はない.
万一事故が発生した場合、集中型バージョン制御システムで
として機能するコンピュータがダウンタイムになると、すべての人が仕事をすることができなくなり、バージョン制御による便利さを享受することはできません.同じ状況が分散バージョン制御システムで発生したらどうなるのでしょうか.1台のコンピュータがダウンタイムしても大丈夫です.すべての人のコンピュータが同時にダウンタイムすることはできません.すべての人のコンピュータの中で完全なバージョン制御であるため、そのうちの1人のバージョンを見つけて手動でダウンタイムコンピュータにコピーした瞬間、間もなく稼働を再開しましたか?だから分布式は集中式より安全です!分散バージョン制御システムでは誰もが完全なバージョンライブラリを持っている以上、二人はいったい誰のバージョンを基準にしてどのように交流しているのか疑問に思うかもしれません.1つのバージョン、2つのバージョンはまあまあですが、100のバージョンライブラリがあるとしますか?
実際には、これは重要ではありません.100人が協力してプロジェクトを開発していると仮定します.プロジェクトの責任者として、100人のすべての仕事の詳細に関心を持っていないかもしれません.気にしているのは最終的な成果だけです.これらの成果は10人のプロジェクトチーム長が提出して維持しているので、あなたが関心を持っているのは10バージョンだけです.集中的な中央サーバの役割がないと仮定します.では、10のバージョンライブラリを手動で統合し、最終的にプロジェクトを完了する必要があります.
このように中央サーバは確かに存在する必要があるように見えますが、異なるバージョンのライブラリ間のコミュニケーションを容易にするために、通常、分散バージョン制御システムにも中央サーバの役割を果たすコンピュータがあります.ただお互いに交換して修正するのは不便です!
分布式であろうと集中式であろうと、存在は合理的であり、どのように取捨選択するかはそれぞれの応用シーンがあり、民主と専制を代表している.
gitとsvn
git
は分布式バージョン制御システムの代表であり、それ以外にもBitKeeper
,Mercurial
,Bazaar
などの分布式制御システムがあり、それぞれの分布式制御システムには独自の特徴があり、疑いの余地がないのはgit
が最も簡単で最も流行していることだ.svn
は集中型バージョン制御システムの代表であり、現在最も広く使用されている集中型バージョン制御システムであり、cvs
ClearCase
などはすべて集中型に属する.分布式であろうと集中式であろうと、無料であろうと有料であろうと、最良のものを追求するのではなく、自分に最適なものだけを必要とする.
git
は分散型制御システム、svn
は集中型バージョン制御システムgit
コンテンツをメタデータ形式で格納、svn
はファイル形式で格納git
のコンテンツ整合性はsvn
より優れている.git
のコンテンツ記憶はsha-1
ハッシュアルゴリズムに基づいて、コンテンツの整合性を確保するからである.小結
git
はLinusがLinux
カーネル開発の管理を支援するために開発したオープンソースのバージョン制御ソフトウェアである.原文アクセスしてくださいhttps://snowdreams1006.github.io/git/base/about.html