じさばどん
ところで stash は add するファイルを調整すれば一部ファイルや差分のみ stash することもできた気がします
git stash 慣れてないので まだ apply した時にちゃんと元に戻るのか不安な私です(だめ)
git stash なーメンタルがSVN系なのでだいたい全部の操作がディレクトリ丸ごとなことにまだ慣れていない…
かもしれない
根本的に、「unstaged / unmanaged な変更がある状態で merge を行う」というのがおかしいのでは
seyana
コミットしろ
gitのマージ失敗時の処理はぐぐるとなぜか git reset 系の手元で変更してるファイルがある怠惰な人間にはとても危険なコマンドが出てくるのですけど、私としましてはいったんコンフリクトしてるファイルを全部 git add 後 git commit してマージは完了させてしまった後でマージ前のリビジョンをチェックアウトして元いたブランチを消して戻った位置にブランチを作成しなおすのを推奨します。
だいたいコミットしてない変更がめっちゃあるので git reset --hard すると死にます
うちマージしまくってる < PRにmasterをマージ
(ただしgitに対する知識があるていど必要)
git で一番恐ろしいミスは、 unstaged な変更を消してしまうことと .git を消してしまうことで、後者は git コマンドから起こることはおそらくないので、コミットされたものを弄るだけなら大概のことは取り返しがつく
rebaseとかcherry-pickした物をリモートに送ってはいけないという訳ではなくて、リモートに送ると誰かがpullとかmergeしてしまうかもしれないので送らない方が良いというやつ
コミットログがカオスになりますけど。
rebaseとcherry-pickはうっかりして事故るのが怖いので回避するほうですね
じつは毎回リリースノート見てない…
けっこうv2.6.1への更新でハマってるインスタンスあるみたいね。
途中のv2.5.1、v2.5.2がstable-2.5系で、メインのツリーはv2.5.0からのアップデートになるから、conflictしやすい。
v2.5.xのリリースノートで、これバックポートだから、pullすんなよ、fetchしてcheckoutにしとけよ、って書いてあったと思うんだけど、意味が通じていたかどうか……。
upstreamと自分のリポジトリのそれぞれのブランチの分岐状態がどういう状態になっているかに依存しそう…。
リモート参照先をGitHub側でフォークした自分のレポに変更してうまくいくかな?リモートが進んでても一致しない部分から分岐するだけだからいけるか。
upstreamのコミットグラフを把握する必要はある
Mastodonは、オープンなウェブプロトコルを採用した、自由でオープンソースなソーシャルネットワークです。電子メールのような分散型の仕組みを採っています。