Skip to content

Instantly share code, notes, and snippets.

@rkmathi rkmathi/githubkaigi-00.md
Last active Aug 29, 2015

Embed
What would you like to do?
#githubkaigi

githubkaigi 01 GitHub実践入門

大塚弘記さん (@HIROCASTER)

  • mixi

本日のメッセージ

  • GitHubを利用した開発の世界を知る
  • GitHubを(利用|活用)する違いを知る
  • GitHub実践入門はガイドブック

GitHubの世界へようこそ

Pull request

  • PR
  • プルリ
  • プルリク

よくある世界

  • なんとなく変数名
  • なんとなく…

他の人の目に触れることがなく「あとで」変えるつもりだった変数名がそのまま本番へ…

GitHubのある世界

  • 他の開発者がレビュー
  • 他の人のコードを見ることが習慣づいている

2つの世界の差

習慣

  • 見る・読む・見られる・読まれる

機会

  • 修正・拡張・学習
  • PRに対するフィードバックを受けることができる

品質

  • 2eyes < over 4eyes
  • 1人より2人以上のチェック

心理

  • 不安・安心・自身

世界の中にも差

|使っているだけの人|活用している人 -|------------------|------------ GitHub|コードを管理する道具|コードの勝ちを高める道具 PR|差分を入れてもらう|対話・設計・改善 コードレビュー|-|する・してもらう

活用している人になる

使ってるだけのPR

  • 「このメソッド名は抽象的すぎませんか?」のようなコメントだけ

活用しているPR

  • 「このメソッド名は抽象的すぎませんか?xxxという名前のほうが具体的で良いと思うのですが!」

指摘は簡単、提案は難しい

  • 「何だこのコード!」って言うだけは簡単
  • そのコードをより良くするための行動をしよう
  • 悪いことを回避・解決するノウハウも

現実と戦う

現実

  • 粗悪なコード
  • 会社や組織の体制、ワークフロー
  • コストの話

GitHubを使うために学ぶことは多い

  • gitの操作
  • ワークフロー
  • コミットメッセージ
  • etc...

学べる情報はそこら辺にある

GitHub != 目的

  • GitHubの先にあるものを獲得しなければならない
  • 開発効率?品質?ビジネスの成功?ソフトウェア価値の向上?

githubkaigi 02 はてなブログ

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

  • 自動化しきれない部分を教えないと新人がリリースできない

解決案

まとめ

GitHubをメインに最大活用

色んな問題→そのたびに解決法を検討

ちょっとした工夫

ワークフローは改善し続けることが大切

githubkaigi 03 OSSとGitHub(仮)

@amatsuda さん

  • COOKPAD
  • Asakusa.rb

GitHub

ソーシャルコーディングの世界

  • プログラマにとって大切な「ソースコード」を、ソーシャルコーディングによって 誰もが開発できるようになった
  • 以前は「コミット権」を持つ一部の人しか開発に直接携われなかったが、今ならPRでOK

GitHub & Rails

  • GitHub自体がRailsで作られている
  • GHが最初にホストした大規模なOSSプロジェクト
  • Rubyコミュニティの熱狂的なGitブームを牽引

RailsプラグインとGitHub

  • RubyGems
  • Bundler
  • gem-src

How to patch Rails

  • GitHubでPR
  • コミッターの誰かがレビュー
  • コミッターの誰かがマージ

Ruby

  • 20年+の歴史
  • 3人のフルタイムコミッタ
  • 数十人くらいのコミッタ
  • Railsと違って、外部からのパッチはあまり来ない
  • あんまりGH使われない

How could this repo get 4000 stars?

  • ドキュメントをしっかり書いた
  • 「コミュニティ」に参加した
  • コミュニティの友人が広めてくれた

ドキュメントをしっかり書いた

  • README, Wiki
  • とにかく丁寧に
  • 英語がちょっとくらい間違えていても誰かが直してくれる

「コミュニティ」に参加した

  • GitHubだけがリアルじゃない
  • Asakusa.rbを設立
  • RubyConf, RailsConf, RubyKaigiへ
  • GitHubはSNS

教訓

  • ドキュメントがとても重要
  • コミットをきれいに
  • 名前重要

githubkaigi 04 How GitHub work

https://speakerdeck.com/cobyism/how-github-works-github-kaigi-tokyo-2014

@cobyism さん

  • GitHubのWebチームでデザイナーと開発者

GitHub

  • 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

HUBOT

TOASTS

大事なのは、ツールではなくツールの使用方法

Everythibg should have an URL.

Be patient

What works changes over time.

githubkaigi 05 GitHubで雑誌・書籍を作る

技術評論社 稲尾さん

Web+DB PRESS

執筆陣は一流のエンジニア

使ってるツール

  • GitHubで原稿管理とやりとり
  • md2inaoで変換
  • InDesignで管理

md2inaoとは

  • markdownを原稿に変換

ブランチモデル

作業者が、WIPなPRにを送る

  • 執筆時は、著者がWIP PRを出す
  • 編集時は、編集がWIP PRを出す

これを繰り返して作る

コミット数は、特集で大体500くらい

GitHubで何が変わったか

進捗が見える化された

  • 従来はアウトライン、草稿、完成原稿の3回位

メールを使わなくなった

雑誌・書籍づくりはソフトウエア開発に近づけたほうがうまくいく

  • 著者さんの普段のワークフローに近いから?
  • 雑誌や書籍もソフトウェアだから?

githubkaigi 07 入門書には載っていないGit&GitHub Tips

@yuku_t さん

  • Increments Inc. (Qiita)

話すこと

  • Qiitaに載ってた
  • GitHub Cheat Sheetに載っていない
  • 「入門Git」に出てこない
  • あとGitHubを使ったデモ

Conflict

コンフリクト発生時の問題

  • コンフリクトするとHEADとマージ対象が書き出される
  • "<<<<<<<<< HEAD"みたいな
  • 共通の祖先の情報を書き出す機能がある
  • $ git config --global merge.conflictstyle diff3

git stash

git stash save / pop

  • trackされていないファイルは残される
  • indexしたものもstashされる
  • そのせいで、indexの情報が欠落してしまう

git stash -u (--include-untracked) git stash -a git stash -k

git stash pop --index

全く新しいworking directoryがほしい

/path/to/git-core/contrib/workdir/git-new-workdir

addしてcommitせずにreset --hardしちゃった

git fsck --lost-found

ゴミ判定されたオブジェクトが書きだされる

  • .git/lost-found/commit/
  • .git/lost-found/other

hub

git rebase -i --autosquash

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
You can’t perform that action at this time.