「debug」ブランチで【rm whoyou.txt】と打って「whoyou.txt」を削除し、「Iam.txt」の中身を"I am a cat."に変更してステージングをしないまま、 【git checkout genbug】 と打って「genbug」ブランチに切り替え、ワークツリーを確認してみると、「Iam.txt」の中身は"I am a cat."に変更されているのに、 「whoyou.txt」は削除されていない（というより復活している）。 これはなぜなのだろうか？（whoyou.txtをgitリポジトリから消したいならrmコマンドではなくgit rm --cachedを使うべきなのはわかる）
ちなみに、 checkout前のブランチとcheckout後のブランチにコミットされているファイルが等しく無い場合、 checkoutすることでcheckout後のブランチにコミットされているファイルへ置き換わるが、 checkout前のブランチにおいてワークツリー上でそのファイルを編集や削除していると、 checkoutが失敗する 0467デフォルトの名無しさん (ﾜｯﾁｮｲ 9fe4-oOo3)2022/08/25(木) 02:40:02.58ID:W0zamWK80 $ git status -sb ## debug $ ls iam.txt whoyou.txt $ cat iam.txt I am a dog. $ echo "I am a cat." > iam.txt $ rm whoyou.txt $ git status -sb ## debug M iam.txt D whoyou.txt $ ls iam.txt $ cat iam.txt I am a cat. $ git checkout genbug M iam.txt D whoyou.txt Switched to branch 'genbug' $ git status -sb ## genbug M iam.txt D whoyou.txt $ ls iam.txt $ cat iam.txt I am a cat. 0468デフォルトの名無しさん (ﾜｯﾁｮｲ 1f5f-SiT/)2022/08/25(木) 10:19:53.57ID:x22ro4Sl0>>466-467 whoyou.txtが復活するのは勘違いしていたみたい すまん 「checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、 checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、 checkout後のブランチにそのまま引き継がれる」 こんな仕様があったのか。知らなかった。ありがとう。
To c:\gittest\server\proj01 ! [remote rejected] master -> master (branch is currently checked out) error: failed to push some refs to 'c:\gittest\server\proj01'
これはどういうことでしょうか？ 0533デフォルトの名無しさん (ﾜｯﾁｮｲ cfbb-Sudb)2022/10/01(土) 14:10:19.42ID:J9f91GHl0 それウィルスに感染してる 0534デフォルトの名無しさん (ﾜｯﾁｮｲ c31d-755I)2022/10/02(日) 17:48:34.37ID:6kxI91N30 コミットメッセージについてです テキストエディタを使って複数行書く方法と、コマンドライン上で1行書く方法が あるみたいですが、基本的にはどっちを使うべきなんでしょうか？ 0535デフォルトの名無しさん (ﾌﾞｰｲﾓ MMff-HD9v)2022/10/02(日) 18:05:40.19ID:dk1cJbbAM 仕事や既存OSSならチームのルールがあるだろうから先輩に聞け 個人ならどっちでも自分が楽な方でいい ぶっちゃけコミットメッセージなんか誰も見ないから実際どうでもいいし、 そのうちチームに入ってから空気読めばいいだけの話なんで学習中の身のうちから意識して鍛えておかなければならないほど大した話ではない 0536534 (ﾜｯﾁｮｲ c31d-755I)2022/10/02(日) 18:30:26.77ID:6kxI91N30>>535 分かりました ありがとうございます 取り敢えずVSCodeを使っておこうと思います 0537デフォルトの名無しさん (ﾌﾞｰｲﾓ MMe7-7lI2)2022/10/02(日) 18:55:33.63ID:q9OgIqJtM Vimを使って書くのが正しいやり方です 0538534 (ﾜｯﾁｮｲ c31d-755I)2022/10/02(日) 19:05:01.56ID:6kxI91N30>>537 そうなんですね インプレスの本ではVSCodeを使いなさいと書いてあったのでそうしました 0539デフォルトの名無しさん (ﾜｯﾁｮｲ cfbb-fxWw)2022/10/02(日) 19:10:39.82ID:uPDZdRB50 コミットメッセージちゃんと書けるやつが本物のプログラマ。書けないやつはゴミグラマー。 自分で試行錯誤しているローカルリポジトリはコマンドラインで適当に入れても良いけど、他人に見せるやつはエディタで丁寧に時間をかけて書く。 コードを書いている時間よりコミットメッセージ書いている時間の方が長いくらいで普通。 0540デフォルトの名無しさん (ﾜｯﾁｮｲ cfbb-Vwkg)2022/10/02(日) 19:16:22.79ID:D5S18uSu0 長文したためなくてもバグトラッカーのID書いてあればいいよ 繰り返しになるけどプロジェクト次第 0541デフォルトの名無しさん (ﾌﾞｰｲﾓ MMff-HD9v)2022/10/02(日) 19:28:14.51ID:Sn8H/WH4M>>539 まあチーム次第だから君が間違っていると言うつもりはないが、一般的に言って流石にコーディングより時間をかけるのは時間の無駄 コミットメッセージは見つけづらくて無駄だから、そんな時間があったらドキュメントでも書いてくれ 0542デフォルトの名無しさん (ﾜｯﾁｮｲ 435f-pIDl)2022/10/02(日) 20:42:06.76ID:t7yq2oGI0https://git-scm.com/docs/SubmittingPatches#describe-changes > The log message that explains your changes is just as important as the changes themselves. Your code may be clearly written with in-code comment to sufficiently explain how it works with the surrounding code, but those who need to fix or enhance your code in the future will need to know why your code does what it does, for a few reasons: ... 0543デフォルトの名無しさん (ﾜｯﾁｮｲ 6384-ARfL)2022/10/02(日) 21:53:11.93ID:QRo7yeZh0>>539 コマンドラインでもコミットメッセージはvimとかで丁寧に書けますが 0544デフォルトの名無しさん (ﾜｯﾁｮｲ 6384-ARfL)2022/10/02(日) 21:57:22.79ID:QRo7yeZh0>>541 ReamineのチケットとかGithubのIssueとかにコミットを結びつけた方が読みやすいよね 0545デフォルトの名無しさん (ﾜｯﾁｮｲ cfbb-fxWw)2022/10/02(日) 22:11:44.82ID:uPDZdRB50>>543 vim はエディタでないという主張は初めて聞いた。emacs は環境とういうのは良く聞くけど。 0546デフォルトの名無しさん (ﾜｯﾁｮｲ ff7c-pIDl)2022/10/02(日) 22:30:04.49ID:w76y/xOG0 コミットはWindowsでやるならTortoiseGitが楽でいい複数行のコメントも書けるしね ログもGUIの方が見やすいし、diffもそうだしね 0547デフォルトの名無しさん (ｽｯｯﾌﾟ Sd1f-HD9v)2022/10/02(日) 23:56:46.78ID:Yp4OiWZtd 今時Tortoiseはないでしょ GitはSVNなんかと違ってフォルダベースじゃないからファイルエクスプローラ上で操作するのは非合理で、 SourceTreeのようなワーキングツリーの差分をフラットに扱うクライアントのほうが圧倒的に使いやすい 普通に開発を進める分にはVSCodeやVS等のエディタ付属のGit機能で十分だしな
