1
3
テーマ、知りたいこと
Gitでブランチを切りながら、RailsでWebアプリの開発をしています。
コミットを記録してからについて理解が正しいのか不安なため、ご助言をいただきたいです。
私は、新規ファイルなどを生成した直後など、こまめにコミットを記録するようにしています。
（一例）
$ rails g model User
$ git add app/models/User.rb
$ git commit -m "add:User model生成"
$ rails db:migrate
$ git add .
$ git commit -m "add:Users tableを作成した"
このようにコミットをしております。
その後、コミットした箇所を変更したい場合、コミットのログを見て一度resetしたのち、修正して、新たにコミットするのが正しいのでしょうか？
また、戻らずにそのまま修正を施し、さらにコミットした場合何か問題が発生するのでしょうか？
言葉不足で申し訳ありませんが、ご教授願いたいです。
回答13件
#1
総合スコア145932
投稿2024/06/01 07:40
また、戻らずにそのまま修正を施し、さらにコミットした場合何か問題が発生するのでしょうか？
むしろ、普通はこうします。
特に、一度リモートなどの他のリポジトリへプッシュしたコミットをあとから変更すると、リモートに元のコミットが残り続ける事態となるので、gITツリーがカオス化するという、誰も得しない結果にしかなりません。
#2
ご回答ありがとうございます！
実行したコミットには触れずに、そのままコードを変更し、その後新たにコミットするという流れが正しいのですね。
もうひとつ質問させてください！
コミットはあくまでリポジトリに記録する行為であって、コミット同士で競合が存在していたとしても、コミットではコンフリクトは発生せず、マージする際にコンフリクトが発生する。という認識でして、
もしその認識が正しい場合、マージするまでコンフリクトは解消できないということでしょうか？
#3
総合スコア145932
投稿2024/06/01 08:46
編集2024/06/01 08:50コミット同士で競合が存在していたとしても
おそらく、「コミット」の概念を取り違えています。
Gitにおけるコミットは、前のコミットとの差ではなく、現在の状態をまるごと記録していくものです（圧縮効率がいいので、差分圧縮されることはありますが、それはコミットの本質とは別の話です）。
コミットする＝「現在の状態を記録する」ことに、他の状態は全く関係しませんので、1コミットするにあたって競合という概念自体が成立しません。「コミットされたもの同士の競合」だけが存在します。
#4
複数人の開発者同士のコミットで競合が発生することはあっても、個人で開発している場合はコミットによる競合は存在しないという認識で正しいでしょうか。
#5
総合スコア145932
投稿2024/06/01 09:16
そうではありません。ブランチを切った場合には、自分自身で行ったコミット同士が競合することもありえます。
#6
申し訳ございません、おそらく自分自身コミットについての理解が正しくないですね。
認識のずれがないか確認していただきたいのですが、
（gitでブランチを切って作業する場合）
私の認識するコミットは、「現在のローカルブランチで行われた変更をローカルリポジトリ内のマスターブランチに記録する操作のこと」という認識です。
「マスターブランチに記録する操作」というのは、マスターブランチに統合するものという認識です。
間違っていますでしょうか？
#7
総合スコア23549
投稿2024/06/01 13:06
間違えていますね
コミットは、「現在のローカルブランチで行われた変更をローカルリポジトリ内の現在のローカルブランチに記録する操作のこと」です。
ですからコンフリクトは発生しません。
マスターブランチに統合する のは マージ です。
ですから コンフリクト は起き得ます。しょっちゅうやらかしてます。
#8
総合スコア647
投稿2024/06/01 16:40
その後、コミットした箇所を変更したい場合、コミットのログを見て一度resetしたのち、修正して、新たにコミットするのが正しいのでしょうか？
また、戻らずにそのまま修正を施し、さらにコミットした場合何か問題が発生するのでしょうか？
①コミットのログを見て一度resetしたのち、修正して、新たにコミットする
②戻らずにそのまま修正を施し、さらにコミット
どちらが良いかは時と場合によります。
大前提として「既に他のブランチにマージしている」「リモートにプッシュしている」内容を含む箇所には絶対に戻らない方が良いです。
（社外秘の内容を公開してしまったとか容量の問題でリポジトリに含めるべきでなかった…みたいな場合は専用の歴史修正のための手法があり、ちゃんと関係メンバーに周知の上で対応します）
一般的に他ブランチに統合済み・リモートに公開済みというのは「確定された」状態で、その機能や挙動を元に他者がさらに開発を進めている可能性があります。
この状態での修正とは「既存機能の変更」にあたるので、変更自体を新たなコミットとすべきです。
そうではないローカルの自分専用ブランチの場合は、まあどちらでもよいです。
極端な例ですが
「AとBを作成した」みたいなコミットで、Bをaddし忘れていたような場合の直後の修正は
「Bをコミット忘れていた」という追加コミットではなく commit --amend で実質「1つだけresetしてコミットし直す」という①のやり方が一般的です。
また、特に自分専用・未公開・未統合のローカル作業用ブランチであれば、試行錯誤のためにコミットを捨てるのはよくやります。
その際は新たに試行錯誤用ブランチを派生させていろいろ試す→ブランチごと捨てるという(①とも②とも異なる)やり方でも、
戻りたくなったらresetで戻す(①の方針)、でも良いです。
最初から「色々試してみよう！」と言う場合は素直に作業用ブランチを作るのが一般的ですが、
正しいと思っていくつもコミットして進めていた作業に方針レベルで大きな問題があって全部戻さなきゃ…みたいな場合には
大量にrevertコミットするという②の方針ではなく一連の作業開始まで戻ってしまう①の方が分かりやすいでしょう。
戻らずにそのまま修正を施し、さらにコミットした場合何か問題が発生するのでしょうか？
不整合などの問題は発生しませんがデメリットはあります。
細かい修正のたびに毎回コミットし直していると、あとから分かりにくい履歴になりがちです。
大きな粒度で見ればメインブランチへのマージ単位で機能レベルの変更を追えれば良かったりするので、重篤なデメリットでもないですが
本当に何がなんだか分からないログが並ぶよりは気軽にreset/rebaseでログを多少キレイにしていくのはありだと思います。
「〇〇が良いと思って作成したがこれこれこういう問題があったので△△に変更する」という説明を含めた修正コミットであれば、作業用ブランチであっても履歴として残す価値は大いにありますが
「〇〇と△△を作成」「言語仕様をちゃんと確認したら〇〇と□□だった」「よく考えたら××と□□だった」…みたいなログが並ぶのであればいや最後のコミットだけでいいやろ！…みたいな。
（この辺は流派や思想によって意見が分かれる所です）
色々細かく書きましたが
ピンとこない、完全には理解できてない……というような状態であれば
一切resetせず修正コミットを積み上げる方が安全で楽かもしれません。
#9
コミットは、「現在のローカルブランチで行われた変更をローカルリポジトリ内の現在のローカルブランチに記録する操作のこと」
とのことですが、つまり、現在のローカルブランチでコミットを複数回する場合、現在のローカルブランチに記録がどんどん追加されていくということでしょうか？
また、そのコミット（現在のローカルブランチにコミットしたもの）は、変更履歴を追跡できるようにするためだけに行うものという認識は正しいでしょうか？
#10
一般的に他ブランチに統合済み・リモートに公開済みというのは「確定された」状態で、その機能や挙動を元に他者がさらに開発を進めている可能性があります。
この状態での修正とは「既存機能の変更」にあたるので、変更自体を新たなコミットとすべきです。
そうではないローカルの自分専用ブランチの場合は、まあどちらでもよいです。
↪️この説明すごくわかりやすかったです！
また、特に自分専用・未公開・未統合のローカル作業用ブランチであれば、試行錯誤のためにコミットを捨てるのはよくやります。
↪️とのことですが、コミットを捨てるとは、コミットした内容をほったらかしにして、新規のブランチを切って作業を再開するということでしょうか？
#11
総合スコア23549
投稿2024/06/02 07:55
とのことですが、つまり、現在のローカルブランチでコミットを複数回する場合、現在のローカルブランチに記録がどんどん追加されていくということでしょうか？
そうです。 そのブランチで git log してみて
また、そのコミット（現在のローカルブランチにコミットしたもの）は、変更履歴を追跡できるようにするためだけに行うものという認識は正しいでしょうか？
私の場合はそればかりではない。
何かが解決した毎に行うことが多いな。次の問題解決でわけわかになったときに戻る場所の確保。
#12
総合スコア29
投稿2024/06/04 14:05
リモートリポジトリで他人と一緒に作業をするのか、
自分だけで作業をするのかで大きく違うかと思います。
自分だけであれば極論好きにすりゃいいと思いますが、
チームで作業をしている中で無駄なコミットを大量に増やされると可読性が酷く落ち込むため、
使えないエンジニア認定されてしまうかもしれません。
細かいコミット癖があるのであれば、作業用ブランチにて作業を行い、プルリクやレビュー依頼を行うブランチは別で作成して、清書のように必要なコミット分けだけ行い提出するのが良いと思います。
レビュー指摘に対して修正を行いコミットする分にはレビュアーが変更履歴を追いやすいため、清書してレビュー依頼を行ったブランチにコミットするのが基本だと思います。（チームの規定によるかとは思いますが。）
#13
総合スコア647
投稿2024/06/04 22:29
コミットを捨てるとは、コミットした内容をほったらかしにして、新規のブランチを切って作業を再開するということでしょうか？
開発ルール次第ですが
その「ローカル作業用ブランチ」が、プロジェクト管理ツールの issue, ticket, etc... に結びついたいわゆる feature ブランチであれば、そのブランチのままで安全なポイント(試行錯誤とかの前)に reset します。
そうではなく最初からいろいろ試行錯誤したいと分かっているなら
feature ブランチから試行錯誤用の一時的なブランチを派生させてそこで色々試してみて、満足したら元の feature ブランチへと戻り
上手くいった部分だけを feature ブランチに取り込んで / 上手くいかなかったらそのまま何もせずに、
最終的には一時的なブランチごと全部捨てたりします。
（試行錯誤ブランチは一般的に他開発者にとって意味はないので、feature ブランチにマージしたりして公開はしません）
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。