と思っていた時期もあった (2017年2月3日)

以下は古い内容

issueトラッカーとcommit関連付けを使わないなら、GitHub使ってる意味無いです

issue使わないと、サーバーにsshでつないでgitリポジトリ置くのとなんら変わらない・・・

GitHubの各リポジトリにはissueトラッカーがある

メモ&TODOリスト&議論スレとソースコード管理がうまく融合してて、便利なので解説します(shokai)

実はissueトラッカーがVCSホスティングのコア機能

コードは手元にcloneできるけどissueはできない

GitHubは他社と差別化するためにかなり力入れてると思う

例 https://github.com/shokai/tw/issues

用途

未実装の機能、バグなどのtodoリスト

えらいハッカーだと、issueに書くだけで誰かが実装してpull requestしてくれるらしい

調査内容などをガンガン書く

1行で「このページの下のあたりのコードが参考になる」とかメモを書いておける

作者への機能要望、バグ報告

作者への機能提案、pull request

issue立てて議論スレにする。リポジトリ主と相談して新機能作る。

（コミッタが複数いる場合）タスクの割り振りに使える

画像やソースコードのシンタックスハイライト入れて綺麗に書ける

Markdownが使える

gitのcommitをissueに関連付けられる

issueにIDがある

上のissue list画像の#33とか、URL末尾の数字がID

コミットメッセージに#番号を書くと、issueにcommitが関連付けられる

issue#21に関連付けたい場合は

右側の83a8bb9という青文字リンクからそのcommitへ飛べる

もしくは、コミットメッセージに書かずにissueスレにコメントで @commit_id を書けばリンクになる

画像一番下の shokai commented ってやつがソレ

commit IDは % git log で確認できる

また逆に、commitからissueへは #21 という青文字リンクから飛べる

ブランチを切って作業する事で、同時に複数のissueを進めることが可能

複数人での開発に便利

例:新機能開発中に既存部分のbugを発見したら、bugのissue&branch作って開発と修正同時にできる

1. issueを立てる

タイトルわかりやすく書く

現状の問題点、必要な機能、参考になるURLなど書ければ書く

（複数人で開発してる場合）issue担当者を自分に設定する

2. ローカルbranchを切る

頭にissue IDをつけつつ、わかりやすい名前のブランチを切る

3. commitしてpushする

issue IDをつけるの忘れるな

IDつけ忘れても、@commit_idをgithubにコメント書けばissueに関連付けできる

4. issueにメモを書く

試行錯誤や調査はissueにコメントとして書いておく

5. masterにrebaseする

指示に従って、「squash」を使ってコミットを（なるべく）1つにまとめる

もし1つにまとめづらい内容の場合、issueを切る粒度が間違ってる可能性高い

6. masterにmergeしてpushする

6.1 もしくは、プルリクする

masterにmergeせずにプルリクし、GitHubでmasterにマージする

あとはwebでプルリクする

自分のリポジトリで、自分のmasterに対してプルリクが出せる

7. issueをcloseして終了

必要なし派だったけど、rebaseしろや派になった

思ってた以上にデメリットが全くないのと

mergeする時にコンフリクトしにくくなる

コンフリクトしても修正しやすくなる

良いことだらけ