squash and mergeしか使ってないけど全く困ってない
こういうことはレポジトリ構成・ワークフローと密接に紐づいているので、そういう前提を抜きにはどれがいいとかはいうことはできない。が、自分はいわゆるsquash and mergeのみの環境しかほとんど経験がないし、それで困ったことが一度もない、という話をしておきたいので書いておきたい、ので書いておく。 squash and mergeのメリットは書いてある通りで、基本的にPR内の細かい修正というのはゴミみたいなコミットが多く、メッセージも雑なことが多いので、それをコミットログに残しておくのは嫌だということがある。それよりは意味のある単位のコミットを残しておきたいし、それの単位はPRで行うのが良い、ということだ。 “Google-style” workflow デメリットの方は、いわゆるfeature branchというワークフローで顕在化する問題であると思う。で解決策はあり、それはワークフロ
炭坑の庭師 - steps to phantasien
Chromium と WebKit は二つの独立したプロジェクトだ。 ソースツリーはそれぞれ別で、そこにはインテグレーションの苦労がある。 WebKit 以外にも V8 や Skia など Chromium が依存している外部のプロジェクトは山ほどあるけれど, WebKit とは特にぴったりくっついている。 そのぶん二つの足並みをあわせる手間も際立つ。 以前、書籍 ”アジャイル開発の本質とスケールアップ” で リリーストレイン という大規模プロジェクトのインテグレーション手法を読んだ。 プロジェクトの内部で一段細かい時限リリースを設け、そのタイミングでインテグレーションする方法。 内部リリースにあわせてプロジェクト同士が依存している相手のバージョンを上げ、 壊れたところをなおすわけ。 Chromium と WebKit もこまめに相手のバージョンを新しくする。 主たる依存の向きは Chro
ブラウザのリリースサイクル短縮の利点と影響 | Web標準Blog | ミツエーリンクス
Mozilla Japan ブログにて、Firefox 5のRC版が公開されたことが発表されています。正式版は来週の21日リリースを予定しているようです。 Firefox 5 のリリース候補版を公開しました Firefox 4.0が公開されたのは3月22日ですから、3ヶ月で新しいバージョンが公開されることになります。この速さはリリースサイクルを変更したことによるものです。 Firefox のリリースサイクル短縮に向け、新しい開発チャネルを公開します 高速リリースサイクルに関するよくある質問 リリースサイクルが短縮されたぶん、いちバージョンでの機能追加は少なくなりそうですが、新しい機能を今までよりもずっと早く利用できる利点があります。たとえば、Firefox 5ではCSS Animationsなどが実装されています。今までであれば1年近く待つ必要がありましたが、今後は数週間で少しずつ新しい機
2つのChromeを共存させる方法(Google Chrome SxS) - os0x.blog
複数のバージョンのGoogle Chromeを同時に動かす方法 - 0xFFでは、かなり強引にスタンドアローンなChromeを作る方法を紹介しましたが、最近(Issue 35574 - chromium - Add side by side distribution - An open-source browser project to help move the web forward. - Google Project Hosting )正式に2つのバージョンを同時に動かす実装が導入されたので、それを紹介します。 まず、今のところ共存できるのは2つまで、片方はdev版相当canary版*1という制限付きです。その点はご了承を。 Google Chrome - Get a fast new browser. For PC, Mac, and Linuxで専用のインストーラーが公開されてい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Chromeの更新期間が6週間から4週間に短縮
