GitHubを雰囲気で使っている(pull request)

GitHubでチーム開発を実施するようになり、pull requestの時には色々気をつけることがあるなと思い、整理したいと思います。

要約

レビューイ時

• pull requestの内容を分かりやすく
• レビュアーからコードレビューを受ける
• checksでの設定項目をクリアする
• masterブランチの最新をマージする
• masterブランチへマージする

レビュアー時

• 気になったことにコメントする
• 変更を承認する

説明（レビューイ時）

pull requestの内容を分かりやすく

他者が理解できるような内容を記述することが求められます。具体的には以下のようなことを実施しています。

• プロジェクト管理ツールなどの関連URLを載せる
  • 開発の背景などが書かれているためです
• やったことを書く
  • コード変更の差分だけでは意図が伝わりづらいためです
• 特に確認してほしいことを書く
  • 開発に際して不安に思っていることがある場合には、それを明確に伝えることでフィードバックを得やすくなります

レビュアーからコードレビューを受ける

コードレビューで指摘を受けた場合には、改めてローカルのブランチで開発を行います。
その際にpull requestのタイトルに[WIP]をつけておくと良いと思います。

WIPというGitHub Appsが導入されている場合にはmasterへのマージを抑制することが可能です。
GitHub Apps - WIP · GitHub

checksでの設定項目をクリアする

前述のWIPやCircle CIといったAppが連携されている場合にchecksの項目にステータスが表示されます。
各Appが成功する条件を満たして、変更内容をマージ可能にする必要があります。

masterブランチの最新をマージする

pull requestの元になっているブランチに対して、masterブランチの最新をマージする必要があります。

masterブランチへマージする

これまでの内容をクリアすることでようやくmasterブランチにマージすることができます。
GitHub Flowのようにmasterブランチとtopicブランチしか存在しないブランチ戦略を採用している場合にはsquash and mergeで無駄なコミットログをまとめてマージするのがオススメです。

説明（レビュアー時）

気になったことにコメントする

Files changed画面でソースコードにコメントを残す
Reviewing proposed changes in a pull request - GitHub Help

変更を承認する

必須レビュー機能が設定されている場合、レビューの結果がApproveされていないとマージできません。
Approveを選択して変更を承認します。

まとめ

PR時にチェックが強制されることでチーム開発でも秩序が守られるのはありがたいことです。

GitHubを雰囲気で使っている(remote URL)

GitHubでcloneするときに公式的にはHTTPSが推奨なのを知りませんでした。

help.github.com

認証が毎回必要なのでは？と思いましたが、保存できるので1回済ませたら以降は不要なようです。

help.github.com

HTTPSならプロキシ環境下でも問題ないのが推奨ポイントのように見受けられます。
HTTPSだと認証情報の設定が分かりやすいので、周りにはHTTPSを推奨していこうと思います。
SSHをよく知らない人はそれなりにいるのでは？という気がしています。

メモを共有するWebアプリを作った

メモを共有するWebアプリを作りました。

kollecton.hi1280.com

ほぼWikiみたいなものです。

ここでは、どのように作ったのかの概要、製作の感想を紹介したいと思います。

Webアプリのコンセプト決め

まずはWebアプリのコンセプトを決めました。
個人的に知識は共有することに価値があると思っているので、その発想を中心に考えていきました。

その発想から世の中に知識を共有するサービスが色々あることに気づき、最終的には以下を実現することにしました。

• Markdown記法
• 匿名
• 誰でも編集
• 個人用途でも可

似たサービスのコンセプト、機能、UIデザインを参考にしました。

• 情報共有
  • esa.io
  • DocBase
• オンラインドキュメント
  • Googleドキュメント
  • Dropbox Paper
• 各種Wiki

使用技術の選定

個人活動として何かを作る際には、新しい技術を最低１つ採用することを個人的に決めています。
今回は、今後のWebフロントエンド界隈でさらに注目されそうなAWS Amplifyを採用することにしました。
UI部分は使い慣れているAngularを採用しました。

具体的には以下の内容になりました。

• Angular
• AWS Amplify
  • AWSのリソースをWebクライアントから直接操作可能なライブラリ
• 各種Angular向けモジュール(ng addで追加可能なもの)
  • PWA(@angular/pwa)
  • Angular Material(@angular/material)
• 各種npmモジュール
  • ブラウザ向けオンラインエディタ
    • codemirror
  • 編集履歴を表示
    • jsdiff
    • diff2html
  • Markdownコンパイル
    • Marked
    • highlight.js
    • github-markdown-css

製作中に学んだこと

AWS Amplifyの基本的な使い方

AWS AmplifyはS3やAppSyncといったAWSのリソースをクライアントから扱えるようにする仕組みが整っています。その仕組みに応じた使い方をするとAWSリソースが簡単に扱えるので便利です。
AWSのリソースを最初から作ろうとすると様々な設定が出てきて迷いますが、そのあたりをサポートしてくれます。

Angularのルーティング機能

公式ドキュメントを参照するとルーティング機能の詳しい内容が書かれています。
多層のコンポーネントを設定する方法が役立ちました。
https://angular.jp/guide/router#milestone-4-crisis-center-feature

コンポーネント設計を途中で見直したことで、ルーティングの設定が大きく変わる場面がありました。
最初の段階でコンポーネント設計を検討しておくことも重要だと感じました。

複数のコンポーネントが存在する場合にそれぞれのコンポーネントに対してルーティングの際にどのようにデータが受け渡されるのかを理解しました。
https://angular.jp/guide/router#resolve-pre-fetching-component-data

ルーティング時のデータはObservableなデータなので、ルーティング時に複数コンポーネントが存在してもそれぞれのコンポーネントでSubscribeすることで同じデータを受け取れるというのはよくできているなぁと思いました。

製作中に苦労したこと

画面のデザイン

codemirrorは内部でCSSの設定を変えながらエディタの動作を作っているので、そのあたりを考慮しつつ画面のデザインを意図した通りにするのは大変でした。
Flexboxを活用して相対的な位置指定で違和感がないデザインを意識しました。
今回はAngular Materialを活用して、UI部品に対してのデザイン部分を省力化できたと思います。

まとめ

今回のような具体的なアプリを作ると、これはAngularやAmplifyでどうやるのだろうという課題が色々出てきました。
何か自分で考えたアプリを作るのは特定の技術を勉強するという意味でも役立ちます。

本サービスを作った際の具体的なノウハウをこちらにも載せていますのでご覧ください。