TL;DR
- ブランチの運用、プルリク、マージリクエストの書き方は、お互いのためにもちゃんと新人に教えよう。
はじめに
現在、開発でのバージョン管理やソースコードの変更点の管理等はGitで行うのが主流となっており
過去、SVNを使用していた会社も、Gitに移行して運用を実施してきています。
Gitは非常に便利なものですが、チェックアウト、開発、ブランチ作成、マージ、リクエスト等
複雑な操作が多く、ブランチ間の移動や、マージ、チェリーピック等の際に「自分のコミットが消えた...!?」と思ってしまう初学者の人も多いかと思います。
(実際は消えているわけでは無いので、落ち着いて操作しなおせば良いのですが、少しヒヤっとしてしまいがちです...)
本稿は、Gitでのリポジトリのチェックアウト、開発・修正、プッシュ、マージリクエストまでの流れを簡単にまとめ、下記のような、諸先輩方から指摘されがちな問題を減らしていき、Git運用のある程度の指針にすることを目的にしています。
（指摘が減ると、レビュイーもレビュワーも幸せ！やったね！！）
- よくある問題点、指摘
- コミット時のコメントが不明確
- マージリクエストが分かりづらい
- そもそもブランチ運用があやふや
※現在の会社に入社して1,2ヶ月。GitLabを使用しての開発のフローがなんとなくつかめてきましたが、wikiや会社内でのブランチ運用の明確なルールがなかったので、現在の自分のチェックリスト兼将来の自分の後輩育成用の資料として作成しました。今作ることで将来の自分の負担が減るね。天才じゃん。
Gitのブランチ運用
gitのブランチの運用は、様々な方向性があります。
- Git-Flow
- GitHub-Flow
- GitLab-Flow
- その他、上記のFlowの亜種
それぞれの運用方法にも特徴・有利な点・不利な点があるので興味があればその他の運用フローも確認してみてください。
- GitHub Flow – Scott Chacon
- はてなブログチームの開発フローとGitHub - Speaker Deck
- Introduction to GitLab Flow | GitLab
- Gitlab-flowの説明 - Qiita
準備
実際に開発を行う為のEclipse等の環境、およびGitのインストールは完了しているものとします。
1. リポジトリからのクローン
1.1. Gitからcloneする
-
対象のリポジトリにアクセスし、URLをコピー(HTTPSの場合)
例 : https://github.com/HirokiYoshida837/processingLibrary.git
自分のPC上で、リポジトリを置きたい場所をエクスプローラーで開く
-
対象の場所でシェルを開き、以下のコマンドを実行
$ git clone https://github.com/HirokiYoshida837/processingLibrary.git(※URLは上記の手順1.でコピーしたURL)リポジトリのフォルダ名を変更したい場合は、下記のコマンドになります。同一リポジトリを、同じ階層内に別のフォルダ名で保存したい場合などに使用します。
$ git clone https://github.com/HirokiYoshida837/processingLibrary.git 変更したいフォルダ名 エクスプローラーもしくは
lsコマンド等で、チェックアウトされている事を確認する
1.2. チェックアウトしたプロジェクトをEclipseで開けるようにする
- チェックアウトしたリポジトリに移動
- 移動先で以下のコマンドを実行する。
>
$ ./gradlew eclipse
gradle.buildファイルに、eclipse用プロジェクト生成のプラグインが含まれている為、上記のコマンドを実施するだけでeclipseプロジェクトに必要なファイル、クラスパスなどを生成し、必要なライブラリなどを取得してきてくれます。
- eclipseからプロジェクトをインポート。(詳細は割愛) eclipseからのプロジェクトのインポートは、他の資料などを参照。 Eclipseに限らず、好きなIDEでも問題有りません。
2. 自分の開発用ブランチの作成
2.1. masterブランチから新しくブランチを作成
今回は、チケット番号#1234599という架空のチケット内容を例に開発していきます。
※あくまで説明の為なので、実際には、自分の担当しているチケットで作成してください。
2.1.1. 適当な名前でブランチを作成しチェックアウトする
自分の担当しているチケット名に即した内容でブランチを作成します。
今回は、#1234599のチケットを担当しているので、ブランチ名は 1234599_hogehogeとします。
※hogehogeの部分は、チケット番号と、内容がわかるような名称をつけると良いです。
$ git checkout -b 1234599_hogehoge
これで、ローカルにブランチを作成し、自動でそのブランチに移動してくれます。
3. 開発
3.1. 開発、コミット
手順2. でチェックアウトしたブランチ上で開発を行っていきます。
プログラムをある程度書く度に、コミットしていく。
[補足] コミットの粒度、rebaseでのコミットのまとめ
gitではgit rebaseコマンドで、複数のコミットをまとめて一つのコミットにする方法があります。
ただ、コマンドラインからrebaseでコミットをsquashするのはなれない場合には注意が必要です
(デフォルトでは起動するエディタがvimなので操作がわかりにくい、複数のジャンルのコミットがまとまってしまって逆に分かりづらい、失敗して焦ってしまう、等)
3.2. プッシュ
作成・修正したプログラムは、現状、自分のPC上のリポジトリ(ローカル)にしか存在していません。
これをリモート(GitLabのリポジトリ)に反映させるためには、pushすることが必要です。
3.2.1. プッシュの手順
$ git push [remote-name] [branch-name] を実施することで、リモート側に反映することができます。ただし、下記の引用文のように、他の人がすでに変更を反映している場合(同一ブランチで、複数人で開発を実施している場合など)には、そのままではpushできません。
このコマンドが動作するのは、自分が書き込みアクセス権を持つサーバーからクローンし、かつその後だれもそのサーバーにプッシュしていない場合のみです。 あなた以外の誰かが同じサーバーからクローンし、誰かが上流にプッシュした後で自分がプッシュしようとすると、それは拒否されます。 拒否された場合は、まず誰かがプッシュした作業内容を引き出してきてローカル環境で調整してからでないとプッシュできません。
3.2.2. リモート上の変更を、自分のブランチに反映
$ git pull
※git pullコマンドを実行した場合、git fetchとgit mergeを自動的に実施するようになっており、自動的にリモートの変更がマージされてしまいます。(conflictが発生していた場合を除く)
できれば、個別にgit fetchとgit mergeを実施し、fetchの時点で、どこが変わるのかを把握した方が良いです。
3.2.3. masterブランチの変更を、現在のブランチに反映
ブランチでの開発が長くなってくると、masterブランチと、自分の開発ブランチとの間に差ができてきます。
すでに誰かが修正したバグ修正・仕様変更を自分の開発環境に反映できていない場合には、仕様との乖離ができてしまいますし、また、最終的にmasterブランチへのマージ時にconflict(変更箇所の競合)が大量に発生する可能性があります。
なので、適宜、リモート上の変更を自分の開発ブランチへ反映させていくことが望ましいです。
- ローカル(自分のPC) で、masterブランチをチェックアウト
>
$ git checkout master - リモート上のmasterの最新をとってくる
>
$ git fetch origin master - 自分のローカル上のmasterに、origin/masterをマージ
>
$ git merge origin master - 自分の開発ブランチにmasterをマージ
>
$ git checkout 1234599_hogehoge>$ git merge master
4. マージリクエスト
4.1. テストをローカルで通してみる
マージリクエストを送る前に、ローカル環境でテストが問題なく通るかどうかを確認する。
問題があれば、エラーが出なくなるまで修正。
4.1.1. Eclipse等での単体テスト
タイトルのとおりです。テストクラスから、右クリックでテストを実施できます。
テストが書かれてない...?書けばよかろうなのｄ
4.1.2. gradleからテストタスクを実行
下記コマンドで、jenkinsと同じようにテストが実施できます。
$ ./gradlew test
テストの結果はtest/..中略../build/report/tests/の中にhtmlで出力されます。具体的にどのテストが失敗した等の情報が見れるので活用してください。
テストが書かれてない...?(略)
4.2. マージ先とのdiffを見る
マージリクエストを送る前に、マージ先との差分を確認します。
$ git diff [マージ先] [自分が開発したブランチ]
これによって、
- 変更量がどれだけか
- 意図していない箇所を間違って修正してしまっていないか
- コンフリクトがどのあたりで発生しそうか
- 自分で理解できていない処理がないか。コメントが適切にかかれているか。
- 不要なファイル、記述類が含まれていないか
- 個人のPC環境用の設定ファイル
- メモの消し忘れ
- 無意味な沢山の改行
- コメントアウトの残り
- etc...
がわかります。マージリクエストを送る前に、自分で一度、おちついて変更箇所に変な箇所がないかを確認する意味もあります。しっかり確認しましょう。
マージリクエストを送る前に、自分でおちついてソースコードを読むことで、悪い箇所・直したい箇所などを見つけられることもあります。
CLIで見る他にも、GitLabやGitHubでは、マージリクエストを書いている最中に、マージ先との差分を確認する事ができます。
その他、Git Diffで使えるツール・ソフトウェアは以下のリンクを参考にしてください。
- Git - 変更内容のリポジトリへの記録
4.3. マージリクエストを送る
テスト・確認ができたので、マージリクエストを書いて、送ります。
※環境の問題、特殊な問題で確認・テストが十分にできていない場合は、それも含めてマージリクエストを書いてください。
マージリクエストする際は、要点をちゃんとまとめたコミットメッセージになってるか確認する。
- この変更は、何によるものなのか(チケット番号とか)
- そもそも、ブランチ名をチケット番号に関連付けること。
- どのファイルを、どういう意図で修正・追加したか
- どの環境で動作確認、テストしたか
- etc...
GitHubでプルリク、GitLabでマージリクエストを送る前のチェックリスト！ - Qiita
こちらもチェック事項の参考にしてください。
4.4. マージしてもらう
マージしてもらいます。
4.5. マージ後のJenkinsのテストの確認
masterブランチへのマージ後、jenkinsが自動でテスト・ビルドを走らせます。
ローカルでテストが通っていても、環境の差等で意図せずテストが通らない場合があります。
ビルドエラーが出た場合、Jenkinsに出ているログを確認して修正、再度マージを依頼します。
CI環境がない...?(略)
4.6. デプロイ環境での確認
Jenkinsは、自動でテスト、ビルド、環境へのデプロイまでを行ってくれます。
(※行ってくれるように設定してあります。)
場合によっては、DBの差、実行環境の違いなどが影響していることもあります。
デプロイされた環境で、再度自分で変更箇所まわりを触り、問題ないことを確認しましょう。
CI環(略)
まとめ
以上で、おおまかな開発の流れの解説、Gitの運用についての解説おわりです。
Gitについてもっと詳しく知りたい方は、公式資料の『Git Book』を確認してみましょう！
(3. Git のブランチ機能あたりまで読むだけで、かなり理解が深まります。)
https://git-scm.com/book/ja/v2
Gitを使って、チームで快適な開発ライフを送りましょう！