実際のGit

Pro Gitというすばらしい本があり、gitのすべてのコマンドと機能について詳しく説明しています。 しかし、それを読んだ後も、多くの人は、これらすべてを実際に使用する方法についてまだ誤解しています。 特に、さまざまなレベルのプログラマーは、Gitでブランチを使用する方法、ブランチを開始するタイミング、およびブランチを維持する方法についてよく質問します。 時々、gitで作業するための非常に「オリジナル」で不合理に複雑なスキームに出くわしました。 プログラマーのコミュニティはすでにgitとそのブランチを操作するためのスキームを形成しています。 この記事では、Gitを使用する際の主なポイントの簡単な概要を示し、ブランチを使用する「クラシック」なスキームについて説明します。 この記事で説明する内容の多くは、他のバージョン管理システムにも当てはまります。

この記事は、Gitやその他のバージョン管理システムを習い始めたばかりのプログラマーに役立つかもしれません。 経験豊富なプログラマーにとっては、この記事は非常に単純で平凡に思えます。

まず、ブランチとコミットとは何かを理解しましょう。

コミットする

コミットは、バージョン管理システムの主要なオブジェクトであると言えます。 ユーザーがアプリケーションコードに加えた変更の説明が含まれています。 Gitでは、コミットはいくつかのいわゆるオブジェクトで構成されます。 理解を容易にするために、コミットは、変更されたファイルを含むオブジェクトと以前のコミットへのリンクで構成される単一リンクリストであると想定できます。



コミットには他のプロパティがあります。 たとえば、コミットの日付、作成者、コミットに関するコメントなど。
コメントとして、通常、このコミットがコードに加える変更、または解決するタスクの名前を示します。

Gitは分散バージョン管理システムです。 これは、各プロジェクト参加者が、プロジェクトのルートにある「.git」フォルダにあるリポジトリの独自のコピーを持っていることを意味します。 すべてのコミットと他のGitオブジェクトが保存されるのはこのフォルダーです。 Gitで作業する場合、Gitはこのフォルダーでも機能します。

新しいリポジトリの作成は非常に簡単です。これはチームによって行われます

git init

このようにして、新しい空のリポジトリを取得します。 既存のプロジェクトの開発に参加する場合は、このリポジトリをリモートリポジトリからローカルフォルダにコピーする必要があります。 これは次のように行われます。

git clone <url >

その後、現在のフォルダーに.gitディレクトリが表示され、リモートリポジトリのコピーが含まれます。

コードが存在する主な領域がいくつかあります。

• 作業ディレクトリは、プロジェクトのルートにあるファイル、つまり作業中のコードです。
  
• ローカルリポジトリは「.git」ディレクトリでもあります 。 コミットやその他のオブジェクトを保存します。
• リモートリポジトリは、共有と見なされるリポジトリと同じリポジトリであり、ローカルリポジトリからコミットを転送して、他のプログラマがそれらを見ることができるようにします。 複数のリモートリポジトリが存在する場合がありますが、通常は1つです。
• 通常、問題があることを理解している別の領域があります。 これは、いわゆるステージング領域です。 実際には、コミットに変更を含める前に、このコミットに含める内容を正確にメモする必要があります。 作業ディレクトリ内の複数のファイルを変更できますが、これらのすべての変更を特定のコミットに含める必要はありません。

一般に、gitの操作は次のようになります。作業ディレクトリ内のファイルを変更し、コマンドを使用してこれらの変更をステージング領域に追加します。

git add </>

アスタリスク付きのマスクを使用できます。
次に、ローカルリポジトリにコミットします

git commit –m “ ”

十分なコミットが蓄積されて共有できるようになったら、コマンドを実行します

git push

その後、コミットはリモートリポジトリに移動します。

リモートリポジトリから変更を取得する必要がある場合は、コマンドを実行する必要があります

git pull

その後、他のプログラマによって送信された変更がローカルリポジトリに表示されます。

プロジェクトのワークスペース内のコードは、コミットに含まれる変更を適用することにより形成されます。 各コミットには独自の名前があります。これは、コミット自体の内容からのsha-1関数のハッシュの結果です。

コマンドを使用してコミットを表示できます

git log

このコマンドのデフォルトの応答形式はあまり便利ではありません。 これは、より読みやすい形式で回答を表示するコマンドです

git log --pretty=format:"%H [%cd]: %an - %s" --graph --date=format:%c

プレビューを終了するには、qキーを押します
次のコマンドを使用して、作業ディレクトリとステージング領域の内容を確認できます

git status

コマンドを実行することにより、作業ディレクトリを以前の状態に切り替えることができます

git checkout <hash >

これを行う直前に、git statusを実行し、ローカルおよびコミットされていない変更がないことを確認してください。 そうしないと、Gitはそれを切り替える方法を理解しません。 git statusは、ローカルの変更でできることを教えてくれるので、切り替えることができます。 他の切り替えワークスペースでは、このルールに従う必要があります。

支店

Gitのブランチは、いずれかのコミットへの移動ポインターです。 通常、ブランチはコミットチェーンの最後のコミットを指します。 ブランチは単一のコミットから発生します。 視覚的には、このように想像できます。



コマンドを実行して、新しいブランチを作成してそれに切り替えることができます

git pull
git checkout –b < >


次のコマンドを使用して、切り替えずに単純にブランチを作成できます。

git branch < >

ブランチに切り替える

git checkout < >

ブランチはブランチからではなく、あなたがいたブランチにある最後のコミットから発生することを理解することが重要です。

通常、ブランチは特別なマージコミットで終了します。これは、ブランチを他のブランチとマージする必要があることを示します。 マージコミットには、1つのブランチにマージされる2つのコミットへの2つのリンクが含まれています。



ブランチをマージする場合、マージコミットなしでマージが発生する可能性がある別の状況があります。 実際、ブランチの1つで変更が発生していなければ、2つの祖先とのマージコミットは必要ありません。 この場合、Gitはブランチをマージするときに、このブランチがマージされたブランチのコミットがさらにあることを単にメモします。 このようなマージスキームは、早送りマージと呼ばれ、視覚的には次のように表すことができます。



これらのすべての場合、ブランチが別のブランチとマージした後、そのブランチで行われたすべてのコミットは、ブランチがマージされたブランチに分類されます。 また、マージは双方向の操作ではないことを理解することも重要です。 タスクブランチをマスターブランチに保持すると、タスクブランチにあったコードがマスターブランチに表示され、マスターブランチからの新しいコードはタスクブランチに表示されません。 これを実現するには、masterブランチをtaskブランチにマージする必要があります。
あるブランチを別のブランチに保持するには、最初に保持したいブランチに切り替える必要があります

git checkout < >

次に、このスレッドで行われた最新の変更を取得します

git pull

次に、コマンドを実行します

git merge < >

これは、ブランチの作業が一般的にどのように見えるかです。

新しいブランチを開始する前に、git pullを実行する必要があることに注意してください。 これにはいくつかの理由があります。

• 別のプログラマーは、新しいブランチを開始する問題の解決に影響するような変更を行うなど、コードを変更できます。 これらの変更は、問題を解決する際に役立ちます。
• これらの変更により、合併の競合が発生する可能性があります。
• マージコミットが行われる可能性が高くなります。 これは、前の2つのポイントほど悪くはありません。 しかし、余分なコミットを避けることができるなら、なぜそれをしないのですか？

人気のあるGitブランチスキーム

これで、gitでブランチを操作するための一般的なスキームを説明できます。

プログラマーがプロジェクトで一緒に作業し、同時に互いに干渉しないようにするために、ブランチが必要です。 プロジェクトを作成するとき、Gitはベースブランチを作成します。 マスターブランチと呼ばれます。 中央ブランチ、つまり メインアプリケーションコードが含まれています。

ブランチを操作する古典的なスキーム

通常、問題の解決を開始する前に、プログラマーは最後の作業コミット、マスターブランチから新しいブランチを開始し、この新しいブランチの問題を解決します。 ソリューション中に、彼はいくつかのコミットを行い、その後、タスクブランチでコードを直接テストします。 そして、タスクが解決した後、masterブランチにマージを戻します。 この作業スキームは、ユニットテストおよび自動展開でよく使用されます。 単体テストがコード全体をカバーする場合、タスクブランチのすべてのテストが最初に実行されるように展開を構成できます。 その後、成功した場合、マージと展開が行われます。 このスキームを使用すると、テストおよび展開中に完全な自動化を実現できます。

名前付きブランチ

経験の浅いプログラマーは、独自のブランチを開始し、常にそこで作業します。 一度に1つの問題を解決し、問題の1つを解決し終えると、Webインターフェースを介して新しいプル要求を作成します（これについては以下で詳しく説明します）。 このアプローチの欠点は、この方法では1つの問題のみを解決でき、別の問題の解決にすぐに切り替えることができないことです。 別の欠点は、ブランチが時間の経過とともにますます分岐し、プログラマブランチのコードがマスターブランチに関して遅かれ早かれ廃止され、更新する必要があることです。 これを行うには、マスターブランチをプログラマブランチにマージするか、マスターブランチの最後の作業状態からこのプログラマの新しいブランチを開始します。 確かに、これが起こる頃には、プログラマーは既に「古典的な」作業スキームに切り替えるのに十分なgitをマスターできています。 したがって、このスキームは、Gitの経験の浅いユーザー向けの場所です。

devブランチを使用したスキーム

別のスキームは、従来のスキームに非常によく似ていますが、マスターブランチに加えて、テストサーバーに展開される開発ブランチもあります。 このブランチは通常devと呼ばれます。 作業のスキームは次のとおりです。 新しいタスクを実行する前に、プログラマはマスターブランチの最後の作業状態からブランチを開始します。 彼はタスクの作業を終えると、タスクブランチを自分でdevブランチにマージします。 その後、共同で、タスクは残りのタスクと共にテストサーバーでテストされます。 エラーがある場合、タスクは同じブランチでファイナライズされ、devブランチで保持されます。 タスクのテストが完了すると、マスターブランチでタスクのタスクが保持されます。 masterブランチを操作するこのスキームでは、devブランチではなくtaskブランチをマージする必要があることに注意することが重要です。 実際、devブランチには、このタスクだけでなく他のタスクでも行われた変更が含まれます。これらの変更のすべてが機能するとは限りません。 マスターブランチとdevブランチは時間の経過とともに分岐するため、この作業スキームでは、マスターブランチの最後の作業状態から定期的に新しいdevブランチが開始されます。 このアプローチの欠点は、従来のスキームと比較して冗長性です。 プロジェクトに自動化されたテストがなく、すべてのテストが開発サーバーで手動で実行される場合、このブランチでの作業スキームがよく使用されます。

また、これらの作業スキームは、必要に応じて互いに組み合わせることができることに注意してください。

プルリクエスト

この概念には混乱があります。 実際、Gitにはプルリクエストと呼ばれる2つの完全に異なるものがあります。 その1つがコンソールgit pullコマンドです。 もう1つは、リポジトリのWebインターフェイスのボタンです。 github.comでは、このように見えます



このボタンについてはさらに説明します。

プログラマーが経験豊富で責任がある場合、通常、彼は自分のコードをmasterブランチにマージします。 それ以外の場合、プログラマーはいわゆるプル要求を行います。 プルリクエストは、本質的にマージを行うための許可リクエストです。 プルリクエストは、Git Webインターフェースから、またはgit request-pullコマンドを使用して作成できます。 プルリクエストが作成された後、他の参加者はこれを確認し、プログラマがプロジェクトに追加するために提供するコードを表示し、このコードを承認するかどうかを決定できます。 プルリクエストによるマージには長所と短所があります。 欠点は、経験豊富なプログラマーの緊密なチームにとって、このアプローチが不要になることです。 これは、作業を遅くするだけで、官僚主義の色合いを取り入れます。

一方、コードを破ることができる経験豊富なプログラマーがプロジェクトにいない場合、プルリクエストはエラーを回避するのに役立ち、コードにどのような変更を加えるかを観察することで、これらのプログラマーを迅速にトレーニングできます。

プルリクエストは、オープンソースプログラマの幅広いコミュニティにも適しています。 この場合、そのような開発者の能力や、コードで何を変更したいかについて前もって言うことはできません。

対立

これらのブランチで同じコード行が異なる方法で変更された場合、ブランチのマージ中に競合が発生します。 次に、Gitはどの変更を適用する必要があるかをGit自身で決定できないため、この状況を手動で解決することを提案しています。 これにより、プロジェクト内のコードでの作業が遅くなります。 これはさまざまな方法で回避できます。 たとえば、関連するタスクが異なるプログラマーによって同時に実行されないようにタスクを分散できます。
これを回避する別の方法は、特定のコードスタイルに同意することです。 その場合、プログラマはコードのフォーマットを変更せず、同じ行を変更する可能性が低くなります。

チームで作業しているときに競合を避けるのに役立つもう1つの良いヒントは、問題を解決するときにコードに最小限の変更を加えることです。 変更する行が少ないほど、別のタスクの別のプログラマと同じ行を変更する可能性が低くなります。

安定と見なすことができるマスターブランチの状態に到達すると、この状態のバージョンのタグでマークされます。 これは、プログラムのバージョンと呼ばれるものです。
これは次のように行われます

git tag -a v1.0

ブランチをリモートリポジトリに転送するには、コマンドを実行する必要があります

git push –tags

タグは、タグでマークされたコードの状態に簡単に切り替えることができるという点でも便利です。 これは同じコマンドを使用して行われます。

git checkout < >

さまざまな展開および自動化されたアセンブリシステムは、タグを使用して、展開または組み立てる必要がある状態を識別します。 これは、最新バージョンのコードを収集または展開すると、現時点で他のプログラマーがmasterブランチに何らかの変更を加えるリスクがあり、必要なものを収集しないためです。 さらに、作業中のプロジェクトの状態と確認済みのプロジェクトの状態を簡単に切り替えることができます。

これらのルールとブランチを操作する「クラシック」スキームを順守している場合、Gitを他のシステムと統合するのが簡単になります。 たとえば、継続的インテグレーションシステムまたはpackagist.orgなどのパッケージリポジトリを使用します。 通常、サードパーティのソリューションとすべての種類の拡張機能は、gitを使用するこのようなスキーム向けに特別に設計されており、すぐにすべてを正しく開始する場合、これは将来にとって大きなプラスになる可能性があります。

これは、Gitを使用する際のハイライトの概要です。 Gitについて詳しく知りたい場合は、Pro Gitの本を読むことをお勧めします。 まさにここ 。

この記事では、コミットの簡略化された表現を紹介しました。 しかし、それを書く前に、コミットがディスクにどのように保存されているかを正確に把握することにしました。 この質問にも興味がある場合は、 ここでそれについて読むことができます 。