- プルリ受け取ったことがある人 38%
- プルリ送ったことがある人 57%
- プライベートリポジトリ持ってる人 26%
- GitHub Enterprise使ってる人 21%
- atom使ってる人 28%
Session
Last active
August 29, 2015 14:02
-
-
Save rkmathi/55643cba6de503e417ec to your computer and use it in GitHub Desktop.
#githubkaigi
大塚弘記さん (@HIROCASTER)
- mixi
本日のメッセージ
- GitHubを利用した開発の世界を知る
- GitHubを(利用|活用)する違いを知る
- GitHub実践入門はガイドブック
- PR
- プルリ
- プルリク
よくある世界
- なんとなく変数名
- なんとなく…
他の人の目に触れることがなく「あとで」変えるつもりだった変数名がそのまま本番へ…
GitHubのある世界
- 他の開発者がレビュー
- 他の人のコードを見ることが習慣づいている
習慣
- 見る・読む・見られる・読まれる
機会
- 修正・拡張・学習
- PRに対するフィードバックを受けることができる
品質
- 2eyes < over 4eyes
- 1人より2人以上のチェック
心理
- 不安・安心・自身
|使っているだけの人|活用している人 -|------------------|------------ GitHub|コードを管理する道具|コードの勝ちを高める道具 PR|差分を入れてもらう|対話・設計・改善 コードレビュー|-|する・してもらう
活用している人になる
使ってるだけのPR
- 「このメソッド名は抽象的すぎませんか？」のようなコメントだけ
活用しているPR
- 「このメソッド名は抽象的すぎませんか？xxxという名前のほうが具体的で良いと思うのですが！」
指摘は簡単、提案は難しい
- 「何だこのコード！」って言うだけは簡単
- そのコードをより良くするための行動をしよう
- 悪いことを回避・解決するノウハウも
現実
- 粗悪なコード
- 会社や組織の体制、ワークフロー
- コストの話
GitHubを使うために学ぶことは多い
- gitの操作
- ワークフロー
- コミットメッセージ
- etc...
学べる情報はそこら辺にある
- GitHubの先にあるものを獲得しなければならない
- 開発効率？品質？ビジネスの成功？ソフトウェア価値の向上？
https://speakerdeck.com/shibayu36/hatenaburogutimufalsekai-fa-hurotogithub
@shiba_yu36 さん
はてなブログというサービスを開発しているチーム
- 5エンジニア & 2デザイナー
- 170 PR & 1,281 commits / Month
- 45 releases / Month
開発フローの問題発生→問題解決
- タスク管理
- レビュー
- リリース
ブログチームの開発の流れ
- issue登録
- issueに対応するbranchを切る
- 実装したらPRなげてマージ
GitHubとタスク管理
- 以前1: Redmineメインの時代
- 以前2: GitHubのissuesのみ
以前1
- タスクはRedmine、PRとかはGitHubで分けてた
- エンジニアもデザイナも、両ツールを見なければいけなくて面倒だった
- →issuesのみにしよう
以前2
- 開発者の見るツールが減る
- コードの連携が便利
- だけど…
- チームの重要なものは何かわかりづらい
- issuesには優先度、締め切りのがわかりづらい、誰がどのタスクをやっているの？
- →マネージャがチームの俯瞰ができない
カンバンで補助
- issuesに全タスクが入っていて、誰でも追加して良い状態
- 毎日朝にやるべきかを検討
- カンバンに、issuesの中で重要なものだけマネージャが選択
カンバン
- カンバンは2枚
- 「重要なものリスト」と「タスクの進捗状況」
これによって、
- 開発者はGitHub issuesを見るだけで大体OK
- マネージャはカンバンを見れば状況管理ができる
GitHubとタスク管理
- 開発者にとって一番効率のよいissuesをメインに
- カンバンで重要なものを管理
以前のレビューの流れ
- PRからレビューしてくれる人を探す
問題1: PRの状態がわからない
- レビュー依頼中？
- レビューして修正中？
- レビューもう終わってる？
問題3: ベテランだけがひたすらレビューすることに
GitHubのレビューツールは最高
- 但し促進は少ない
解決案
- レビューの状態をはっきり
- レビュー依頼一覧をわかりやすく
- ベテラン以外も開発に参加
レビュー状態ラベル
- レビュー状態をはっきりさせるラベル
- レビュー依頼
- レビュー中
- レビュー完了
レビューラベル
レビュータイム
- ランチ後 14:00 -
- レビューのきっかけができて毎日レビューするように
GitHubとレビュー
- PRだけだとレビューの促進が上手く行かなかったので、レビュータイムを導入した
デプロイはコマンド一発にしていた
- 実際にはリリース前の検証などがあった
- 流れが自動化できない
問題1
- マネージャに確認せずにリリースしてしまった
問題2
- 自動化しきれない部分を教えないと新人がリリースできない
解決案
- リリース用PRに手順を書くように
- https://github.com/motemen/git-pr-release
GitHubをメインに最大活用
色んな問題→そのたびに解決法を検討
ちょっとした工夫
ワークフローは改善し続けることが大切
@amatsuda さん
- COOKPAD
- Asakusa.rb
ソーシャルコーディングの世界
- プログラマにとって大切な「ソースコード」を、ソーシャルコーディングによって 誰もが開発できるようになった
- 以前は「コミット権」を持つ一部の人しか開発に直接携われなかったが、今ならPRでOK
- GitHub自体がRailsで作られている
- GHが最初にホストした大規模なOSSプロジェクト
- Rubyコミュニティの熱狂的なGitブームを牽引
- RubyGems
- Bundler
- gem-src
- GitHubでPR
- コミッターの誰かがレビュー
- コミッターの誰かがマージ
- 20年+の歴史
- 3人のフルタイムコミッタ
- 数十人くらいのコミッタ
- Railsと違って、外部からのパッチはあまり来ない
- あんまりGH使われない
- ドキュメントをしっかり書いた
- 「コミュニティ」に参加した
- コミュニティの友人が広めてくれた
ドキュメントをしっかり書いた
- README, Wiki
- とにかく丁寧に
- 英語がちょっとくらい間違えていても誰かが直してくれる
「コミュニティ」に参加した
- GitHubだけがリアルじゃない
- Asakusa.rbを設立
- RubyConf, RailsConf, RubyKaigiへ
- GitHubはSNS
- ドキュメントがとても重要
- コミットをきれいに
- 名前重要
https://speakerdeck.com/cobyism/how-github-works-github-kaigi-tokyo-2014
@cobyism さん
- GitHubのWebチームでデザイナーと開発者
- GitHubは約60%の社員がリモート
HAPPINESS comes first.
Build the company where YOU WANT TO WORK.
Everything else is A SIDE-EFFECT.
Life is TOO SHORT.
EXTRINSIC ←→ INTRINSIC
INtrinsic motivation means:
- FLEXIBILITY
- AUTONOMY
- OPENNESS
技術評論社 稲尾さん
執筆陣は一流のエンジニア
- GitHubで原稿管理とやりとり
- md2inaoで変換
- InDesignで管理
md2inaoとは
- markdownを原稿に変換
作業者が、WIPなPRにを送る
- 執筆時は、著者がWIP PRを出す
- 編集時は、編集がWIP PRを出す
これを繰り返して作る
コミット数は、特集で大体500くらい
進捗が見える化された
- 従来はアウトライン、草稿、完成原稿の3回位
メールを使わなくなった
- 著者さんの普段のワークフローに近いから？
- 雑誌や書籍もソフトウェアだから？
https://www.dropbox.com/s/utaud80bk5egse3/Atom%20%E2%80%93%20GitHub%20Kaigi_jp.pdf
@nathansobo さん
- Pivotal Labs
- Started Summer 2011
- Beta published Feb 2014
- Open sourced May 2014
@yuku_t さん
- Increments Inc. (Qiita)
話すこと
- Qiitaに載ってた
- GitHub Cheat Sheetに載っていない
- 「入門Git」に出てこない
- あとGitHubを使ったデモ
コンフリクト発生時の問題
- コンフリクトするとHEADとマージ対象が書き出される
- "<<<<<<<<< HEAD"みたいな
- 共通の祖先の情報を書き出す機能がある
$ git config --global merge.conflictstyle diff3
git stash save / pop
- trackされていないファイルは残される
- indexしたものもstashされる
- そのせいで、indexの情報が欠落してしまう
git stash -u (--include-untracked)
git stash -a
git stash -k
git stash pop --index
/path/to/git-core/contrib/workdir/git-new-workdir
git fsck --lost-found
ゴミ判定されたオブジェクトが書きだされる
- .git/lost-found/commit/
- .git/lost-found/other
git config --global rebase.autosquash true
git commit --squash <COMMIT>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment