チラシの裏からうっすら見える外枠の外のメモ書き

新聞に挟まってる硬い紙のチラシの裏からうっすら見える外枠の外に走り書きされたようなものです。思いついたときにふらふらと。

GitHubでIssueをブランチを切って直す

LINEのメッセージをDiscordに転送するプログラム「LINE2Discord」で、バグがあったのでそれ修正しつつ、GitHubでどのように問題が修正されるのかをまとめてみました。

リポジトリはこちら

github.com

 

 

 

1. Issueを切る

問題があるプログラムのリポジトリにあるIssueページでNew Issueします。すでにある場合は2へ

このときIssueはわかりやすく簡潔に書くべき(らしい)です。またリポジトリによってIssueの書き方などにお作法があるらしいので従ってください。

個人的にはLabelをつけてあるのがそれっぽいなーと思います。

 

今回はバグのIssueなのでLabelでbugを選択します。

Submit Issueを押せばIssueがOpenされます。

f:id:k-hyoda:20190427191433p:plain

こうなります



 

2. Issueのためのブランチを切る

Issueができると(リポジトリのオーナーがIssueを発行しない限り)リポジトリのオーナーに通知が飛びます。

そのIssueに対してコメントなどで詳細を求めたり、「仕様です。」と言い切るのであれば該当のIssueページでコメントしましょう。

ようやくIssueに対してコード的な対応を行う気になったら、ブランチを切ります。

コマンドでもSourceTreeなどのソフトウェアでもいいのでブランチを切りましょう。

ブランチ名にも命名規則があるそうですのでそれに従ってください。

GitHubのブランチ(リモートブランチ)は名前を重複させることができません。しかも削除したブランチについてもです。

なので命名するときは慎重に、重複していないかや今後重複しないかを考えながらブランチを切りましょう。

命名規則があるならその規則に従えばおそらく重複しないでしょう。先人たちがいます。

 

私はブランチ名に「ユーザー名/何をするか_Issue番号」をつけるタイプです。

何をするかを書くのが面倒なときはfix_Issue番号にします。

f:id:k-hyoda:20190427192835p:plain

今回は4です



できました。

 

3. 修正する

修正してください。

コミットとプッシュもしてください。

コミットするときにfix #Issue番号としておくとそのIssueと関連付けられ、Issueページにリンクができます。

その後デフォルトブランチにそのコミットが含まれるブランチがマージされるとIssueも自動でCloseされます。

f:id:k-hyoda:20190427193142p:plain

リンクができています

f:id:k-hyoda:20190427193238p:plain

Issueページにもこのようにリンクができました

 

4. PullRequestを出す

修正が十分できたら、元のブランチに合流させます。

ここで言う元のブランチとは、今作業をしているブランチの元となったブランチかもしれませんし、また別のブランチかもしれません。

合流させるときは競合を確認してコードに問題がないか確認するためにPullRequest(PR)を作成します。PullRequestはMergeRequest(MR)とも呼ばれるのでいろいろな呼ばれ方があります。

PRを作るリンクは修正を施したブランチのGitHubページに現れます。

f:id:k-hyoda:20190427193834p:plain

これです

これを押すとPullRequest作成ページが表示されるので、必要な内容をぱぱぱっと入力しちゃいます。

注意するポイントは、ページの上の方にあるマージ先ブランチが正しいブランチであるか確認しておくことです。

ブランチの木構造が複雑だとここでやらかす可能性があります。

大体はデフォルトブランチが選択されていると思います。

 

また、この時点で明らかに競合になるようなものがチェックされているのでその場合は競合を解決してからPRしましょう。

f:id:k-hyoda:20190427194559p:plain

実際のPR

 

5. コードレビューする

あとはコードレビュアーがコードに問題ないか確認するのを待ちます。もし自分でコードレビューすることになるなら別人になりきりましょう。

コードレビュアーにレビューしてもらったらPRにコメントでバシバシと指摘が入るかと思います。

LGTM?ナニソレってなるのでLGTMだけ覚えておけば困ることはないんじゃないかなと思いました。

LGTMはおもしろ画像で自分のユーモアのセンスを他人に伝えることができる絶好のチャンスです。

qiita.com

 

6. マージする

レビュアーが許可を出したのなら、早速ブランチをマージしましょう。

PRページのMerge pull requestを押すだけで勝手にマージしてくれます。

このときにコミットを追加してマージすることができるのでそのあたりもうまく書きましょう。

これで元のブランチにも修正した結果が反映されました。

デフォルトブランチにマージされたのであればIssueはCloseされているはずです。

また、デフォルトブランチにマージしたわけじゃないけどIssueをCloseするときや、自動でCloseされなかった場合はIssueページからCloseしましょう。

 

7. ブランチを削除する

作業で使ったブランチは必要なければ削除します。

残っているとまだ作業するのかな?と思いますし。

PRページにDelete branchボタンがあるのでそれを押せばブランチは消えます。

ローカルも不要であれば削除しましょう。

f:id:k-hyoda:20190427200049p:plain

削除

 

終わり

ここで「いかがでしたか?」と書くと一部の人達からクソ記事と言われるみたいですね。

これは私があるプロジェクトで実際に踏んだ手順です。

こういうのをもっと強化したGit Flowというのがあるみたいですけどとても大変そうだと思いました。

ということで現在公開しているLINE2Discord、よければ使ってみてください。

他にも指定しただけメモリを食いつぶすプログラムMemoLeak-Chanやリスト構造で素数を数えるListed-Primeもぜひ。

github.com

github.com

github.com