/ 最近 .rdf 追記 編集 設定 本棚

脳log[20181113] GitHub でプルリクエストを出した後の作業手順 | Git のサブコマンドについて



2018年11月13日 (火) #世界ふしぎ発見 で「銀ブラ」の語源をクイズに出題し、三省堂国語辞典で誤りとされた説を正解として紹介する - Togetter」■モーガン・フリーマンの名前を冠した NHK の教養番組っぽいものが種々雑多な言説をフラットに取り上げていて、それはつまり業界の共通認識と異端児1人の言っていることの取り扱いに差がないということで、その回の放送内容のほとんどすべてを聞きかじっていた分野だからそういう判断ができたけど、それ以外で普通に「へーそーなんかー」と感心していては危険な番組だと思った。

最終更新: 2019-04-12T22:47+0900

[Git] GitHub でプルリクエストを出した後の作業手順

プルリクエストの元になったブランチは、自分の GitHub リポジトリにプッシュしたものが即座にリクエスト先にも反映される点で、公的なブランチだといえる。

プルリクエストに対する修正を事前に私的にテストするために、プルリクエストを意図せず Work in progress 状態にしないために、どういう手順をとるか。

前提として AppVeyor といった CI が自分の GitHub リポジトリと連動しており、GitHub にプッシュしなければテストが完了しないという事情がある。

元になったブランチから私的実験ブランチを派生させるのがいいと思う(これって常識?)。実験して結果を確かめたものを公的ブランチにマージし、必要ならリベース(並べ替え・併合)し、プッシュする。あるいは実験ブランチの段階でリベースによりコミットの取捨選択と整理を行っておき、公的ブランチにはマージとプッシュだけをしてもいい。

最終更新: 2019-04-12T22:47+0900

[Git] Git のサブコマンドについて

操作対象で分かれてるよね。そんで fetch, pull, push 以外はオフラインと考えていい。

remote
外部リポジトリ名
rebase
コミット
branch
ブランチ
checkout
ワーキングツリー
reset
refs/heads [インデックス] [ワーキングツリー]
fetch
refs/remotes
merge
refs から refs へ
pull
リモートからローカルのブランチへ
push
ローカルからリモートのブランチへ

rebase の用途は主にマージの1手段としてと、ブランチの付け替えと、コミットの整理とがあるけど、やってることはコミットオブジェクトの書き換え(※)であると。

※これは概念的な理解であって、もちろんコミットオブジェクトは名前に対して不変であるし、実際には refs/heads の書き換えも行っているはず。

ローカルブランチの削除は branch で行うけど、リモートリポジトリにあるブランチの削除を行うのは push であると。

git pull --all とかやっちゃうと操作対象はブランチだから、現在のブランチにマージコミットが追加されておろおろしてしまうと。git fetch --all にしよう。

もちろんオプションによりブランチだった対象がタグになったりするし、branch サブコマンドでリモート(※ローカルのリポジトリにフェッチ済みのリモート)にあるブランチを表示したりもできる。あくまでも基本の対象ではある。

See also...

listed by...