• サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ
  • ビジュアル的にも丁寧でよくまとまっている
• デザイナのための Git
  • コマンドの要点がまとまったガイド
• gitの基礎 (全22回) - ドットインストール
  • ドットインストールのスクリーンキャスト
• Git - Book - いわゆる Pro Git
  • Git - Book - 日本語訳もある
  • Pro Gitの日本語版PDF等
• Gitのセットアップ - homebrewをフォークするためのGit&GitHub入門 前編 - A Way of Code
  • GitとGithubのセットアップ
• ブランチもマージも簡単な分散型バージョン管理システム はじめてのGit - WEB+DB PRESS Vol.50
  • WEB+DB PRESS 総集編 に含まれてる

変更の短いサマリ

2行目は空改行にして、3行目か詳細について書く
この書き方は世界共通
詳細部分はサマリだけで十分なら必要はない

• 見えないチカラ: 【翻訳】Gitのコミットメッセージに関する注意点
• コミットメッセージの書き方 - ククログ(2012-02-21)
• クリアなコードの作り方: 意図が伝わるコミットのしかた - ククログ(2012-03-13)
• 分かりやすいコミットログを書くこと - by shigemk2
• コミットメッセージの作法 #Subversion #git - Qiita
  • 命令形は宗派的なものだと思います
• 作法に囚われてコミットしないのが一番よくない

c.f. コミットメッセージのサマリで変更内容が説明できる粒度

メリット

• 何を変更/追加したのが客観的に分かりやすい
• 歴史改変の手助けになる
  • 間違った変更を戻す
    • gitでアレを元に戻す108の方法 - TIM Labs
    • Gitの使い方あれこれ
  • どこでバグが入り込んだのか調べる
    • git bisect で問題箇所を特定する #AdventCalendar #git - Qiita
• コミットを意識するようになる(コミットし忘れ防止)

コミットし忘れる/間違える

やろうと思えば修正できる、やり過ぎは体に毒

• gitでありがちな問題の解決方法まとめ #git - Qiita
• 【派閥別】Gitのコミットを間違えたときの対処法まとめ - 本当は怖い情報科学
• Git初心者が絶対に覚えておくべきコマンド - idesaku blog

コマンドで分かりにくい時はSourceTreeを使ってGUIで操作するのも手

• ググれば現実的に不可能な事以外はやり方が出てくる

• 見えないチカラ: 【翻訳】Gitをボトムアップから理解する
• モデルから知るGit
  • Gitの各コマンドの動きやref/remoteの動き等が図示されていて分かりやすい
• Git Cheatsheet
  • Gitのステージの流れで見られるチートシート
• Gitの仕組み - homebrewをフォークするためのGit&GitHub入門 中編 - A Way of Code
  • コミットオブジェクトとか

Git リファレンス

• 逆引きGit | サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ
• transitive.info - Git 使い方 見出し一覧
• Gitによるバージョン管理 | オーム社eStore(β)
• bash/zshのgit補完

• Redmine/JIRA/Trac等のチケット管理するツールが必須
• 今回はRedmineをベースに進める
• コードを書く前にチケットを切る
  • Ticket First
  • チケットがないコミットはしない(例外はありそうだけど)
• チケットは閉じられる事が前提とする
• やることが全部チケット化されてるのが理想
• コードとチケットを関係付ける
  • コミットメッセージ Fixed #123

• チケットは仕様ではない
  • 仕様は仕様でドキュメントにおとすべき
• チケットで全てを管理しようとしない
  • できるだけ、チケットを作って閉じるだけを意識できるようなものがいい
• チケットを放置する状況を作らない
  • 重すぎるチケットの分割
  • 期限切れのチケットの退避
  • TiDD に scrum 混ぜると幸せになれるんじゃない？ - かおるんダイアリー
  • TiDD初心者によく聞かれる質問part1～チケットが放置されがちです #tidd: プログラマの思索
  • チケット駆動開発のアンチパターン: プログラマの思索

• チケットステータスの簡易化
  • 新規
  • 進行中
  • 解決
  • フィードバック
  • 終了
  • 却下
• 進行中がずっと続くほどチケットは大きくしない(やるなら自動化)
• 解決したら直ぐチケットを閉じる
  • レビューをするなら、レビューのチケットを新規で作る
• 却下はあってもいいけど、あんまり使う機会無い気もする(管理する人向けなのかも)
• チケットの進行度は0%か100%でいい
  • "新規"/"終了"と被るので操作しなくてもいい

• タスクが分割できる
• GTDに似てる
  • 最初にやりたいことを吐き出しておく
• 並行処理がしやすい
• 1日に処理できる量が見えてくる
• 他の人がチケットを見て作業内容を把握しやすい
• 意外とやってると楽しい
  • [Software]辞めていった人達が作ったシステムの保守を楽しいものにする - ariyasacca(2012-03-18)
  • チケットを処理するリズムが生まれると開発がスムーズに進む

• チケットを処理をするリズムを生む粒度にするのが大事
• チケットを見て、チケットの終了条件(ゴール)が分かる大きさ
  • チケットを見てゴールが複雑だと思ったらそのチケットは分割
  • 複数のゴールがあるなら、できるだけ一つのゴールにする
• チケットは細分化して、放置されるようなタスクのサイズにしない
  • 一日で終わらないようなチケットは作らない
• 大きなチケットがある場合は分割する
  • 大きなチケット(親チケット)の下に子チケットを作って分割する
  • 子チケットを全部処理すれば親チケットも終わる
  • 子、孫とネストが深くなりすぎるなら、親チケット自体を分割した方がいい
• 感覚的には数コミットの範囲で終わるチケットになる気がする
• TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？: プログラマの思索

typo

• 動作に影響がない程度の小さなものならそのままコミット
  • チケットは作らないでそのままdevlopブランチにコミット
• 必要なら、git commit --amend や git rebase -i などでコミットをまとめる
• バグにつながってるものなら、チケットを立てる

bugfix

• バグについてはできるだけチケットを作っておく
• バグの再現手順などをチケットに書いておくといい
• バグの原因/解決はコミットメッセージにも書く

機能別

• 画面は結構大きな単位
  • その画面のゴールが見えてないなら"画面"単位のチケットは避ける
  • 客観的に終わりという線が敷きにくい

コード

• プログラマ以外も利用するなら、コードに深く入りすぎたチケット名は避ける
• あまりプログラムによりすぎないチケットにした方がいい
  • 若干利用者視点
• プログラムについてはコミットメッセージ等に書く

他

• 他の人が見ても何を書いてあるのか分かるようにする
• ゴールが分かるような説明にする

• 3年使ったRedmineの使い方について共有したい10のこと | 世界 - daipresents!!
  • redmineで運用するために役立つこと
• 離れた場所で働くチームのつくり方〜１年間のアイルランドでの実践で学んだこと - Social Change!
  • リモート開発と開発スタイルについて
• チケット駆動開発で Pivotal Tracker を上手に使うための4つのポイント - Social Change!
  • TiDDの方向性や粒度、注意点等よくまとまってる

• gitのブランチモデルを補助するコマンドラインツール
  • bash/zshなどから使う(自分はzsh利用)
• MacのGUI Git SourceTree もサポート
  • SourceTree 1.5: Going With The Flow – Bitbucket

A successful Git branching model

• 見えないチカラ: A successful Git branching model を翻訳しました
• Gitのブランチで効率的に開発・運用・保守・管理する方法 - (DxD)∞

Gitのブランチ機能を使った開発モデルの事

• TiDDととても相性がいい
• iOSアプリ開発とも相性がいい

簡単にまとめると

• 常にリリース可能なブランチを持っておく(master)
  • git-flow release
• 代わりに開発の主体になるブランチを持つ(devlop)
• 機能開発やホットフィックス(チケット的)などは、それぞれブランチを切って開発する
  • トピックブランチと言われるもの
• ブランチのマージは–no-ffフラグを使い、どのブランチで開発してたのかを履歴に残す

git-flowで切るブランチをチケット毎とすると分かりやすい

1. チケット番号でGitのブランチを切る = チケットオープン

   git-flow feature start id/TICKET_ID

2. チケットの内容に関するコミットする
3. コミットが終わったブランチをマージしてブランチを閉じる = チケットクローズ

   git-flow feature finish id/TICKET_ID

後はこれをチケット毎に繰り返していけばいい

• TiDDとgit-flowを合わせた開発手法について | Technology-Gym
• Gitにおけるトピックブランチの使い方 | EIPラボ

• git-flow releaseはgit tagを付けるため、バージョン番号が必須
• git-flowはリリースが頻繁(1日数回等)な場合は相性悪いと言われる
  • Git で日々の共同作業やリリース作業をサポートする git-daily を作りました | GREE Engineers' Blog
• iOSアプリのrelease(App Store審査がある)はそこまで頻繁に起きない
• iOSアプリのVersion = git-flow releaseのバージョン なので分かりやすい

• GitHub直伝 プルリクエスト活用の3つのコツ « A-Listers
• Scott Chacon on the Interwebs

Githubのような、Pull Requestを中心とした開発モデル

1. ブランチを切る git-flow feature start id/TICKET_ID
2. ブランチをpushする git-flow feature publish id/TICKET_ID
3. Pull Requestを送る
4. 開発/コミット
5. push(Pull Request/ブランチ上にコミットは溜まっていく)
6. Pull Requestを閉じる(リモートのブランチは自動で閉じる)
   • Acceptの場合はローカルもマージして閉じる git-flow feature finish id/TICKET_ID
   • Denyの場合は、ブランチを捨てる

git-flowを使った場合でもPull Requestを使った開発自体はできる.(まあ目的が若干違う)

• 2,3はGithubならhubコマンドを利用
• Gitでリモートの共有リポジトリにあるブランチを消す時のメモ - longkey1::blog

git-issue

Github/redmineのチケットをコマンドラインから処理するツール

• チケットの詳細を見る
• プロジェクトのチケット一覧を見る
• チケットのアップデート(編集/ステータス更新/閉じる)
• チケットを元にブランチを切る/コミットする

チケット操作周りは一通りできる便利なCLIツール

percol + git-issue

• ブランチを切る際にチケット番号を手動で入力するのは面倒臭い
• percolとgit-issueを使って、redmineのチケットをブランチに切って作業するのが捗る設定 | Technology-Gym

• TiDDはツールありきな部分がある
• => ツール等環境を良くすればそれだけ便利になる
• => より効率のいい方法やツールなどを探す/作るべき
• git-flow と TiDD は相性がいい
  • ブランチ = チケット
• 粒度　: チケット = ブランチ >= コミット
• TiDDとgit-flowを合わせたワークフローによりコミットの癖が付く
• チケットとコミットメッセージの2方向から説明ができる