Mergify - CI/CD pipeline optimizerThe Best Solution to Merge Your CodeMergify is a complete solution combining efficiency and customization. Mergify adapts to the way your team works and let you define your own rules. Why should you use Mergify to merge your pull requests?
GitHubでの”Merge pull request”の弊害 | POSTD
私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
MySQL 5.6での、マルチカラムインデックスとカラムごとのインデックスの比較 | Yakst
MySQL Performance Blogの翻訳。複数のカラムを指定したマルチカラムインデックスを使うべきか、カラムごとに別々にインデックスを作るべきかは悩ましい問題だ。しかし、MySQL 5.6で導入されたIndex condition pushdownの仕組みを理解すれば、マルチカラムインデックスを効率的に使うことができるようになる。 インデックスに関する話をしている時によく出てくる質問と言えば…マルチカラムインデックスを使うべきか、カラムそれぞれにインデックスを張るべきか、ということだ。Peter Zaitevがこれについて2008年に書いていて、その時の結論としては、マルチカラムインデックスが多くの場合においてベストな解決策だ、というこだった。しかし、最近のオプティマイザの進化によって、MySQL 5.6では事情は違ってきてはいないだろうか？ 準備 テストのため、以下のような2つ
あるフロントエンドエンジニアの1日 - Life goes on
Frontrend Advent Calenderの14日目の記事です。 風邪引いてちょっと遅れました…。 先週ですが、札幌でSaCSS Special4 Frontrend in Sapporoというイベントで講演させていただく機会がありました。 自分は"黒い画面"ことターミナルやコマンドに慣れていない方に興味を持ってもらおうという感じで、お話をさせていただきました。 ターミナルに興味が出てきたところで、「どうやって作業してんだろ？」っていうのが見ないと分からなかったりもすると思います。 自分は日常的にターミナル内で作業してるのですが、こんな感じでフロントエンドに関わる作業するのかなーという一例として書いてみます。あくまで イメージです。 10:00 出社してiTerm2を立ち上げる。 tmuxとtmuxinatorを使って、その日の作業に対応した、paneとかwindowとか指定してる
Git チームワークフロー: マージ (merge)、それともリベース (rebase) ? | Atlassian Japan 公式ブログ | アトラシアン株式会社
質問は簡単です。git と フィーチャーブランチ を利用しているソフトウェアチームにとって、完了済みの作業を開発のメインラインに取り込む最良の方法は何でしょうか？これは、確固たる意見を持つ両陣営によって繰り返し展開されている議論の一つですが、やはり議論には最低限の配慮を持って対応したいものです。 (その他の激しい議論の例としてはこれがあります: The Internet)。 リベースを行って、リポジトリの履歴をフラットかつクリーンに保つべきでしょうか？それとも、可読性と明晰さを犠牲にする事でトレーサビリティを得られる、マージを行うべきでしょうか？( ファストフォワード マージを禁止するなど。) 議論 このトピックは、vim と Emacs や Linux と BSD ほどまでには有名な論争の的とはなっていないものの、双方共に遠慮なく意見を述べ合っています。 all-things-git に
転職してから半年くらいでやったことまとめ - Perl日記
IRCを導入した 遠隔地で作業しているひともいた中でメールでのやりとりはとても面倒だった。 (同じオフィスで開発してるひとからもメールでいろいろ来た) だるかったので、ngIRCdを導入して、やりとりがすごく楽になった。(基本英語だが) リポジトリを分割した サーバに置いてあるものがすべて1つのリポジトリで管理されていた。(僕は泣いた) だるかったけど、頑張って適切なサービスの単位で分割した。 ファイルサーバ作った クラウドに置かないほうがいいファイルとか共有するため。 ユニットテスト直した ぶっ壊れていたのをとりあえず動くようにしてから、とにかく自分が触るところを中心に追加していった。 カバレッジが最初は30%くらいだったけど、いまは90%近くまで上がっていて、 僕に多少の精神的な安寧をもたらしてくれている。 Pull Reqestベースの開発にした それまでは(ローンチ後も)maste
グラフィカルなDiff/マージツール「Meld 1.7.5」リリース | OSDN Magazine
Meldの開発者は9月1日、GUIでグラフィカルに差分表示やマージを行えるdiffビューア/マージツール「Meld 1.7.5」をリリースした。プロジェクトのWebサイトよりダウンロードできる。 Meldはマルチプラットフォームに対応するマージツール。ファイルやディレクトリの差分を視覚的に表示できるほか、Git、Bazaar、Mercurial、Subversionなどでのマージ操作でも利用できる。2方向のほか3方向での比較もサポートするほか、自動マージモード、リアルタイムアップデートなどの機能もある。踏査環境はWindowsおよびMac OS X、Linux。ライセンスはGPLv2。 Meld 1.7.5は細かな機能強化が中心となる。gconfにおける誤設定の処理を改善し、ファイル比較で現在の行をハイライトするかどうかを設定できるようになった。コミットダイアログにアクセスできるキーボード
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blog.inouetakuya.info/entry/20130602/1370173582