tsujiprogram’s diary

共に学んで行きましょう‼️

Git ブランチ マージの基本・処理 コンフリクト コマンド

ブランチ使用・理由

・gitを使用した開発ではブランチを必ず使用する。

・通常は最初にコミットでgitが自動的に生成するマスターブランチを利用する。→このブランチが標準のブランチとして機能している。

 

それでは、どのような時にブランチを使用するのか

→例えば、過去リリースしたコミット済みのある機能に対して、性能向上が期待できる

 ロジックが思いついたとします。本当に狙い通りいくかは実際に試すしかない。共有 

 リポジトリ反映させるのは検証が終わってからになる。

              ↓

 

 そのため、ブランチを使用し、マスターブランチの開発とは関係ない機能を試す場所として利用していく。

 

ポイント:ブランチは好きな名前を付けることが出来るため、何のためのブランチかを分かりやすくする名前を付ける!

 

 

開発の流れ(ブランチとマージ

1.サンプルシステム1.0がをリリース

 

2.新プロジェクト「サンプルシステム2.0」ブランチ始動

 →メンバーから1.0に対して開発段階で、何度もコミットとプッシュされていく

 

3.運用チームより1.0に重大な障害報告

 

4.一旦サンプルプロジェクト2.0についての開発を中断して、バグ対応開始する。

 

5.バグ対応のためのブランチ作成bugfix

 →これまで作業していた2.0から、ブランチbugfixに切り替える。

  (この切り替え作業は、ローカルの作業ディレクトリで実施する)

 

6.問題を修正し、マスターブランチにbugfixブランチをマージする。

 →マスターブランチに組み込まれる。

 

7.サンプルプロジェクト1.1をリリース

 →今回のマージは「fast foward(ファストフォワード)」という

 

8.「サンプルシステム2.0」ブランチに戻り、新プロジェクトの開発再開

 

 

マージの基本

マージを理解していないことにより、履歴の喪失などのリポジトリを破壊してしまうことがある。他にもgitでトラブルが発生し開発が停止してしまった。これらはリベース(rebase)コマンドを使った時に起こりやすい

→そのため、マージとリベースは特定の人のみにするなどの制限を設ける場合がある。

★マージは枝分かれしたブランチを一つに統合することを意味する。コミットされる度

 にブランチは1つずつ版を重ねていくことになる。コミットは1ファイルだけでなく 

 複数のファイルが含まれている。

 

そのためマージ処理とは・・・

1.同一ファイルに行われた変更を統合する

2.コミットに含まれるファイル全体を統合する

ことを意味する

 

 

マージ処理の方法(上記開発の流れを使用して説明する)

1.fast foward(ファストフォワード)=早送り

 マスターをチェックアウトしている状態で、bugfixをマージする

git merge bugfix

→マスターブランチにbugfixが組み込まれる!

 

 

2.ファストフォワードしないマージ

git merge 2.0

 このマージによって新しいコミットができる。ファーストフォワードと違い枝分かれした履歴を保持した状態で新規作成する

 同じコマンドを実行しても、ファーストフォワードとファストフォワードしない異なる動作をするが、gitは賢く動作する。

 

 

3.rebase(リベース)

 例えば、バグ対応版ブランチとサンプルプロジェクト2.0ブランチの開発を継続する。

2つが並行している中でバグ対応ブランチが1.0の元に変わる→これをrebase(リベース)という。

 

 2.0は複数のメンバーに共有されていることが多い。2つが並行している中でバグ対応ブランチが1.0の元に変わり1.1となる。そのためリベースすると、1.1は1.0から派生している。1.1と並行している2.0は、共有リポジトリへpushできなくなってしまう

 

→厳密に言えば、強制的に上書きはできるが、バージョン管理システムを利用している開発では、版の履歴が重要となってくる。

              ↓

対策として、共有リポジトリではリベースしないこと、ローカルのみに存在するブランチに対して操作することが上げられる。

 

 

コンフリクト(conflict)

マージを行うと、コンフリクト(conflict)衝突が発生する場合がある。

衝突とは、マージを実行した時に「同じファイルの同じ行に違う変更をしていたブランチとブランチがマージした場合を指す。

この場合gitはどちらを採用すればいいか分からない状態が生まれるため利用者の判断が必要となる。

pullでも起きる(プルはフェッチとマージを行っているため)

 

コンフリクトの対処

まず、コンフリクトが解決するまで処理を停止させる

gitがどこのソースコードで発生したか、詳細な情報を提示してくれるため、提示された内容のどちらを採用するかを判断する。→コンフリクト解消

 

git status

→マージが失敗したソースコードを確認できる

 

解決後修正したコードに対して、索引(index)に追加する必要があり、gitに修正したことを知らせる必要がある。

最後にコミットを実行してコンフリクトは解決する。

 

 

Gitコマンド

git branch ブランチ名新しいブランチを作成するコマンド

git branch -d[-D] ブランチ名ブランチの削除するコマンド(-Dは強制的に削除

                る)

 

 

git checkout[switch] ブランチ名別のブランチに切り替えるコマンド

git checkout[switch] -b[-c] ブランチ名新しいブランチを作成して切り替える

                      マンド

 

 

git diff   ファイル名:Gitリポジトリ内の変更を確認・比較するために使用するコマンド

 

 

git log :gitリポジトリの履歴を表示するコマンド

 

 

git stash:作業中の変更を一時的に保存し、作業ディレクトリを整理するコマンド

     →変更点を一時的に棚に上げて、綺麗にし他の作業が終わった後に再度戻っ

                        て作業を始められる

 →git stash listスタッシュした一覧を表示する。

  git stash apply[stash @{スタッシュ名}]最後にスタッシュしたもの[指定した

                      スタッシュ]作業ディレクトリ戻す

 

  git stash pop[drop stash @{スタッシュ名}]最後にスタッシュしたもの[指定し

                        たスタッシュ]削除する

 

  git stash clearすべてのスタッシュを削除する