[Git] Gitで用いるGit-Flowまとめ

<!-- wp:paragraph -->
<p>■出典： <a href="https://ko-dev-jp.com/2020/08/10/git-flow-j01/">[Git] Gitで用いるGit-Flowまとめ</a><br></p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><br></p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2><strong>目標</strong></h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>このポストでは、Git Flowの概念と必要性、作業にとって理解が必要な機能の用語と全体的な進行の流れについて説明します。<br><br></p>
<!-- /wp:paragraph -->

<!-- wp:heading -->
<h2><strong>目次</strong></h2>
<!-- /wp:heading -->

<!-- wp:list {"ordered":true} -->
<ol><li>Git Flow</li><li>Git Flowを考慮したきっかけ</li><li>事前準備</li><li>Branch<br>①Branchのライフサイクル<br>②Branchの命名規則（Naming Convention）<br>③Branch作業に必要なコマンド</li><li>Merge<br>①Branchマージ（merge）際、mergeの方向<br>②Conflict減らし方<br>③Conflictが出た状況の対策</li><li>Pull</li><li>Pull Request</li><li>まとめ</li></ol>
<!-- /wp:list -->

<!-- wp:paragraph -->
<p><br><br></p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":3} -->
<h3><strong>1. Gitフロー</strong></h3>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Git flowとは、Gitのブランチ<sub>branch</sub>を活用して、実行する作業の流れだと言います。どのような種類のブランチを作成して、一緒にマージ<sub>merge</sub>すべきかを方法論的に提案します。</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>■参考<br><a href="https://nvie.com/about/">Vincent Driessen</a>のA successful Git branching model<br>：<a href="https://nvie.com/posts/a-successful-git-branching-model/">https://nvie.com/posts/a-successful-git-branching-model/</a></p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><br><br></p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":3} -->
<h3><strong>2. Git Flowを考慮したきっかけ</strong></h3>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>複数の人とチームとして長期開発をする場合、<strong>運用ルールを定めずにGitを使用すると、競合<sub>conflict</sub>が度々起こるし、マージ<sub>merge</sub>のミスなどのハプニングがよくあります</strong>。Gitを使用するときに発生するミスを減らすために採用する案が「Git flow」です。</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><br><br><br></p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":3} -->
<h3><strong>3.事前準備</strong></h3>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>1）複数の人が共有することができるリモートリポジトリ<sub>remote repository</sub>を作成し、プロジェクトのソースコードをアップロードします。<br>2）必要があれば「.gitignore」を作成します。<br>3）ローカルPC上で動作するローカリポジトリ<sub>local repository</sub>を作成し、リモートリポジトリのプロジェクトをcloneします。</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>*「 .gitignore」<br>：変更履歴を無視したいファイルやディレクトリをまとめておいたリストです。リスト内のファイルおよびディレクトリの変更は、git addの際スキップされます。（しかし、思ったより適用ができない場合がよくあります。）</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><br><br><br></p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":3} -->
<h3>4.ブランチ</h3>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Branchは&nbsp;&nbsp;<strong>master、release、 develop、feature、hot-fix</strong>で、5つの開発実行ポイントを区分して進行します。</p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><li>feature<br>......&nbsp;個別機能の実装とバグを解決するブランチ</li><li><strong>develop</strong><br>......&nbsp;リリースのための開発を進めているブランチ</li><li>release<br>......&nbsp;リリースの前に活用するブランチで、最小限の調整だけするブランチ</li><li><strong>master</strong><br>......&nbsp;最上位のブランチで、プロジェクトを格納します。原本ソースコードを保存するため、ソースの修正をしない</li><li>hot-fix<br>......&nbsp;リリースが終わったプロジェクトの緊急修正対応（バグ等）をするためのブランチ</li></ul>
<!-- /wp:list -->

<!-- wp:paragraph -->
<p>Masterブランチの場合は、プロジェクトのバージョンをTagで付けてプロジェクトのバージョンを管理します。</p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":4} -->
<h4>①Branchのライフサイクル</h4>
<!-- /wp:heading -->

<!-- wp:list {"ordered":true} -->
<ol><li>一度生成がされると、削除されないブランチ<br>：master、develop</li><li>目的にとって使用された後に削除されるブランチ<br>：feature、release、hotfix</li></ol>
<!-- /wp:list -->

<!-- wp:heading {"level":4} -->
<h4>②Branchの命名規則<sub>Naming Convention</sub></h4>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>： "[branch name] - [日付、あるいはバージョンなど]"<br>（ex：realease-1.2もしくはdev01-200730）</p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":4} -->
<h4>③Branch作業に必要なコマンド</h4>
<!-- /wp:heading -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">$ git checkout master 
 //「master」branchに切り替え
（check out：現在のユーザが関与しているbranchで他のbranchへの移行）
$ git merge --no-ff release-1.2 
//「merge」（branchのマージ* merge方向については、4番（Mergeについて）を参照）
$ git tag -a 1.2 
//バージョン名などのプロジェクトの説明を付ける
</pre>
<!-- /wp:preformatted -->

<!-- wp:heading {"level":3} -->
<h3>5.Merge</h3>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>ブランチ間の変更事項を1つのブランチに結合することを言います。</p>
<!-- /wp:paragraph -->

<!-- wp:image {"id":974,"width":749,"height":350,"sizeSlug":"large"} -->
<figure class="wp-block-image size-large is-resized"><img src="https://kodevjpcom.files.wordpress.com/2020/08/git-merge-2.jpg?w=998" alt="" class="wp-image-974" width="749" height="350"/><figcaption><sub>gitチュートリアルに示されているmerge状況</sub></figcaption></figure>
<!-- /wp:image -->
<!-- wp:paragraph -->

<p>上記の状況を解決するプロセスは、チュートリアルを参照してください（<a rel="noreferrer noopener" href="https://git-scm.com/book/ko/v2/Git-%EB%B8%8C%EB%9E%9C%EC%B9%98-%EB%B8%8C%EB%9E%9C%EC%B9%98%EC%99%80-Merge-%EC%9D%98-%EA%B8%B0%EC%B4%88" target="_blank">ブランチとMergeの基礎</a>）</p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":4} -->
<h4>①Branchマージ<sub>merge</sub>時、マージの方向</h4>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p><strong>[Case]<br></strong>hotfixブランチを作成して、バグを正しく直したのかを確認し、<br>最終的に運用環境にリリースするためにhotfixブランチをmasterブランチにマージ<sub>merge</sub>する状況</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><code>git merge</code>&nbsp;コマンドで次のようにします。</p>
<!-- /wp:paragraph -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">$ git checkout master // branchのヘッドをmasterへ置く
$ git merge hotfix</pre>
<!-- /wp:preformatted -->

<!-- wp:paragraph -->
<p>masterのソースを元にしたhotfifxブランチのソースコードに、最新のコミット<sub>commit</sub>を持ってくるため、マスターにヘッドを置いてhotfixとマージします。このようなマージをfast-forwardです。</p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":4} -->
<h4>②Conflict減らし方</h4>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Conflictは、mergeする際に発生するソースコード間の<strong>衝突</strong>です。</p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><li>開発開始前に、最新のソースをpullして取得します（pullは6番を参照）</li><li>適正な時期にmergeをします（merge時期を遅らせるとconflictの修正が多くなるので）</li></ul>
<!-- /wp:list -->

<!-- wp:paragraph -->
<p><strong>masterブランチの変更を継続的に自分のローカルブランチに更新する</strong>ことが重要で、更新した後に自分のブランチをマージすれば衝突を最小限に抑えることができます。</p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":4} -->
<h4>③Conflictが出た状況の対策</h4>
<!-- /wp:heading -->

<!-- wp:list -->
<ul><li>&lt;基本&gt;衝突された部分を修正することができる場合には、コードを変更した後、結合を試みます。</li><li>マージする前の状態に戻します。</li></ul>
<!-- /wp:list -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">$ git merge --abort</pre>
<!-- /wp:preformatted -->

<!-- wp:list -->
<ul><li>コードを変更した後、マージする前に戻したい場合</li></ul>
<!-- /wp:list -->

<!-- wp:preformatted -->
<pre class="wp-block-preformatted">$ git reset --hard HEAD</pre>
<!-- /wp:preformatted -->

<!-- wp:paragraph -->
<p>以外にもrevert&nbsp;<sub>（コミット後の記録を残したままマージ前に戻す）</sub>、reset&nbsp;<sub>（コミット後の記録を残さず、マージ前に戻す）</sub>のコマンドがあります。</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p>マージが終わったら、あるブランチの中で必要ないものを削除します。</p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":3} -->
<h3>6.Pull</h3>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>pullコマンドは<br>1）fetch&nbsp;<sub>（リモートリポジトリの変更をインポートして、マージはしないこと）</sub>を実行した後、<br>2）マージ<sub>merge</sub>するコマンド<br>です。</p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><li>pull：リモートリポジトリのコミット<sub>commit</sub>履歴と私のローカルリポジトリのデータを結合したい時</li><li>fetch：リモートリポジトリのコミット履歴だけを確認したい時<br>（このとき、リモートリポジトリから取得した最新のコミット履歴は、自分のローカルリポジトリに「FETCH_HEAD」でインポートします。）</li></ul>
<!-- /wp:list -->

<!-- wp:paragraph -->
<p>したがって、コミットされていない変更があるままでPullをしたら、マージが失敗することになりますので注意してください。</p>
<!-- /wp:paragraph -->

<!-- wp:heading {"level":3} -->
<h3>7.Pull Request</h3>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Pull Requestとは、チームプロジェクトを進める際、開発者のローカルリポジトリの変更を他のメンバーに共有することです。ソースコードの変更内容を見やすく表示し、マージ予定事実をお知らせします。また、ソースコードのマージのコミュニケーションを行うことができ、問題発生時の履歴も確認することができます。</p>
<!-- /wp:paragraph -->

<!-- wp:paragraph -->
<p><br><strong>[開発時に進行されるPull Requestプロセス]</strong></p>
<!-- /wp:paragraph -->

<!-- wp:list {"ordered":true} -->
<ol><li>[開発者]機能の追加などの開発を進めます。</li><li>[開発者]機能追加が完了したら、pushします。</li><li>[開発者] Pull Requestを作成します。</li><li>[担当者] Pull Requestで変更を確認します。</li><li>[担当者]ソースコードの問題がなければマージします。<br>もし、確認の結果、ソースコードのマージが必要ない場合には、クローズします。</li></ol>
<!-- /wp:list -->

<!-- wp:heading -->
<h2><br>8.まとめ</h2>
<!-- /wp:heading -->

<!-- wp:paragraph -->
<p>Git Flowは、チームとして長期開発をする際に必要な効果的なプロジェクトのバージョン管理戦略です。</p>
<!-- /wp:paragraph -->

<!-- wp:list -->
<ul><li>開発が終わったソースコードを無理なくマージし、正しく動作するソースコードをリリース環境のブランチで管理することを目指しています。</li><li>developブランチのソースコードをrelease直前の状態で管理するのに無理がある場合は、中間検証のための<strong>Stagingのブランチ</strong>を作成してリリース直前のソースコードを管理する方法があります。<br>（staging用ブランチを作成するのは、開発に集中ができる環境を構成するという利点があります。）</li><li>Gitの操作を開始する前に、各作業の予想順序をシートにまとめた後作業に入れば、ミスを減らすことができると思います。</li></ul>
<!-- /wp:list -->

<!-- /wp:list -->

<!-- wp:paragraph -->
<p></p>
<!-- /wp:paragraph -->
<br>
<br>


<!-- wp:paragraph {"align":"right"} -->
<p class="has-text-align-right">Please visit here too!<br><sub><a href="https://ko-dev-jp.com/2020/07/30/git-flow/">[ Korean ]<br></a><a rel="noreferrer noopener" href="https://ko-dev-jp.com/2020/08/10/git-flow-j01/" target="_blank">[&nbsp;Japanese&nbsp;]<br></a><a rel="noreferrer noopener" href="https://okky.kr/article/831473" target="_blank">[&nbsp;</a><a rel="noreferrer noopener" href="https://okky.kr/article/757781" target="_blank">OKKY&nbsp;</a><a rel="noreferrer noopener" href="https://okky.kr/article/831473" target="_blank">]</a><br></sub><a rel="noreferrer noopener" href="https://qiita.com/liten623jp/items/cd553e8dc85a60500ce2" target="_blank"><sub>[&nbsp;</sub></a><sub><a rel="noreferrer noopener" href="https://qiita.com/liten623jp/items/d870e13ada7718a442c0" target="_blank">Qiita&nbsp;</a></sub><a rel="noreferrer noopener" href="https://qiita.com/liten623jp/items/cd553e8dc85a60500ce2" target="_blank"><sub>]</sub></a><br></p>
<!-- /wp:paragraph -->