私は研究のために取り組んでいるPythonプロジェクトを持っています。私は2つの異なるマシンで作業していました。私は最近、ファイルの半分がタブを使用し、残りの半分がスペースを使用していることを発見しました。書式のみの更新は軽度のGitコミットですか？
Pythonは、編集して別のマシン上のファイルを実行しようとしたときに反対しています。そのため、すべてをタブではなくスペースに切り替える必要があります。しかし、これはGitコミットの無駄だと思われます。コミットされていないが正しいファイルで 'git diff'を実行すると、ファイル全体が置き換えられて置き換えられるように見えます。
方法はありますか？つまり、これらの（IMO）軽薄な変更を「隠す」方法がありますか？
これは、rebaseと呼ばれていますが、そのファイルを編集した各コミットで遡ってすべてのファイルにスペースを追加したいと思うでしょう。これは非常に面倒です。
ただし、このようなコミットには何も問題ありません。コミットとは、プロジェクトの異なる機能状態を変更し、タブをスペースで置き換えることは間違いなく別個の状態です。
となる場所は、誤って機能しないコミットをした場合です。たとえば、必要なファイルの半分だけをコミットしたとします。
最後のこと：変更を別のマシンにプッシュした後は、履歴を編集しないでください（つまり、rebase）。マシンが同期しなくなり、レポがゆっくりと爆発的に始まります。
良い答えですが、コミットが「機能的」な状態でなければならないという要件を強制すべきではありません。多くの状況で非機能コード状態を持つことは完全に容認されます。 （誰かが頼りにしている既存のコードを壊していない限り）私の仕事の大きなプロジェクトでは、機能ブランチレポのレイアウトがあります。それぞれの問題は、独自のブランチを取得し、その問題のコミットが行われ、その後、トランクにマージされます。マージされた状態の作業について心配する必要がありますが、ブランチコミットは機能する必要はありません。 –
これにより、より詳細なタイムライン、進捗状況の追跡、チームコラボレーションなど、多くのメリットが得られます。 –
残念ながら、テキストレベルでは大きな変化です。空白の変更とその他の変更を混在させることはできません。そのようなコミットの話題は、空白の変更だけでなければなりません。
このスクランブルが公開されていない場合（プライベートレポジスにのみ公開されている場合）、導入時の履歴にその時点で戻って混乱を修正し、その後の変更を修正する苦痛を経験することができます（正しい字下げスタイルで再加工する必要があります）。努力のために、あなたはきれいな歴史に終わる。
これは完全に有効です。ホワイトスペースの再フォーマットと同じファイル内の他の変更を結合すると、ホワイトスペース以外の変更を難読化する可能性があります。コミットには、空白を再フォーマットする単一の責任があります。
純粋に私の意見ではあるが、書式変更のみのコミットは実際には本当のコミットになる理由は何かを伝えるメッセージをコミットするだけのことです（「すべてをスペースのみに切り替え、コードや動作の変更は意図していません"またはそれのようなもの）。 – torek
@torekに同意します。特にタブからスペースへのフォーマット変更は、独自のコミットでなければなりません。私はgithubの大規模なプロジェクトに定期的に貢献し、マージされたプルリクエストの中にはこれよりも重要度が低いものがあります（たとえば、今日のpythonファイル 'pep-8'に準拠させました）。 –
@torek - そのコメントを回答にすると、私はそれを受け入れるでしょう（それは、Kazの答えの前に約1分で現れました。 – tonysdg