GitHubのissueトラッカーが便利

以下は古い内容

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

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

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

http://gyazo.com/e961487bc697873c648db02d54b72a60.png

用途

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

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

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

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

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

作者への機能提案、pull request

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

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

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

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

issueにIDがある

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

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

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

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

http://gyazo.com/a00f63ae2ec990d9e3a3dd4869bac739.png

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

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

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

http://gyazo.com/25eb1c48abf08c155c60f1aac5f76ecc.png

issueトラッカーを使った開発手順

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

複数人での開発に便利

1. issueを立てる

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

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

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

2. ローカルbranchを切る

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

% git checkout -b 21_expand_short_url

3. commitしてpushする

issue IDをつけるの忘れるな

% git push origin 21_expand_short_url

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

4. issueにメモを書く

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

5. masterにrebaseする

% git rebase -i master

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

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

6. masterにmergeしてpushする

% git checkout master

% git merge 21_expand_short_url

% git push origin master

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

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

% git push origin 21_expand_short_url

あとはwebでプルリクする

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

7. issueをcloseして終了

masterにmerge前にrebaseする

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

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

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

良いことだらけ