こんにちは、キノトロープアカデミーです。

「キノトロープアカデミー」は、Web業界のトップランナーである株式会社キノトロープの社員が講師を務めるオンラインアカデミーです。リモートワーク時代に不可欠な「個のスキル」を高め、職人のような「匠」を目指す人を増やしたい。そんな願いを込め、基礎から経営判断、業務フローまで、一生モノのナレッジを惜しみなく公開していきます。

＜中級編 第16回＞
システム開発 バージョン管理とGit 第3回
についてお伝えします。

担当は高橋です。

複数人での同時開発を安全に進めるためには、ブランチを作成して歴史を分岐させ、各自の変更履歴をプッシュやプルによってリモートリポジトリと共有・同期していくことが不可欠です。

作業完了後はそれぞれの変更内容をマージによって統合しますが、同じ箇所の競合が起きた際には手動でコンフリクトを解消し、履歴の不具合にはリバートやリセットといった取り消し操作を正しく使い分ける必要があります。

ただし、Gitはすべてを自動化してくれるわけではないため、チーム内でGit flowなどの適切な運用ルールを定めて共通認識を持つことが、バグの混入を防ぎ作業時間を最小化するための最大の鍵となります。

”システム開発 バージョン管理とGit 第3回”をテーマに、
今日お伝えしたいことは3つあります。

この記事はシステム開発の初心者の方や、バージョン管理について聞いたことはある、または少しだけ利用したことはあるが、しっかりとは理解できていない人向けとなります。

第１回目は、バージョン管理はどのようなものかのイメージを持てるようになるための内容となっています。

第２回目はバージョン管理システムであるGitについての概念と基本操作について、第３回目としてはGitの基本操作と運用についての内容となっています。

初めにStep3の「ブランチを切る」についてです。Gitでのブランチを切るとは「歴史を分岐させる」という意味合いとなります。よく、「ブランチ切ってから作業を行ってください」と言われたりする場合があるかと思います。

そもそもブランチとは歴史の流れを分岐して記録していくための物となります。

分岐したブランチは他のブランチの影響を受けない為、同じリポジトリ内で複数の変更を同時に進めることが可能となります。

ブランチは本流となるブランチから切って、「機能追加」「バグ修正」「リリース」等を作成します。

実施したい用途に分けるのが一般的です。ブランチ名には各自で命名出来ますが、「1」や「A」等ではなく「header」「topPageSlideBannerBugFix」など「追加機能名」「バグ名」にするとぱっと見で分かりやすいでしょう。

また、こちらの図ではすべてのブランチをmasterブランチから切っていますが、
masterから必ず切る必要はありません。

次に、Step4のプッシュとプルについてです。
まずプッシュ（push）とは、ローカルリポジトリの歴史をリモートリポジトリへ反映・アップロードすることです。

次に、プル（pull）とは、リモートリポジトリの歴史をローカルリポジトリへダウンロードすることを指します。

こちらの図で、赤枠で囲った箇所になります。

各自のローカルリポジトリから歴史のアップロードをプッシュし、リモートリポジトリからローカルリポジトリへダウンロードをプルするという流れとなります。

Step5のマージ(merge)とは、歴史の統合という意味合いとなります。つまりマージは現在のブランチへ他のブランチの更新を取り込むことを指します。

こちらの図ではmasterから2つのブランチを切り、masterへ統合するという流れになります。

SourceTree上で、マージ前とマージ後とで見比べてみましょう。

見ていただきたいのが、一番左の樹形図です。2つの分岐から合流しているのが分かるかと思います。

次に、Step6のリバート(revert)とリセット(reset)についてです。Gitにはリバートとリセットの2つの取り消しが存在します。

リバートはコミットの打ち消しコミットになります。

対して、リセットはそのままの意味でコミット自体をなかったことにします。

リバートを行うと次のようになります。

こちらの図のようにRevert “トップページ修正” となっており、トップページ修正というコミットに対しての打ち消しコミットとなります。

一方リセットを行うと、次のようになります。

リセット前は先程行った「リバート」と「トップページ修正」の2つのコミット履歴が残っています。

リセット後にはその2つが消えているのが分かります。

結局、どっちの取り消し操作を使えば良いのでしょうか。実際に行ってみてリバートとリセットの違いは次の通りです。

・リバートはコミットログを残し、過ちを認める。
・リセットの場合コミットログは残らず、記録抹消。

リセット操作は場合によっては後戻り出来ない操作となるため、注意して行う必要があります。特に理由がなければリバートを使うと良いと思います。

次にマージに関連して、競合・コンフリクトに関して説明します。

競合(Conflict)とは互いに競り合っている状態のことを指します。
例えば、同じファイルを同時に触って、コミットとプッシュを行うと競合が起こることがあります。

その場合、コンピューターはどっちが正しいかまでは判断出来ないため、人間がどちらが正しいのか修正してあげると競合が解消されます。

では、故意に競合を起こしてみましょう。

まず、本流となるmasterブランチにて「conflict.txt」を作成します。テキストの中は左下のようになっています。

masterブランチより緑色ブランチを切り、「conflict.txt」の4行目、「あ」にテキストを入れます。

続いて、緑色ブランチと同じく、黄色ブランチを切り、「conflict.txt」の5行目、「い」にテキストを入れます。

先に、緑色ブランチをmasterへマージします。続いて、黄色ブランチをmasterへマージします。すると競合が発生します。

では、競合が起こったファイルを開いてみましょう。

自分が入力していない変なテキストが挿入されている、と焦ってはいけません。

競合が起こった際はこの様になり、人間の手でどちらが正しいか直してあげる必要があります。見方について説明していきたいと思います。

青枠の箇所が、「master」で先にマージ済みの緑色ブランチの修正が含まれた状態です。黄色の箇所が、後からマージを行った黄色ブランチの修正が入った状態になります。

というわけで、正しい所だけ残して保存しましょう。

正しくはこのような内容となります。「あ」と「い」には値が入った状態となります。

競合を解消したら、通常通りコミットとプッシュを行えます。これで、競合解消されます
また、不用意に他人の修正範囲を元に戻してしまうといった心配がなくなります。

結果として、第１回中で問題点として上げていた「複数人で1つのファイルを触るとデグレが起きやすい」という問題が解決することができます。

なお、競合について気をつけたいことは、コンフリクト自体は悪いことではありません。チーム開発が活発であれば自然と起こるものです。

ただし、不用意にコンフリクトしないように気をつける必要はあります。ブランチを作成する際は、正しい箇所(最新のmaster等)から作ることや、チーム開発において、作業の順番や担当の割り振りなどで大きなコンフリクトの発生などが起きないように調整することは可能です。

最後に３つ目「Gitの運用」についてです。

Gitを利用することで開発を進めるうえでの問題点を解決できる面はありますが、すべてを自動的に行ってくれるものではありません。そのため、Gitを利用する際に会社やプロジェクトにおける運用方法を決めることがとても重要となってきます。

Gitの運用方法を決めないまま進めていくと、コンフリクトが頻発したり、マージのミスやバグの管理が出来なくなってしまったりするからです。

いくらすべてバージョンが管理されているとはいえ、だれも把握できない管理状況では意味がないものとなってしまいます。

リリース作業や改修にも時間がかかるようになってしまい非効率です。
対して、Gitの運用方法を定めておくことで、管理がしやすく、チームのメンバーが理解しやすい・共有認識を持てるものとなります。

よくある運用方法としてはGit flowや GitHub flowなどがありますのでそれらを参考に実施に運用し、プロジェクトに最適に運用方法を定義することがよいでしょう。

一例としてはの運用フローです。

これは簡易的に記載している部分はありますが、よく利用しているベースとなる運用フローを示した図です。

このように、ブランチの切り方や確認方法、命名規則、コメント規則などの運用ルールを定めることで、作業期間、作業時間の最小化が可能となります。

最後までご覧いただきありがとうございました。

の３点についての内容でした。