なんたらノート第三期ベータスマートフォン用の表示で見るスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。読者です読者をやめる読者になる読者になるなんたらノート第三期ベータ2012-02-08GitHubでプルリクエスト用ブランチを保守するメモGitGitHubにリポジトリを置いてる人はみんなプルリクエストを待っています。プルリクエスト用にフォークした自分のリポジトリを保守する方法が途中でわからなくなって...という人が案外多いんじゃないかなと思ったり。人のためみたいな言い方ですが、まあ自分用のメモです。したほうがいいという原則。masterブランチはフォーク元から変更せず、かならず自分用のブランチを作る。これは、masterを作業の同期用に置いておくためです。自分のブランチでコミットしたあと、フォーク元のmasterが進んでないかのチェックは必ずすること。進んでいたら自分のmasterに元作者のコミットを取り込んで自分のGitHubでのフォークが最新と同期してる状態にしましょう。元作者のコミットログを確認して何が起こったのかを理解しましょう。いう名前は、オリジナル版の名前です。始まる名前にしないほうがいいということで、習慣的によくこの名前が使われます。元作者の作業がmasterで進んだのに、自分の作業ブランチが遅れたmasterを元にしてるというのはダメです。作業の基点をやり直すためにrebaseをしておきましょう。...ここで自分の最後のコミットとフォーク元のmasterの進化の間で競合があると、rebaseプロセスが保留されてこんなメッセージで止まります。これ初めて目にすると「あわわどうしたら」ってなりますね。--abort&#34;.このときソースコード的には競合をマージしないといけない感じになっています。mineとにかくこの競合を解決して両方の意図が反映されたコードにすること。それができるまで他のことしちゃダメ。いうのも、このときローカルリポジトリは処理保留中の状態なので、下手するとせっかくの自分の作業を紛失しちゃったりするかもしれません。あわてないあわてない。統合できたら保留されていたrebaseの処理を再開するように指示します。...これで競合がなくなれば、ローカルリポジトリでの同期は完了。あとはGitHubに自分の作業ブランチをpushします。いう例のメッセージが出てうまくいきません。これ、いちどGitHubにpushしたはいいけどやっぱりまだプルリクエストする勇気がないからってそのままにしてたけど、っていうようなブランチでよく起こります。そんなときは、リモートの自分のコミットをいちど巻き戻します。そこに、rebaseしてマージしたその上に自分のコミットを積んだものをpushします。mytopic...というここまでの操作を繰り返して、よし送るぞという決意が固まったらGitHubのフォームから熱い思いを綴ったメッセージとともにプルリクエストを。元の作者さんだって、コミットログが少々雑でもないよりあったほうがだんぜん嬉しいのがプルリクエストです。以上、プルリクエストの作法、というよりは、勇気が出るまで自分のブランチをメンテナンスし続けるうえで、パニックにならないための自分なりの操作手順メモです。良い作法なんかはもっと詳しい人の情報を参考にしてください。Blog|ブログを報告する。