ギット

抜粋: https://zhuanlan.zhihu.com/p/263050507 (上映中)

Git世界で最も先進的な**「分散型バージョン管理システム」ですが、SVN「集中型バージョン管理システム」**です。SVN のバージョン管理は中央サーバーに集中されていますが、Git のバージョン管理はローカライズできます。

Git には、「リモートウェアハウス、ワークスペース、ステージングエリア、リポジトリ」という4 つの概念があります。リモートウェアハウスは Git サーバーで、管理対象チームのコードを保存するために使用されます。

ワークスペース、一時記憶域、バージョンライブラリはローカルのものです。たとえば、初期化後、現在のディレクトリの下にディレクトリがgit init表示されます。「redis ディレクトリはワークスペースであり、.git ディレクトリはバージョンライブラリによって所有されています。」 . バージョン情報はこちら」。.git

.git ディレクトリ内のインデックスファイル () は.git/index**「一時記憶領域」で、stageまたはと呼ばれますindex。インデックスはデータベースのインデックスに似ているため、「インデックス」** と呼ばれることもあります。

これら 4 つの領域の模式図は以下に示されており、Git を使用したことがある人には、次のコマンドによく知られています。

概略図からわかるように、コードは異なるレベル間で転送でき、レベルをまたいで転送することもでき、これらのアクションはすべて Git コマンドを通じて実現されます。

初期化時に、Git は自動的に最初のブランチを作成しmaster、マスターへのポインターが呼び出されますHEAD。

クローンプロジェクト

実際の作業環境では、プロジェクトはサーバーからローカルに複製され、次のgit cloneコマンドを使用して Git でプロジェクトを複製できます。

git clone https://github.com/liduchang/redis

実行するとgit cloneコピーが生成され、ローカルのウェアハウスとワークスペースで同期されます。具体的な概略図は次のとおりです。

コードを送信する

上の図から、コードは異なるレベル間を、高レベルから低レベルに、または逆に低レベルから高レベルに、またはレベル間で移動できることがわかります。

Git でのコードの低レベルから高レベルへの移動は、主に次のコマンドに依存します。

git add .：ファイルが一時記憶領域に追加されます。
git commit -m "提交信息": ファイルはローカルウェアハウスに追加され、-m パラメータが -am に変更されてローカルウェアハウスに直接プッシュされます。
git push: ファイルはリモートウェアハウスにプッシュされます。

実行は、実行してすべてのファイルを一時記憶域に追加し、実行してファイルをローカルウェアハウスに送信することとgit commit -a同じです。git addgit commit

コードフォールバック

コードを高レベルから低レベルに移動するコマンドは次のとおりです。

git pull: コードをリモートの倉庫からローカルにプルします。
git reset --files: 一時ストレージ領域の変更をローカルウェアハウスで上書きします。つまり、最後の git add の内容を上書きします。
git checkout --files: ファイルを一時記憶領域から作業領域にコピーして、ローカルの変更を破棄します。
git checkout HEAD --files: 最後の送信をロールバックします。

コードの競合

チームで共同で Git を使用する場合、全員が自分のコードを送信し、最終的にそれをトランクにマージします。プッシュの性質上、「ローカルウェアハウスのコミットレコードを使用して上書きする」ため、プッシュが失敗する場合が必ずあります。リモートウェアハウスのコミットレコード。

しかし、他の人がコードを提出し、そのコードがローカルにないため、コードは上書きされ、他の人のコミットの記録が残らないことになります。これは絶対に許可されません。

したがって、Git はプッシュするたびにチェックします。この状況が存在する場合、プッシュは失敗します。最初に git pull し、ローカルウェアハウスをリモートウェアハウスとマージするだけで、最後にプッシュは成功します。ファイルがすでに存在する場合は、競合するコードについては、ファイルを開いて競合を再度解決してください。

支店管理

Git で最も重要な点はブランチの概念です。ブランチにはマージとリベースの操作があり、「マージ」と「リベース」によって「コードのバージョンを効率的に管理」できます。

Git の初期化では、と呼ばれるデフォルトのメインブランチがありmaster、各コミットはタイムライン (ブランチ) にまとめられ、現在のブランチはHEADポインタによってポイントされます。

GIF カバー

コードのコミットが発生するたびに、現在のポイントが新しいバージョンを形成します。新しいブランチブランチが作成され、現在のコミットが新しいブランチを指している場合、新しいブランチは時間の経過とともに更新されます。多くのバージョンを形成します。

新しいブランチが開発されたら、ウェアハウスを送信してトランクマスターにマージし、最後にブランブランチを削除して、個人的な開発を完了します。

したがって、メインブランチにブランチが 1 つだけ作成されている場合、ブランチのマージは非常に高速です。マスターブランチを現在の送信に移動し、HEAD ポインターをマスターにポイントし、最後にブランブランチを削除するだけで完了します。。

しかし、これは実際には当てはまりません。複数人の共同開発チームでは、各人が自分のブランチを作成し、独自のサブミットを作成し、最後にそれをトランクにマージすることがよくあります。彼が自分自身をサブミットすると、リモートウェアハウスのコードが存在します。独自のローカルウェアハウスに存在しないコードのため、プッシュが失敗します。

例: プログラマーのトムとジェリーは同時にコードから移動し、最初のコードブランチは次の図に示すとおりです。

トムが独自のビジネスモジュールを開発し、コードを送信してトランクにマージすると、リモートトランクブランチが次の図に示されます。

「リモート倉庫マスターは gs234 を指さなくなりましたが、現在指されているバージョンとして新しいバージョン dfd453 が生成されます。」

同時に、Jerry's local も独自のモジュールを開発した後のブランチは、次の図に示されています。

ジェリーのローカル環境では、彼の **「ローカルウェアハウスマスターはまだ gs234」** を指しており、ジェリーは新しく作成されたブランチbranで開発し、開発後にブランチをマージし、最終的にmasterそれを指しますed489。

ジェリーがコードを再度送信すると、Git はリモートウェアハウスとジェリーのローカルウェアハウスをチェックします。比較した結果、リモートウェアハウスにはジェリーのローカルウェアハウスに存在しないコードがあることがわかります。ジェリーはリモートウェアハウスを実行して競合を解決する必要があります。それ自体でgit pull。

上記ではブランチの基本原理とブランチの管理で発生する問題について説明しましたが、次にブランチを操作するための基本的なコマンドをステップごとに説明していきます。

新しい支店

Git で新しいブランチを作成するコマンドは次のとおりですgit branch <分支名字>。新しいブランチの作成後にブランチを切り替えるコマンドは次のとおりですgit checkout <分支名字>。

新しいブランチ作成の本質: 「現在の提出物を指す新しい参照を作成することであり、マスターは参照のようなものです」 ; ブランチの切り替えの本質: 元の参照を指す参照をHEADリダイレクトする切り替えるブランチの参照:

もちろん、ブランチの作成とブランチのマージのための上記 2 つのコマンドを 1 つのコマンドに組み合わせることができます。git checkout -b <分支名字>

ポイントを切り替えた後、コミットコードが送信されるたびに、HEAD ポインタが新しいブランブランチとともに移動し、ブランブランチ上に各バージョンが形成されます。

特定のバージョンが新しい bran ブランチで開発されている場合、開発のために master ブランチに戻るとフォークが形成されます。

ブランチを表示

ブランチが作成されたら、次git branchの方法でローカルブランチを確認できます。

先頭に * が付いているブランチは現在のブランチを表しており、スコアを表示した後、どのブランチをチェックアウトするかが明確にわかります。

ブランチをマージする

独自のモジュールを開発して遊んだ後、後からローカルでブランチをマージします。ブランチをマージするコマンド: は、git merge <分支名字>**「指定されたブランチを現在のブランチにマージする」** ことを意味します。例: 現在のブランチはマスターであり、実行します。 : : git merge branbran ブランチを現在の master ブランチにマージすることを意味します。

ブランチのマージも失敗し、2 つのブランチが同じファイルを変更すると、Git はどの変更を保持するかを判断できなくなり、マージの競合が発生します。

例: まずmasterブランチ内の README.md ファイルを変更してから、ローカルウェアハウスに送信します。

次に、ブランチ開発に戻り、README.md ファイルを再度変更して、再度送信します。

最後に、ブランチをマージします。この時点で、2 回変更した README.md ファイルに、2 つの変更の競合するコードが表示されます。

同じファイルの操作を 2 回変更するため、Git はマージ後にどの操作を保持するかがわかりません。そのため、この決定はユーザーの判断に委ねられます。Git は、ファイル内のコードが競合する場所、具体的には競合する方法のみを通知します。それを変えるのはあなた次第です。

ブランチを削除する

最後に、自分で作成したブランチを削除します。次のgit branch -d <分支名字>方法でブランチを削除します。ブランチを削除できない場合は、次のgit branch -D <分支名字>方法でブランチを強制的に削除できます。

Git でのブランチの削除の本質: dev はブランチへの単なる参照であるため、ブランチの削除はこの参照の削除を意味し、コミットは削除されないため、削除操作も非常に効率的です。

ブランチコミットへの参照が削除されると、このブランチへの参照がなくなるため、このブランチは見つからず、Git リサイクルメカニズムによってリサイクルされます。

リモートを見る

複数人で協力するチームでは、いつでもリモートウェアハウスのステータスを確認したい場合があります。git Remote を使用して確認し、-v パラメータを追加してリモートウェアハウスの詳細を確認できます。

git remote
git remote -v

プッシュブランチ

ブランチをリモートにプッシュすることは、前のセクションで説明しました。ブランチは、 git Push コマンドを使用してプッシュできます。ブランチコマンドは、どのブランチをプッシュするかを示すコマンドの後に追加されます。

git push origin master // 将本地master分支推送到远程库

ブランチを引く

ブランチのプルには git pull コマンドを使用します。これは次の 2 つのコマンドと同等です。

git fetch
git merge

ただし、一般的には git pull コマンドを直接使用できます。

支店経営戦略

ブランチをマージする場合、Git は高速マージモード (早送り) でマージしますが、このモードでブランチを削除すると、ブランチの情報が失われます。

Git は **「通常モード」** でマージすることもできます。元の git merge コマンドの後に –no-ff パラメーターを追加するだけです。マージコマンドは次のとおりです。

$ git merge --no-ff -m "message" dev

一時的なアクセスワークスペースの変更

git stash開発中、ある時点で現在の変更を一時的に保存したい場合は、コマンドを使用できます。これは、変更されたファイルが独立したストレージ領域に保存され、送信されず、いつでも使用できることを意味します。また必要なときに取り出してください。

ここで注意すべき点は、「git stash は変更されたファイル、つまり Git によって追跡されるファイルです。新しく追加されたファイルは Git によって追跡されないため、git stash は stash しません」ということです。

git stash コマンドは、save コマンドの後に注釈情報を付けて追加することもでき、簡単に表示できます。

git stash save "备注信息"

git stash**「ローカル作業ディレクトリのコードはローカルウェアハウスと同じになります」** が成功した後、コマンドをgit stash使用して以前のスタッシュの履歴を表示できます。変更されたファイルを再度取り出す必要がある場合は、git stash list次のコマンドを使用できます。

git stash pop

git stash pop**「最初のスタッシュレコードをポップアップすると、スタッシュは履歴から削除されます」を意味します。コマンド「スタッシュをポップアップしますが、このコマンドのスタッシュはスタッシュ履歴に引き続き保存されます」* を使用することもできます。git stash apply *, :git stash dropコマンドを使用して削除することもできます。

この記事では、Git の分岐原理と Git の一時アクセス操作のみを説明します。紙面の都合上、今日はここで終了します。引き続き Git の操作については次号で説明します。また次号でお会いしましょう。

この記事では、引き続き Git について説明します。前の 2 つの元の図は、Git の基本操作を示しています。興味がある場合は、[] と [] を参照してください。

この記事で基本的な Git 操作を書いたら、図は終わりです。Git についてさらに詳しく知りたい場合は、次の Git のハードコア書籍を参照してください: [Proficient in Git]、[GitHub Getting Started and Practice]、[Git Authoritative Guide] 、[Git バージョン管理管理]、[GitHub 実践]。

…(img-mUC6O40i-1684305577842)]

これらは Git に関する良い本です。興味があれば読んでみてください。インターネット上には電子書籍もたくさんあります。あまりゴシップは多くないので、以下から本題を始めましょう。

GIT［基本概念］

ギット