Gitブランチの使用方法

この記事は、「UsingGit」シリーズの第3回です。 インストール記事とgitを効果的に使用する方法の記事の両方を読んだことを前提としています。

バージョン管理システムの世界では、GITは柔軟性の点で間違いなく最高の1つです。 構文を学び、gitがワークフローと環境に最適なサービスを提供する方法を理解するのは非常に簡単です。

このチュートリアルでは、2つのブランチ（マスターと開発）を作成する方法と、開発段階から本番環境にコードをマージする方法を説明します。

ブランチは、そのコアで、一意の名前を持つ一意の一連のコード変更です。 各リポジトリには、1つ以上のブランチを含めることができます。

デフォルトでは、最初のブランチは「マスター」と呼ばれます。

ブランチの表示

新しいブランチを作成する前に、存在するすべてのブランチを確認する必要があります。 次のように入力すると、既存のすべてのブランチを表示できます。

git branch -a

コマンドの最後に「-a」を追加すると、GITに、ローカルワークスペースにないブランチを含め、存在するすべてのブランチを表示するように指示します。

出力は次のようになります。

* master
  remotes/origin/master

出力の最初の行の「master」の横にあるアスタリスクは、現在そのブランチにいることを示しています。 2行目は、originという名前のリモートに、masterとも呼ばれる単一のブランチがあることを示しています。

ブランチの表示方法がわかったので、最初のブランチを作成します。

ブランチの作成

この記事の冒頭で述べたように、コーディング環境の開発と本番環境のセットアップが必要です。

デフォルトの「マスター」ブランチを本番環境として扱うため、開発またはプリプロダクション用に単一のブランチを作成する必要があります。

developmentという名前の新しいブランチを作成するには、次のように入力します。

git checkout -b develop

「develop」という名前のブランチがまだない場合、出力は次のようになります。

Switched to a new branch 'develop'

その名前のブランチがすでに存在する場合、GITは次のように通知します。

fatal: A branch named 'develop' already exists.

git checkoutコマンドを使用して、2つのブランチを切り替えることができます。

git checkout master

また

git checkout develop

切り替えようとしているブランチが存在すると仮定すると、次のような出力が表示されます。

Switched to branch 'master'

存在しないブランチに切り替えようとした場合、

git checkout nosuchbranch

Gitはあなたに教えてくれます：

error: pathspec 'nosuchbranch' did not match any file(s) known to git.

複数のブランチがあるので、それらを有効に活用する必要があります。 このシナリオでは、変更をテストするために「開発」ブランチを使用し、変更を公開するためにマスターブランチを使用します。

このプロセスを説明するために、開発ブランチに戻る必要があります。

git checkout develop

開発ブランチに変更を加える

このブランチでは、「develop」という名前の新しい空のファイルを作成します。 （次の手順で）マスターブランチにマージするまで、そこには存在しません。

touch develop 

前のチュートリアルと同様に、この新しいファイルを追跡することをgitに通知する必要があります。

次のように入力して、「開発」ファイルを追加できます。

git add develop 

上記の一連のコマンドは、「develop」という名前の空のファイルを作成し、それをGITに追加します。

また、このファイルをコミットする必要があります。これにより、現在使用しているブランチである「開発」にこのファイルが添付されます。

git commit -m "develop file" develop 

このファイルは現在、開発ブランチに存在します。 調べようとしているので、マスターブランチには存在しません。

まず、現在開発部門にいることを確認します。 これを行うには、次のように入力します。

git branch 

出力は次のようになります。

* develop
  master

ブランチ名の横のアスタリスクは、現在そのブランチにいることを示していることを以前に学びました。

「ls」コマンドを実行すると、2つのファイルが存在することがわかります。

ls

出力には、それぞれ「file」と「develop」という名前の両方のファイルが見つかったことが示されます。

develop file

ブランチ間のコードのマージ

興味深い部分は、マスターブランチに戻った後です。これは、gitcheckoutコマンドで実行できます。

git checkout master

マスターブランチにいることを確認するには、次のように入力します。

git branch 

出力は、アスタリスクで示されている、私たちが1つのブランチであることを示します。

  develop 
* master

「ls」を再度実行すると、新しいファイルが見つからないようです。

file

それは欠落していません-それは私たちの開発ブランチにあり、私たちは私たちのマスターブランチにあります。

このシナリオでは、このファイルは、開発ブランチでのすべてのテストに合格し、本番環境で使用できるようになっているファイル（またはまったく新しいファイル）への変更を表します。 ブランチ間（多くの場合、開発から本番へ）でコードを移動するプロセスは、マージとして知られています。

マージするときは、マージ先のブランチに参加したいということを覚えておくことが重要です。

この場合、「develop」ファイルが存在する開発ブランチからマスターブランチにマージします。

このことを念頭に置いて、すでにマスターブランチにいることを考えると、mergeコマンドを実行するだけです。

マージコマンドに渡すことができるオプションの1つ、つまり「–no-ff」は、マージ前にgitにすべてのコミットメッセージを保持させたいことを意味します。 これにより、将来の変更の追跡が容易になります。

開発ブランチからマスターブランチへの変更をマージするには、次のように入力します。

git merge develop --no-ff

コマンドの出力は、次のようになります。

Merge made by the 'recursive' strategy.
 0 files changed
 create mode 100644 develop

lsコマンドを再度実行すると、「開発」ファイルがマスターブランチにあることを確認できます。

develop file

リモートサーバーでこの変更を行うために今やらなければならない最後のことは、変更をプッシュすることです。これは、gitpushコマンドを使用して行うことができます。

git push

次のような出力が表示され、開発ブランチからリモートサーバーのマスターブランチへのマージが確認されます。

Counting objects: 4, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 332 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To ssh://[email protected]/repository
   9af2dcb..53649cf  master -> master

結論

上記のチュートリアルに従うことで、デュアルブランチワークフローのセットアップが機能し、GITでブランチがどのように機能するかを理解できるようになります。 コメントであなたの考えを教えてください！