gitなどのバージョン管理システムでコミットをグループ化するにはどうすればよいですか

1つの長いフラットなコミット履歴の代わりに、階層がないのはなぜですか。そのため、トップレベルでプルリクエストがあり、レベルを下げてそのPRのコミットを確認できます。PRはgithubに固有のものであると思いますが、あなたはそのアイデアを理解しています。たとえば、いくつかのコミットを機能やバグ修正としてグループ化することを意味します。

確かに、コミット履歴をナビゲートしやすくなります。

この質問には明白な答えがあると思いますが、それを見つけることができないようです。

変更は順次的であるため、1つの長いフラットコミット履歴があります。それぞれが「前」の状態に基づいて構築され、「後」の状態を残します。これを反映しない変更を行うのは難しいでしょう。

-関連する変更をグループ化するための1つのオプションは、タグを使用することであるhttp://git-scm.com/book/en/Git-Basics-Taggingを彼らはより多くの歴史の中でポイントにタグを付けるのではなく、異種のコミットをグループ化するために使用されているけれども。

コミットをより大きなものにグループ化するには、インタラクティブなリベースを行うこともできます。

ブランチは1つのオプションです。ブランチを作成し、論理的に関連する一連のコミットを実行できます。おそらく--no-ffオプションを使用して、これらのコミットを必要に応じてマスターにマージできます。

ブランチ間の関係は、gitg / gitxなどのビジュアルツールでも確認できます

Git がその親ブランチに番号を付けることに気づくまで、私はこれについて同じ問題を抱えていました。これが与えられれば、通常生成される厄介なマージコミットはサマリーノードと見なすことができます。また、すべての余分な詳細を表示から除外して、単一の要約された線形履歴を残すことができます。

詳細と例については、このブログ投稿を確認してください。

コミットをブランチにグループ化します。各ブランチはコミットのセットです。コミットをマージするときは、1セットのコミットを別のブランチ内に置き、コミットの階層を効果的に構築します（メインブランチ、機能、バグ、実験など）。

理想的には、メインブランチは一連のマージコミットです。最初の親だけを見る場合（gitコマンドはそのようなオプションを受け入れます）、履歴の高レベルのビューが表示されます（うまくいけば、自動生成されたコミットではなく、意味のあるマージコミットを記述します）。ただし、履歴でマージの2番目、3番目などの親を見ると、ボックスを開いて、マージの内容を確認できます。ここに何が起こったかの詳細があります。