初心者向けのGitのヒント-パート2

Gitの初心者向けチュートリアルの第2部では、ブランチの管理、ブランチのマージ機能、およびポインターの原則について説明します。 ここで最初の記事を読むことができます 。

第8章ブランチ

ブランチの概念はそれほど単純ではありません。 作業ディレクトリのファイルに多くの変更を加える必要があると想像してください。しかし、この実験的な作業は、すべてがうまくいくという事実ではありません。 作業が完了するまで、変更を他の従業員に見せたくないでしょう。 たぶんそれまで何もコミットしないのでしょうか？ これは悪いオプションです。 頻繁なコミットとプッシュが作業の安全性の鍵であり、変更の履歴を確認する機会であることはすでにわかっています。 幸いなことに、Gitにはブランチメカニズムがあり、コミットとプッシュは可能ですが、他の従業員には干渉しません。



実験的な変更を開始する前に、ブランチを作成する必要があります。 ブランチには名前があります。 それを私のテストワークと呼びましょう。 これで、すべてのコミットがそこに正確に移動します。 その前に、彼らはメインの開発ブランチに行きました-それをマスターと呼びます。 言い換えれば、あなたはマスターブランチにいました（これを知らなかったとしても）が、今はテスト作業ブランチに切り替えました。 次のようになります。









コミット「3」の後、ブランチが作成され、新しいコミット「4」と「5」がそこに行きました。 そして、あなたの同僚はmasterブランチに残っていたので、新しいコミット「6」、「7」、「8」がmasterブランチに追加されます。 歴史は線形ではなくなりました。



それは何に影響しましたか？ 従業員には、作成したファイルの変更が表示されなくなります。 また、作業ファイルにそれらの変更は表示されません。 それでも、masterブランチの変更の履歴を見ることができます。



だから、今、あなたは誰にも邪魔されることなく、あなた自身の実験的な仕事をすることができます。 その結果があなたに合わない場合は、単純にマスターブランチに切り替えます（最後のコミット-図ではこれはコミット「8」です）。 切り替え時には、作業フォルダー内のファイルは同僚と同じになり、変更は消えます。 これで、作業コピーがコミット「8」からのキャストになりました。 写真は、my test workブランチで行った変更がないことを示しています。

第9章ブランチのマージ

これで、誰でもブランチを作成し、独立して作業できることがわかりました。 あるブランチで作業してから、別のブランチで作業することができます-それらを切り替えます。 ブランチは、checkoutコマンドによって切り替えられます。



ブランチは、一時的な独立した作業だけでなく使用されます。 多くの場合、ゲームのいくつかのバージョンを同時に準備します。 たとえば、あるバージョンはほとんど公開の準備ができており、プログラマーは最新の修正を加えています。 同時に、ゲームデザイナーはすでに次のアップデートに取り組んでいます。 次の理由により、以前のバージョンでは動作しません。

• それらの変更は現在のバージョンには表示されません。
• 変更は何かを壊す可能性があるため、バージョンを公開する前に、できるだけ少ない変更を加える必要があります。

つまり、ブランチには多くの利点があります。 ただし、実験的な作業の例に戻ります。 前の章で、私たちは彼女が失敗したと決めました。 マスターブランチに戻り、テスト作業ブランチで行った変更を失いました。 そして、すべてがうまくいったら？ 変更をmasterブランチに転送して、それを使用する人々がそれらを見ることができるようにします。 Gitは役立ちます-masterブランチでmy test workブランチのmergeコマンドを実行します：









ここで、コミット "8"はmerge-commitと呼ばれる特別なコミットです。 mergeコマンドを実行すると、システムはこのコミット自体を作成します。 コミット「5」、「6」、「7」からの同僚の変更と、コミット「3」、「4」からの作業を組み合わせます。



コミット「1」と「2」からの変更は、ブランチの作成前に行われたため、マージする必要はありません。 そのため、最初はmasterブランチとmy test workブランチの両方にありました。



mergeコマンドは、何もoriginに送信しません。 その唯一の結果は、マージコミット（図の番号8の円）であり、コンピューターに表示されます。 通常のコミットと同様に実行する必要があります。 そのmerge-commitが起点になった後にのみ-同僚はプルによってあなたの作業の結果を見るでしょう。

第10章ブランチAからブランチBへのいくつかのマージ

前の章では、新しいブランチを作成し、そこで作業し、メインブランチに変更をアップロードする方法を学びました。 マージ後の図では、ブランチがマージされています。 これは、私のテスト作業ブランチで作業できないことを意味します-既にmasterとマージされていますか？ いいえ、テスト作業ブランチに引き続きコミットし、メインブランチに定期的にマージできます。 それはどのように見えますか：









ブランチを接続するセグメントは水平ではないことに注意してください-どのブランチからどのマージに移行したかが表示されます。 この状況では、2つのマージがあり、両方とも右ブランチから左へのマージがありました。 最初のマージの結果はmerge-commit "7"で、2番目はmerge-commit "10"でした。 たとえば、マージは右ブランチから左に向かって行われるため、キャスト「8」では、コミット「3」で行われた変更があります。 ただし、キャスト「11」では、コミット「5」で行われた変更はありません。 この理由を必ず理解してください。 そうでない場合は、ブランチの章をもう一度読み直してください。

第11章両側のブランチ間のマージ

前の例では、テスト作業ブランチからマスターブランチまで常にマージを続けました。 反対方向にマージすることは可能ですか？これには意味がありますか？ できます。 あります。



ブランチで長い間作業している場合、メインブランチから定期的にマージすることをお勧めします。 これは、他の人が変更したファイルの現在のバージョンで作業するために必要です。 それはどのように見えますか：









my test workブランチからmasterブランチへの2つのマージと、反対方向への1つのマージがあります。 逆結合の結果は、マージコミット "8"でした。 たとえば、彼のおかげで、コミット "11"のキャストには、コミット "7"からの変更が含まれています。 ただし、このコミットはマージ後に行われたため、「11」キャストの「9」コミットからの変更はありません。

第12章コミットとそのハッシュ

gitはコミットをどのように区別しますか？ 簡単にするために、写真ではシリアル番号を付けました。 実際、Gitのすべてのコミットは次の行で示されます。



e09844739f6f355e169f701a5b7ae02c214d5fb0



これらは、Gitが作成されたときに自動的に付与するコミットの「名前」です。 一般に、このような文字列は一般に「ハッシュ」と呼ばれます。 各コミットハッシュは異なります。 特定のコミットについて誰かに伝えたい場合は、そのコミットのハッシュをその人に送信できます。 ハッシュを知っていれば、彼はこのコミットを見つけることができます（これがあなたのコミットなら、もちろん、最初にそれを実行しなければなりません）。

第13章ブランチとインデックス

次に、Gitがブランチ情報を保存する方法についてもう少し詳しく説明します。 Gitの内部デバイスは心配する必要はないようですが、これにより、Gitで操作を実行すると何が起こるかをよりよく理解できます。 そして、あなたは、多くの間違いを避けることができます。



「ポインター」の概念を理解しましょう。 簡略化された形式では、ポインターはその名前とハッシュで構成されます。 ポインターの例を次に示します。



マスター-e09844739f6f355e169f701a5b7ae02c214d5fb0



あなたは言う：「マスターはおなじみの名前です！ いわゆるメインワーキングブランチ。」 そして、この偶然は偶然ではありません。 Gitはポインターを使用して分岐を示します。 アイデアは簡単です。新しいブランチが必要な場合、Gitは新しいポインターを作成し、ブランチの名前を付けて、ブランチの最後の（最新の）コミットのハッシュを書き込みます。 ブランチが作成されました！

ポインター内のハッシュのおかげで、ポインターはブランチの最後のコミットを参照または「ポイント」していると言えます。 Gitがブランチですべての操作を実行するには、これで十分です。 つまり、どのコミットがどのブランチに属しているかに関する他の情報は、Gitが保存しないブランチです。 それはどれだけミニマルです。



各ブランチには独自のポインターがあります。 次のコミットがブランチに追加されると、ポインターのハッシュは最後のコミットを再び「指す」ように変わります。 これは、最後から2番目のコミットへのブランチポインターのシフトとして表すことができます。



Gitに別のブランチへの切り替えを要求した場合（checkoutコマンド）、このブランチの名前を持つポインターを見つけて、そこから最後のコミットのハッシュを取得するだけで十分です。 Gitは、作業ディレクトリファイルがどのように見えるかを知っています（このコミットのキャストのように）。 Gitはファイルをこの形式にします-ブランチへの切り替えが発生しました。



ポインタの概念と、それらがブランチにどのように関係するかをよく理解していない場合は、この章をもう一度読み直してください。 Gitはポインターと多くの関係があるため、作業の仕組みを明確に理解することが重要です。 幸いなことに、それはまったく複雑ではなく、少し珍しいです。 慣れるだけです。

第14章ヘッドポインター

そのため、ポインターは名前を持つものであり、特定のコミットを参照する（そのハッシュを保存する）ことを知っています。 新しいブランチが必要な場合、Gitは最後のコミットへのポインターを作成し、新しいコミットごとにそれを前方に移動することを知っています。



ポインターはブランチだけでなく使用されます。 特別なヘッドポインターがあります。 コミットを示します。これは作業ディレクトリの状態です。 あなたはその考えを理解していますか？ 以下に例を示します。









ここには、マスターとテストの2つのポインターで表される2つのブランチがあります。 マスターブランチにあり、作業ディレクトリ内のファイルはコミットコミットナゲット「4」に対応しています。 どうやってそれを知るのですか？ ヘッドポインターがコミット "4"を指しているという事実から。 より正確には、マスターポインターを指し、マスターポインターはコミット "4"を指します。 コミット「4」を直接ポイントしないのはなぜですか？ なぜポインターを指しているそのようなフェイントですか？ したがって、Gitは、現在masterブランチにいることを意味します。



コミットにヘッドポインタを置くことができます-これにはチェックアウトコマンドがあります。 ヘッドが表示するコミットで、作業ディレクトリ内のファイルはこの状態になることを思い出してください（これはヘッドポインターのプロパティです）。 したがって、ヘッドポインターを別のコミットに移動することにより、Gitに作業ディレクトリ内のファイルを強制的に変更させます。 これは、たとえば、作業ファイルの古いバージョンにロールバックして、すべてがそこにあった方法を確認するために必要になる場合があります。 そして、マスター（チェックアウトマスター）ブランチの最後のコミットに戻ることができます。 チェックアウトテストを実行すると（図を参照）、headはテストポインターをポイントし、テストポインターはテストブランチの最後のコミットをポイントします。 作業ディレクトリ内のファイルは「6」ナゲットに変更されます。 そこで、テストブランチに切り替えました。



まとめると。 特別なポインタヘッドの置換により、作業ディレクトリ内のファイルがこのコミットのナゲットに変更されます。 しかし、headが何らかのブランチへのポインターを指している場合にのみ、Gitはこのブランチにいると見なします。



そして、headが直接コミット（ハッシュを保存）を指すとどうなりますか？ この状態は分離ヘッドと呼ばれます。 これにしばらく切り替えて、作業ディレクトリのファイルが過去のコミットの1つをどのように見ていたかを確認できます。



切り替え（ブランチ間および通常のコミット間）は、checkoutコマンドによって実行されます。

第15章オリジンオリジン/マスター

リモートリポジトリ（オリジン）は私たちのものと同じなので、そこにもブランチポインターがありますか？ そうだね。 たとえば、このスレッドの最新のコミットを参照するマスターポインターがあります。



興味深いことに、pullコマンドを使用して元から新しいコミットを取得すると、そこからのポインターのコピーもコミットとともにダウンロードされます。 ポインターマスターとoriginからダウンロードしたものを混同しないように、2番目のポインターはここでorigin / masterとして表示されます。 origin / masterは、リモートリポジトリのマスターポインターの現在の状態を表示せず、フェッチまたはプルコマンドが実行された時点でのコピーのコピーに過ぎないことを理解する必要があります。



masterとorigin / masterは異なるコミットを指す場合があります。 写真を見るとより明確になります。









これは、（pullコマンドを使用して）新しいコミットを取得し、2つの新しいコミットを作成したが、まだプッシュしていない状況を示しています。 その結果、ローカルマスターは最後のコミットをポイントします。 そして、origin / masterは、リモートリポジトリから取得したポインターの最後の状態です。 したがって、彼は「遅れました」。



プッシュコマンドの後、2つの上位コミットはオリジンに移動し、オリジン/マスターが上に移動し、マスターのように最後のコミットを指すことは論理的です。



オリジン/マスターは逆に高く、マスターは低いかもしれませんか？ たぶん。 方法は次のとおりです。 pullコマンドは新しいコミットを取得し、すぐに作業ディレクトリに配置します。 pullコマンドの直後に、origin / masterとmasterの両方が同じ最後のコミットをポイントします。 しかし、フェッチコマンドもあります。 プルのように、彼女は元から最新のコミットをダウンロードしますが、作業ディレクトリを更新するのは急いでいません。 グラフィカルには、次のようになります（コミットされていないコミットがない場合）：









フェッチコマンドの前に、マスターポインターはコミット "3"を指しており、これがリポジトリの最後のコミットでした。 取得後、2つの新しいコミット「4」と「5」がダウンロードされました。 リモートリポジトリでは、マスターポインタは明らかにコミット「5」を指していました。 このポインタはコミットとともにダウンロードされ、現在では「5」を指すオリジン/マスターとして表示されています。 すべてが論理的です。



なぜフェッチが必要なのでしょうか？ たとえば、作業ディレクトリの状態を変更する準備はできていませんが、同僚がそこでコミットした内容を確認したいだけです。 フェッチを行い、コミットを調べます。 準備ができたら、mergeコマンドを実行します。 以前にダウンロードしたコミットを作業ディレクトリに適用します。



この単純な例では、コミットされていないコミットがないため、マージでは何もマージする必要はありません。 マスターとヘッドポインターを単純に移動します-これで、コミット「5」が表示されます。 オリジン/マスターのように。



記載されたメカニズムには本当に複雑なものは何もないことに気付くかもしれません。 慎重に理解しなければならない詳細はたくさんあります。 しかし、Gitはそのようなものです。



記事の最後の部分では、ブランチの由来、プッシュがエラーをスローする理由、リベースとは何かについて説明します。 そしてもちろん、要約します。



→ Git：初心者向けのヒント-パート1

→ Git：初心者向けのヒント-パート2

→ Git：初心者向けのヒント-パート3