サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
C++参考書に、著作権が発生するほどのpull requestを受け入れたAuto anchor by tzik · Pull Request #139 · EzoeRyou/cpp-book 私は今まで、GitHubで公開しているC++参考書には、誤字脱字のpull requestならばすぐに受け入れてきた。なぜならば、単純な誤字脱字、句読点の修正、ふりがなの追加などには、著作権は発生しないからだ。 著作権が発生するほどに複雑な修正は、受け入れずに自分で修正してきた。 今回、少し悩んだが、始めて、著作権が発生するほどのpull requestを受け入れることにした。41行ほどのJavaScriptコードだ。 内容は、JavaScriptを使って、スクロールイベントが発生するたびに、スクロールしている場所のidを指すように、ブラウザーのアドレスバーの文字列を書き換えるものだ。 これにより、今見ている場所のリンクが、常にブラウザーのアドレスバーに表示されることにな
私はGitHub が大好きです。GitHubはオープンソースへの コントリビューション （寄与貢献）を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトのGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時
■GitHub時代のオープンソース・プロジェクトとの付き合い方GitHubへpull requestする際のベストプラクティスからmaster ブランチで pull request していいのは小学生までってこともないの流れを読んでいて、先日ruby-listであったRedmineのRuby1.9,Rails3対応の話を思い出した。あのときは投稿者は納得して、「GitHub時代のコントリビューションの仕方」みたいなものを理解してくれたようなのだけど、その上で「masterでパッチ作るな」的なお作法を生真面目に受け取りすぎて敷居を高く感じてしまわれても困るよなぁと思った。 そこで、「GitHub時代にフリー/オープンソース・ソフトウェア(以下FOSS)プロジェクトと付き合うための五ヶ条」的なものをまとめてみた。まぁ、そんな大それたものでもないけど。 1. 貢献しようと意気込まない FOS
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「GitWorkflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
