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

多くの新しい従業員がPlayrixに来ており、そのほとんどはGitで働いていません。 これは、特にゲームのデザイナーとアーティストに当てはまります。 これはプログラマーにとって珍しいことではありませんが、他のバージョン管理システムの経験はあまり役に立ちません。 たとえば、SVNの経験は一般的です。 しかし、Gitはイデオロギーが著しく異なります。 ほとんどの場合、どのボタンを押すかを知ることは難しくありませんが、一歩踏み出すことです。そして、何が起こっているのかを理解することはすでに困難です。







したがって、私たちは入門資料を書くことにしました。 バージョン管理システムとその操作のロジックについて、最初から説明します。 さまざまなクライアントの助けを借りてGitを操作できるため、この記事ではユーザーインターフェイスについて説明しません。 これは異常に見えるかもしれませんが、意図的に行われます。 代わりに、作業ディレクトリ、コミット、ブランチ、プル、プッシュなどに焦点を当てます。 これらの概念を理解したら、Gitクライアントの1つを選択し、そのインターフェイスをマスターする必要があります。

第1章最初の知り合い

作業するWorkディレクトリがあると想像してください。 これを作業ディレクトリと呼びます。 テキストファイルdocument.txtが含まれています。 毎日このファイルを操作し、新しいテキストを追加し、不要なものを削除し、何かを変更します。 突然、数日前に削除したテキストが必要になりました。 どうする バージョン管理システム（SLE）を使用しない場合、このテキストは復元できません。 そして、硬貨を使用する場合-これは問題になりません。



どのように機能しますか？ あなたはいつでもハード通貨にファイルを送ることができ、彼女はそれを覚えているでしょう。 これは、ファイルのコミット（コミットコマンド）と呼ばれます。 ファイルにすべての重要な変更を加えた後にそのようなコミットを行うと、異なるバージョンの多くのコピーがハードカレンシー内で形成されます。 作業ディレクトリにこれらのコピーは表示されません-ファイルは1つだけです。 ただし、コミットしたすべてのコピーは、必要に応じてSLEから取得できます。 ここで、ファイルのすべてのバージョンのリストを表示し、各バージョンで変更された行を確認できます。 便利ですね。



ファイルを変更し、さらにいくつかのコミットを行ったとします。 SLEはファイルのロックされたバージョンを記憶していました（簡潔にするために、ファイルのロックされたバージョンを単に「コミット」と呼びます）。 次にpushコマンドを実行します-コミットをサーバーに送信します。 これには2つの主な目標があります。

1. 安全性（コンピューターが故障した場合、ファイルの変更履歴全体がサーバーに残ります）;
   
   
2. 複数の人が同時に同じファイルで作業できる機能。
   
   

同時作業はどのように見えますか？ コンピューター上の他の従業員にもWorkフォルダーがあり、document.txtファイルも含まれています。 ファイルを編集し、コミットしてプッシュすると、変更がサーバーに送信されます。 別のユーザーがpullコマンドを実行すると、サーバーから変更がダウンロードされ、そのファイルに変更が表示されます。



そのため、複数の従業員が一度に同じファイルで作業できます。 彼らは定期的に他の人の変更を取得（プル）し、変更を加え、コミット（コミット）し、サーバーに送信（プッシュ）します。 そこから、他の従業員がそれらをピックアップできます。

興味深いことに、pullコマンドはサーバーから最新バージョンのファイルだけでなく、誰かがコミットした以前のバージョンもすべてダウンロードします。 つまり、同僚のすべてのコミットは、彼のコンピューターだけでなく、あなたのコンピューターにも保存されます。 これにより、ファイルの履歴全体、つまり、誰が、いつ、どの行が変更されたかを表示できます。



バージョン管理には、Gitプログラムを使用します。 Gitはサーバーにアクセスしてファイルの変更履歴を表示しません。 コンピューターに既に保存されているファイルのすべてのバージョンを表示するだけです。 他の人が編集したファイルのバージョンは、pullコマンドの後にコンピューターに届きます。



要約：

• 私たちはGitを信頼して作業フォルダーを追跡しました。
  
  
• 同僚が作業しているフォルダーにテキストファイルがあります。
  
  
• 時々、このファイルで他の従業員からの変更を収集します（プルコマンド）。
  
  
• また、このファイルを自分で変更してコミットし、Gitがファイルの新しいバージョンを記憶できるようにします。 次に、コミットをサーバーに送信します（プッシュコマンド）。 1つのコミットまたは複数のコミットを一度に送信できます。 しかし、従業員がファイルの現在のバージョンを見ることができるように、より頻繁にプッシュすることをお勧めします。 もう1つ、作業が終了していない場合-ファイルのこのような「作業」バージョンは、もちろん、プッシュする価値がありません。 結局のところ、他の従業員に不便をもたらすでしょう。
  
  

ファイルの変更、コミット、プッシュの違いを明確に理解してください。

おめでとうございます！ Gitバージョン管理システムの主な機能を紹介しました。 コマンドの呼び出し方法については特に説明していないことに注意してください。 異なるインターフェイスを持つGitクライアントがいくつかあるためです。 少し後に、1つを選択して学習します。 それまでの間、チームとは何か、チームは何をするのかをお伝えします。

第2章誰も削除していないリモートリポジトリ

各コミット後にGitがファイルを保存する場所は、ローカルリポジトリと呼ばれます。 それはあなたのコンピュータ上にあります-したがって、「ローカル」です。 プッシュコマンドはコミットをサーバーに送信することを上で述べました。 そのため、Gitでは「サーバー」と言うのはまったく正しくありません。「リモートリポジトリ」と呼ぶ方が正確です。 「リモート」-誰かがそれを削除したからではなく、遠く離れているからです（コンピューター上ではありません）。 この場合、リモートリポジトリはGitHub Webサイトにあります。 その構造では、コンピューター上のリポジトリと同じリポジトリです。 また、コミットも保存します。 pushコマンドは、ローカルリポジトリからリモートにコミットを送信し、反対にプルはリモートリポジトリからローカルリポジトリに新しいものを選択します。 新しいコミットはどこから来たのですか？ 彼らは他の従業員によってそこに送られました。



毎回「リモートリポジトリ」を作成するのに時間がかかりすぎます。 Gitでは、これはオリジンと呼ばれます。 それが伝統です。 さらに簡潔にするために、「リモートリポジトリ」の代わりに「起点」という用語を使用します。

第3章詳細を掘り下げる

重要な技術的詳細を掘り下げます。 それらの多くはありますが、Gitのロジックを理解することは、あなたの仕事に役立ちます。 だからあなたは我慢しなければなりません。



もちろん、作業ディレクトリでの作業は通常1つのファイルだけでなく実行されます。 Gitを使用すると、作業ディレクトリ内およびサブディレクトリ内の任意の数のファイルを操作できます。



各コミットは、複数のファイルの変更を一度に記憶できます。 論理的に関連する変更のみをコミットに含めることをお勧めします。 多くの異なる変更を同時にコミットしないでください-あなたや他の従業員が自分の履歴を理解することは困難です。



作業ディレクトリに新しいファイルを追加し、それをコミットできるようにしたい場合（そして他の従業員がそれを見ることができるようにしたい場合）、自分でGitにファイルを追加する必要があります。 これは、addコマンドによって実行されます。 これを行うまで、Gitはコミットに新しいファイルを含めません。 作業ディレクトリにサブディレクトリを作成することもできます。 それらのファイルは、addコマンドを使用してGitに追加する必要があります。



作業ディレクトリ内のファイルの一部はGitの制御下にある場合とそうでない場合がある（ログなど）ことを理解することが重要です。 これを追跡し、Gitに新しいファイルを追加するのはあなたの仕事です。



ところで、作業ディレクトリはコンピューターのどこから来たのですか？ サーバーからそれを選択すると、そこに表示されます（クローンコマンド）。



コメントを追加する必要があるすべてのコミット。 それはあなたが今どのような変更をコミットしているのかを簡潔にしかし有益に説明しています。



Gitは、前回のコミット以降に変更したファイルのリストを表示できます。 すべてを一度にコミットする必要はありません。 変更が論理的に関連しているファイルのグループを選択してコミットできます。 次に、別のものを選択します-別のコミットを行います。 コミットを論理的なものに分割することが重要です。



プッシュ（リモートオリジンリポジトリにコミットを送信）する前に、まずプル（オリジンに送信した他のユーザーの最新の変更を取得）する必要があります。 これを行わないと、システムはプッシュを許可しません（エラーメッセージが表示されます）。 Gitの機能についてさらに学習すると、なぜこれが起こるのかが理解できるでしょうが、今のところはこのルールを覚えておいてください。

第4章コミットされていない変更

一部のファイルを変更したが、まだコミットしていない場合は、作業ディレクトリにコミットされていない変更があると言われます。 この状態では、多くのGitコマンドを実行できません。 たとえば、プルまたはチェックアウト（作業コピーファイルを別のコミットに切り替える）。 この状況を克服するためのオプションは何ですか？

• これらの変更が不要な場合は、コミットされていない変更を元に戻すことができます。 この場合、ファイルは最後のコミットの状態に戻ります。
  
  
• 変更が役立つ場合は、コミットできます。
  
  
• これらの変更を一時的に非表示にすることもできます（stashコマンド）。 この場合、変更は作業ディレクトリにロールバックされます。 後で、非表示の変更を作業ディレクトリに戻すことができます。
  
  

第5章競合とその解決

オリジンから変更をプルすると、競合が発生する可能性があります。 これは次の場合に発生します。

1. テキストファイルの一部の行を変更し、変更をコミットしましたが、まだプッシュを行っていません。
   
   
2. 同時に、誰かがファイル内の同じ行を変更し、変更を元の場所に送信することに成功しました。
   
   
3. 他の人の変更を拾うためにプルします。 Gitは他の人の変更をあなたのものと組み合わせようとし、同じ行が変更されたことを発見します。 これは競合と呼ばれます。
   
   

この場合、発生したすべてのファイルで競合を手動で解決する必要があります。 競合する行のグループごとに、2つのオプションが表示されます-あなたが書いたものと他の誰かが書いたものです。



変更をマージした結果、これらのオプションのどれを残すかを選択する必要があります。 または、3番目のオプションを手動で記述することもできます-オプションの1つのコピーだけでなく、より微妙な結合が必要な場合。



次に、競合がある各ファイル内の競合する行の各グループに対して同じアクションを繰り返します。



競合がテキストファイルではなく、バイナリ（たとえば、画像）にある場合、もちろん行はありません。 次に、マージ後に残すファイルを完全に選択する必要があります（ファイルのバージョンまたは他のユーザーのバージョン）。 方法がわからない場合は、このファイルを最後に変更した人（ファイルの変更履歴で確認できます）に連絡し、ファイルのバージョンを残すべき人と話し合います。 理解せずにバージョンを常に取得する必要はありません。突然、他の人の変更がより正確になります。 そして、あなたがあなたの都合で対立を解決するならば、あなたはあなたの変更でそれらを一掃するでしょう。 これは明らかに悪いことです。



すべての競合が解決したら、競合のために中断された操作を続行できます。通常、これらはプル、マージ、リベース操作です。



競合があなたを怖がらせ、あなたが今それらを解決する準備ができていない場合、中止コマンドを実行できます。 彼女は作業ディレクトリの状態をロールバックします-競合の原因となった操作の前の状態にします。

第6章キャスト

作業ディレクトリ内のすべてのファイルの現在の状態を一度に想像してください。



提示？ この作業ディレクトリの状態を「キャスト」と呼びます。 次の変更されたファイルをコミットするたびに、Gitは新しいナゲット（作業ディレクトリ内のすべてのファイルの状態）を記憶します。 次の章では「キャスト」の概念を使用します。



注1：スナップショットは、変更されたファイルのみの状態ではありません。 これは、すべての作業ディレクトリファイルの状態です。



注2：もちろん、「作業ディレクトリ内のすべてのファイル」と言うときは、Gitの制御下にあるファイルを意味します。 Gitは他のすべてのファイルについて何も知りません。

第7章変更の履歴とその視覚的表現

作業ディレクトリファイルへの変更の履歴は、次のように表すことができます。









各サークルは1つのコミットです。 このイメージは、1つずつ行われるコミットを示しています。 これは、コミットの履歴をグラフィカルに表現したものです。



ところで、コミットは次の2つの方法のいずれかで検討できます。

• 前回のコミットからファイルを変更してコミットします。
  
  
• ナゲットとしてのコミットは、変更をコミットした後に生じた作業ディレクトリ内のすべてのファイルの新しい状態です。
  
  

場合によっては、履歴を一連の変更と見なし、場合によっては一連のキャストと見なすと便利です。 したがって、両方のオプションを精神的に操作することを学びます。

「キャスト」を考慮するのが便利な場合の例を次に示します。 作業ディレクトリが3つのコミットバックにどのように見えるかを見たいと想像してください。 手配は簡単です。 ストーリー（写真を参照）を取り、3つのサークル（コミット）をカウントし、Gitに次のように言います。「このコミット後、作業ディレクトリがどのように見えるかを知りたい」 Gitはそれに応じて作業ディレクトリ内のファイルを変更します。 つまり、作業ディレクトリをこのコミットのナゲットに切り替えました（または単に「このコミットに」）。



記事の次の部分では 、 次のことについて説明します。

• 枝
  
  
• ブランチをマージ
  
  
• ブランチAからブランチBへのいくつかのマージ。
  
  
• 両方向のブランチ間をマージ
  
  
• コミットとそのハッシュ
  
  
• 枝とポインター
  
  
• ヘッドポインター
  
  
• 原点\マスターポインタ
  
  

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

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

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