Github vs Gerrit最終決戦
Aiming railsを書いてれぅ
(Padrinoにpushするときはテストしないといけない)
require 'padrino'
show-method Padrino::Application.call
show-method Padrino::Application#call
show-method Padrino::Application#dispatch!
Elixir書いてる
Pryで記事を書いた
コードレビュー + PR = Github最強
コードレビュー = 長い会議 …ではない!
対等、双方向、軽量に、レビューをするのがコードレビュー
ソーシャルコーディングのトレンド。でも結構敷居が高い気がする。
もっとレビューの話をしたい。
レビューツール Gerrit
ペアプロ→レビュー→またレビュー…
＿人人 人人＿
＞ 突然の斧 ＜
￣Y^Y^Y^Y￣
Gerrit Rietveldさんが作ったらしいよ
gerrit と github
gerritのいいところ
Patchsetの存在
コミット1つ1つに対して「Change-ID」が割り触られている
gerritはChange-IDが同じコミットは、SHA1の値が違っていても
同一のコミットと見做す
Change-IDが同じコミット群は変更履歴が残る
各コミットのdiffを参照出来るし、過去のコメントも消えない
Patchsetの記録のおかげで、コミットへのコメントがそのコミットに集約する
git rebase -iと親和性が高い
Githubの場合、git rebase やると、git push -fしなければならないから、しんどい
「アメリカ人は消しゴム持たず、だめだったら破り捨てたらいい」って例えの話。
Githubのひとはrebase使わなさそう
gerrit merit
- 無料
- 連携プラグイン(jenkinsとか)
- コマンドラインAPIもあるよ
クラウドに置けない系の開発(アイピーもの)
Github Enterprise?お金で躊躇して導入するならGerritでもいいと思われ
ソーシャルコーディングへの橋渡しGithubほどのオープンぽさがない
社内でホストするのはやっぱ大変で、重くなったりアップデートないといけなかったり、あとUIはGithubのほうがよかったりする。
「複数コミットのつながり」へのコメントが出来ない
ミサワリンクが画像展開されない
gerritのよいところは、オープンソースなところ。
see also
AimingのGithubを使った開発フロー
patchsetのコミットは3、4くらい
