最終更新: 2019-04-12T22:47+0900
プルリクエストの元になったブランチは、自分の GitHub リポジトリにプッシュしたものが即座にリクエスト先にも反映される点で、公的なブランチだといえる。
プルリクエストに対する修正を事前に私的にテストするために、プルリクエストを意図せず Work in progress 状態にしないために、どういう手順をとるか。
前提として AppVeyor といった CI が自分の GitHub リポジトリと連動しており、GitHub にプッシュしなければテストが完了しないという事情がある。
元になったブランチから私的実験ブランチを派生させるのがいいと思う(これって常識？)。実験して結果を確かめたものを公的ブランチにマージし、必要ならリベース(並べ替え・併合)し、プッシュする。あるいは実験ブランチの段階でリベースによりコミットの取捨選択と整理を行っておき、公的ブランチにはマージとプッシュだけをしてもいい。
最終更新: 2019-04-12T22:47+0900
操作対象で分かれてるよね。そんで fetch, pull, push 以外はオフラインと考えていい。
rebase の用途は主にマージの１手段としてと、ブランチの付け替えと、コミットの整理とがあるけど、やってることはコミットオブジェクトの書き換え(※)であると。
※これは概念的な理解であって、もちろんコミットオブジェクトは名前に対して不変であるし、実際には refs/heads の書き換えも行っているはず。
ローカルブランチの削除は branch で行うけど、リモートリポジトリにあるブランチの削除を行うのは push であると。
git pull --all とかやっちゃうと操作対象はブランチだから、現在のブランチにマージコミットが追加されておろおろしてしまうと。git fetch --all にしよう。
もちろんオプションによりブランチだった対象がタグになったりするし、branch サブコマンドでリモート(※ローカルのリポジトリにフェッチ済みのリモート)にあるブランチを表示したりもできる。あくまでも基本の対象ではある。
最新バージョンはご使用のシステムに対応していません」だもんなあ。■Vivaldi はインストールできたし、GitHub も使用できた。■Windows Vista は発売直後に買ったけど、10 はいらないんだよなあ。ほら>「【Windows 10】「勝手にLINEがインストールされていた」の声が増加中（2018年11月11日） | LINEの仕組み」■かくいう Vivaldi も背後のウィンドウとの境目がわからないフラットデザイン(デザイナー仕事しろ！)だけどな。■枠が欲しけりゃ「通常のウィンドウを使用する」という設定が Vivaldi にはあるんだよ。でも、右上のコントロール(＿□✖)のサイズが設定とは異なり小さすぎるし、Aero Glass でない単色の青だしで、全然「通常のウィンドウ」ではない。
if (this) {} else {} みたいなコードが通らなくなる。ヌルポインタかどうかを確かめることには問題がないし、仮想関数を呼び出そうとしたりしない限りは C++ 的にも許されている雰囲気を感じていたのだけど、デバッグ情報が this 付近にあると期待されていたりしてそれが問題につながるんだろうか。■ -g オプションだけなら OK だった。■ -Os でもアウトだったから問題は -Os, -Og という最適化オプションにある。許されてはいなかったのか……。■「C++ の標準としては未定義動作です」最終更新: 2021-05-12T04:21+0900
あまり書かれていないことだけ。
git remote git remotegit remote set-url --push <remote> ""git config --global --add branch.autoSetupMerge false--no-track を既定値にするということ。git branch のみならず git checkout -b においても。--ff-only なマージで済むはず。でもマージする範囲が自動ではわからないかも。なら毎回新しくチェックアウトするとか。git push [-u] <myRemote> localBranch[:remoteBranch]localBranch の部分を HEAD にするとチェックアウト中のブランチ名を意味するみたい。※コミットオブジェクトへの参照(refs)ではなく、refs への参照ってこと？:)はローカルとリモートにおける全ての同名のブランチの組を指すらしい。ローカルにだけ短い名前を付けると対象から外れてしまうし、それがリモートに存在する無関係のブランチと同じ名前だったりしたら……(考えるだに恐ろしい)。git checkout --detach してから。これでひとつのブランチも残しておかなくて済む。[Tips] おそらく一番タイプするコマンドのエイリアス。
[alias] co = checkout st = status --short --branch
git reset, git pushgit push <remote> --delete <remoteBranch> (--delete の代わりにコロンでも同じ。:<remoteBranch> 空のブランチを push = 削除)git fetch --all して <remote>/master などと参照すればよい。すべては自分のリポジトリを表示したときに、他人の作業の成果があたかも自分のものであるかのように表示されるのが嫌だから。あとは一見したページの印象がそっくりだと、自分のリポジトリを削除するつもりでフォーク元のリポジトリを削除してしまうことがあるから。
自分にとって３つのリポジトリの関係は「本家―ローカル―フォーク」として捉えられている。でもひょっとしたら「本家―フォーク―ローカル」の想定もあるのかもな、と考えてみた次第。でも自分で GitHub にフォークリポジトリを持たなくても「本家―ローカル(フォーク)」の２者間でもフォークは成り立つので、中心に GitHub 上のフォークリポジトリを置くのは、GitHub の中の人の立場としてならともかく、個人としては順序が違うと思う。メンタルモデルはひとつで十分だ。そのとき GitHub 上のフォークリポジトリは３番目に位置するオプショナルな存在となる。
♭ べる運転手運転拒否で客放置